message url

[BarryThePenguin]

From steelbrain/linter-ui-default#205, there is a url on the linter message

eslint uses a url to link to the rule documentation https://github.com/jfmengels/eslint-rule-documentation

unified-engine-atom could do something similar

[wooorm]

Yes agreed!
I've been wondering if we could somehow align vfile messages more with linter messages: maybe supporting suggestions even?!

I'm open to suggestions: do you have ideas?

[BarryThePenguin]

When you say supporting suggestions, do you mean solutions?

solutions?: Array<{
 title?: string,
 position: Range,
 priority?: number,
 currentText?: string,
 replaceWith: string,
} | {
 title?: string,
 position: Range,
 priority?: number,
 apply: (() => any),
}>,
// ^ Possible solutions to the error (user can invoke them at will)

[wooorm]

Yup, sorry, both like this: remarkjs/remark-lint#82, and like this: retextjs/retext-simplify@8ec7ce8

[wooorm]

First case was meant to be 'solutions', second was meant as suggestions for a better API and more features/properties!

[BarryThePenguin]

I like the idea of solutions. A single 'fix'/'apply' function makes sense for remark-lint, while the Array of solutions makes sense when dealing with retext plugins that might provide multiple solutions for fixing an issue.

Something that confused colleagues with remark was the stringify settings were seperate from the lint configuration. Neither which impacted one another. Having the 'fix'/'apply' functions might make configuring remark simpler.

The other thing I've been thinking about is the difference between location and range. Atom works with 0-indexed positions (Range). I'm not too sure what the advantages/disadvantages are of 0-indexed positions vs 1-indexed positions. Adding a getter for range to a vfile message that returns toRange(location) probably makes sense.

And urls. How much ✨ magic ✨ would you want in the url handling? Eslint use eslint-rule-documentation and determines the url based on the rule name and a map of plugins and repository urls. Could do something similar. It may just be easier for each rule to set it's own value for url in the vfile message, and mention the url property in the vfile documentation.

Also... have you considered using flow?

[wooorm]

I like the idea of solutions. A single 'fix'/'apply' function makes sense for remark-lint, while the Array of solutions makes sense when dealing with retext plugins that might provide multiple solutions for fixing an issue.

• So there’s two ways to fix stuff. One is AST changes (transforms), the other is text fixes. The latter is what ESLint does, it inserts, removes, or replaces a few characters in the original file. The first sounds really cool, but there are many rules that cannot be fixed in through AST changes (as it’s an AST, not a CST). Transforms cannot work together with text replacements, as transforms make the tree “unstable” (not representing the origin document) which means text fixes cannot be applied.
• Finally, the unified API (so not the CLI) cannot apply fixes: the original document is forgotten, but even if it could, it shouldn’t, as now there’s a transformed document (destination file) and a fixed document (based on the original).
• If we do fixes, it should probably be related to vfile, as vfile handles files and their messages.

Something that confused colleagues with remark was the stringify settings were seperate from the lint configuration. Neither which impacted one another. Having the 'fix'/'apply' functions might make configuring remark simpler.

Yes, I get that! Though fix and apply cannot be used together with tree transforms, as mentioned before

The other thing I've been thinking about is the difference between location and range. Atom works with 0-indexed positions (Range). I'm not too sure what the advantages/disadvantages are of 0-indexed positions vs 1-indexed positions. Adding a getter for range to a vfile message that returns toRange(location) probably makes sense.

Could you expand on how you see that working?

And urls. How much ✨ magic ✨ would you want in the url handling? Eslint use eslint-rule-documentation and determines the url based on the rule name and a map of plugins and repository urls. Could do something similar. It may just be easier for each rule to set it's own value for url in the vfile message, and mention the url property in the vfile documentation.

I’d say no magic at all, just a url property :)

Also... have you considered using flow?

No, reason: I don’t like compiling, I like JavaScript!

[wooorm]

I opened vfile/vfile#21 to work on this!