Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to Fix References #306

Closed
4 tasks done
samjcombs opened this issue Feb 5, 2023 · 7 comments
Closed
4 tasks done

Option to Fix References #306

samjcombs opened this issue Feb 5, 2023 · 7 comments
Labels
👯 no/duplicate Déjà vu 👎 phase/no Post cannot or will not be acted on

Comments

@samjcombs
Copy link

Initial checklist

Problem

It would be great if these three rules:

  • no-undefined-references
  • no-duplicate-definitions
  • no-unused-definitions
    had a --fix or --output option to do the following:
  • no-undefined-references - remove the brackets around the undefined reference
  • no-duplicate-definitions - add a comment to each duplicate so the user can decide which one to keep
  • no-unused-definitions - remove the definition entirely

I have been looking into how to achieve this but before I dive in completely I was wondering if theres a simple option to turn a rule into a write rule instead of just a warning reporter.

Great work on this repo, very impressive stuff here!

Solution

For no-undefined-references

Given this input:

Welcome to [foo].

Desired output:

Welcome to foo.

For no-duplicate-definitions

Given this input:

Welcome to [foo].
[foo]: http://foo.com/1
[foo]: http://foo.com/2

Desired output:

Welcome to [foo].
[foo]: http://foo.com/1 // Duplicate definition `foo` defined on line 3. 
[foo]: http://foo.com/2 // Duplicate definition `foo` defined on line 2. 

For no-unused-definitions

Given this input:

Welcome to foo.
[bar]: http://foo.com/1

Desired output:

Welcome to foo.

Alternatives

I tried piping the output of the cli with these three rules enabled to a script that would parse it and determine where to do file edits, but it got too complicated as lots of work has to be done to make sure that when it starts editing the file, future edits take into account what was already removed and translate positions of everything accordingly. All in all, not a good solution.

Another option I've been toying with is to use these rules to output the AST tree instead of the files, and then parse through that AST and perform the modifications, but I'm not sure how I'd find the violating AST nodes, unless these rules actually add isAllowed to the ast nodes themselves.

Open to other solutions here and it may be easier to do this on a rule by rule basis.

But an abstract solution to provide a fix and fix options for each rule would be great, so users could say, for nodes that violate this rule, fix it in this way.

Thanks much!

@github-actions github-actions bot added 👋 phase/new Post is being triaged automatically 🤞 phase/open Post is being triaged manually and removed 👋 phase/new Post is being triaged automatically labels Feb 5, 2023
@ChristianMurphy
Copy link
Member

ChristianMurphy commented Feb 5, 2023

Welcome @samjcombs! 👋
Thanks for the time and consideration, improving the developer experience is definitely a continuing goal for the project.

I have been looking into how to achieve this but before I dive in completely I was wondering if theres a simple option to turn a rule into a write rule instead of just a warning reporter.

Not currently, see #82
There is ongoing discussion on the approach, your thoughts and insights are welcome on the thread.

no-undefined-references
no-unused-definitions

I'd be cautious outright removing the reference or definitions as a fix.
I see there being (at least) three cases.

  1. There is plain text with a parenthetical which happens to use square brackets, the appropriate fix here would be to escape to clarify that it cannot be a reference ([aside] becomes \[aside\])
  2. There a reference is intended but there is a typo ([a-real-reference-typo] should suggest, "reference is undefined did you mean [a-real-reference]?")
  3. Definition was intentionally removed, but a reference is still hanging (the situation you note)

Given that there are multiple scenarios, I'm not sure remark-lint should take automatic action even if it could.
This feels like something where an integration with https://github.com/remarkjs/vscode-remark would be a better fit, allowing the user to choose from a list of potential fixes.

no-duplicate-definitions

I'm not sure the value of adding a comment would have here.
It doesn't fix the error, and it contains the same information an error message would have.
So the error message may be fine?


Given your interest in fixes.
I'd highly recommend reading through #82 and chiming in with ideas.
As well as checking out https://github.com/remarkjs/vscode-remark, I could definitely see a tie-in between multiple fix options, which require user feedback, and the language server.

@ChristianMurphy
Copy link
Member

@samjcombs thoughts on the above? Is thing something you'd be interested in working on?

@remcohaszing
Copy link
Member

remark-language-server / vscode-remark gives suggestions based on the expected property of reported messages. Let’s say you have this message, it will show a quick fix suggestion to remove the reference:

const message = new VFileMessage('Undefined reference [foo]', nodeOrPosition, 'remark-lint:no-undefined-references')
message.expected = ['foo']

For removal, suggest an empty string.

const message = new VFileMessage('Duplicate reference [foo]', nodeOrPosition, 'remark-lint:no-duplicate-definitions')
message.expected = ['']

This expected property is provided by quite a lot of retext plugins, but not remark-lint plugins. I definitely see value to add several of those.

This doesn’t provide an option to fix all issues with a single command though.

@wooorm
Copy link
Member

wooorm commented Jan 19, 2024

Closing as is discussed in GH-82.

Adding actual/expected fields can be done in separately PRs!

@wooorm wooorm closed this as completed Jan 19, 2024
@wooorm
Copy link
Member

wooorm commented Jan 19, 2024

Duplicate of #82

@wooorm wooorm marked this as a duplicate of #82 Jan 19, 2024

This comment has been minimized.

@wooorm wooorm added the 👯 no/duplicate Déjà vu label Jan 19, 2024
Copy link

Hi! Thanks for taking the time to contribute!

Because we treat issues as our backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn’t an exact duplicate but is closely related.

Thanks,
— bb

@github-actions github-actions bot added 👎 phase/no Post cannot or will not be acted on and removed 🤞 phase/open Post is being triaged manually labels Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
👯 no/duplicate Déjà vu 👎 phase/no Post cannot or will not be acted on
Development

No branches or pull requests

4 participants