Breaking: improve plugin resolving (refs eslint/rfcs#47)

[mysticatea]

Prerequisites checklist

• I have read the contributing guidelines.
• The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

What is the purpose of this pull request? (put an "X" next to an item)

[X] Other, please explain: change existing core features

What changes did you make? (Give an overview)

This PR implements a part of RFC47.

• 3f09215 changes the location that ESLint loads plugins from. (link)
• d29f613 deprecates CLIEngine::getRules() and adds CLIEngine::getRulesForFile(filePath). (link)
• 0d6afaf deprecates metadata.rulesMeta and adds metadata.getRuleMeta(ruleId, filePath). (link)
• f3cc32f deprecates report.usedDeprecatedRules and adds report.results[i].usedDeprecatedRules. (this is not in RFC47, but is a part of RFC40. I found that report.usedDeprecatedRules requires the plugin uniqueness over multiple target files, but RFC47 overlooked it. Fortunately, RFC40 mentions the move of usedDeprecatedRules.)

Is there anything you'd like reviewers to focus on?

Nothing in particular.

[nzakas]

Does it make sense to make changes to CLIEngine now that we are deprecating it?

[mysticatea]

Yes.

1. RFC47 changes the common parts of CLIEngine class and ESLint class -- the logic of loading plugins.
2. RFC47 deprecates a problematic part of ESLint class -- rulesMeta depends on getRules(), but ESLint class doesn't have getRules() because it requires mutable state internally. The removal of rulesMeta is important for ESLint class.
3. Handling usedDeprecatedRules in CLIEngine class makes ESLint class implementation simpler and more correct.

[mysticatea]

I updated this PR:

• 1d8beae, 53f6407, and 24130c1 reverted deprecations in order to split PR.
• 3b2790f updated documentation.

[kaicataldo]

It looks like tests might be failing due to the issue described here.

[kaicataldo]

One small comment about the documentation formatting, but otherwise LGTM!

[btmills]

LGTM. Thank you for the thorough tests - they really helped!

[kaicataldo]

Thanks for working on this!

[bjmiller]

This PR utterly broke an important use case for me. Can there be a fix/patch that optionally restores the original behavior?

We have an organization-wide config that exists specifically so that people don't need to explicitly import all of the plugins in their local project. The command line option doesn't really help, but a flag in the local project's root config might.

[mysticatea]

No, we cannot add the option that changes how ESLint loads configuration files, into configuration files. You can restore the original behavior by --resolve-plugins-relative-to . option.

I'd recommend installing plugins into the same place as the config file that uses it. Otherwise, looks like package.json includes plugins but ESLint configuration doesn't use those.

And, it's good practice if your project configuration files include root: true in order to not use the configuration that came from outside of the project accidentally.

[bjmiller]

That's the problem. We need to primarily use the central configuration (and plugins), but still allow each project to add their own additional ones if they choose. And, if we add a plugin to the central configuration, we need that to propagate to all the projects without requiring them to change their local .eslintrc.js file.

Can there be a way to specify two directories in --resolve-plugins-relative-to, attempted in order?

[mysticatea]

You can use extends to extend shared configuration.

Can there be a way to specify two directories in --resolve-plugins-relative-to, attempted in order?

No. Previously, eslint loads all plugins from cwd. The --resolve-plugins-relative-to . is exactly same behavior as eslint 6.

[bjmiller]

Thank you for being patient, @mysticatea. I'll try using the command line option, and see if it works for what I need.

[arcanis]

Note that if you use the Yarn workspaces, you can make a workspace package containing your shared configuration, and make everything else depend on it. This way your shared plugins are properly scoped to your conf, and individual consumers can add their own additions if needed.