Proposal: Tiny URLs for rules in stylish formatter

Hi there. A common problem for me is, that sometimes I violate a rule, that I’ve never heard before. Typically I see this:

Now I fire up <search engine> and enter eslint no-undef or eslint react/jsx-no-bind to find out what this rule is about. This process could be easier, if there was a link to the documentation of the linting rule, like this:

or this

While adjusting the formatter, I found that some documentation links would be really long, like https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-static-element-interactions.md, which obviously look bad, so this is why I used a shorter version http://example.org/r/{ruleId}.

Yesterday I had a look into creating a simple redirect service with the help of nginx, it is pretty easy, e.g.

location /r/react/ {
    rewrite ^/r/react/([a-z-]*)$ https://github.com/yannickcr/eslint-plugin-react/tree/master/docs/rules/$1.md permanent;
    return 404;
}

Now before I start implementing things, I wanted to ask the maintainers and community if they think this feature is useful and if they’d like me to implement it.

[Krinkle]

@leipert Another way would be to introduce a url property into the rule registry, could be placed alongside the existing meta data that rules have (docs, fixable, category, etc.).

It seems to me like this would provide a more scalable approach, would relying on a centralised service or other indirection layers. The formatter will have access to this meta data and can choose to output it in some form.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom formatters at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the formatter yourself, rather than using a bundled formatter that is packaged with ESLint.