Expose rule URLs to formatters

ESLint Version: 4.15.0

Now that url has been added to meta.docs (#6582) we can use that field to share more information about a rule in the output.

The most obvious place to start is the HTML formatter, which includes links to rule documentation. Currently the links only work for core rules because eslint.org is hard-coded in the URL.

I opened a pull request (#9840) to get an idea of what kind of changes would be needed, and @not-an-aardvark has some great comments, which I’m just going to copy verbatim:

• I like the idea here – it seems like it would be useful to provide url info to formatters.
• If we do add a second argument to formatters, I think it should be an object (perhaps something like { rules: ruleMap }) rather than the rule map itself. That way, if we want to provide additional information to formatters in a later enhancement, we could add it to the same object, so formatters wouldn’t need to remember the argument order and do something like function(results, unused, newInfo) {}.
• getRules is currently somewhat slow, because it requires it requires loading all core rules from the filesystem, and copying a map of rules with ~250 elements. (Currently, we only load a core rule for the first time when it’s actually used, which reduces startup time.) I wonder if it would be better to pass an object like { getRule: ruleName => rule } to the formatter, so that it would only need to load the rules that are needed.
• As an open question, would it be better to just give formatters access to rule.meta or rule.meta.docs rather than giving access to a rule itself? Giving formatters access to a rule object itself would allow them to do things such as rerunning the rule, which seems like it could be confusing because formatters are just supposed to apply a transformation to the results. (Admittedly, I’m not sure why a formatter would want to rerun the rule, but ideally I think we should provide the minimal API needed to be useful.)

[not-an-aardvark]

That could work, although I feel like it’s a lot of complexity for something that users shouldn’t need to do anyway. Maybe a better solution would be to make a breaking change and not allow users to mutate anything (maybe by exposing a similar interface that doesn’t have any mutator methods, or adding something like getRule to Linter to get a single rule without copying the map).

[not-an-aardvark]

It now occurs to me that we could create a “v2” JSON formatter that serializes an object with two top level properties: results and rules.

That seems like a reasonable compromise to me, although I think it would be better to give the formatter a name like json-with-metadata rather than “v2” to avoid implying that the original json formatter would be obsoleted.