New: Plugin Loading Improvement

[mysticatea]

• Rendered RFC

Summary

This RFC changes ESLint to load plugins from the directory of the config files, so it fixes "plugin not found" errors for varied environments.

Related Issues

• New: add --resolve-plugins-relative-to flag eslint#11696 - New: add --resolve-plugins-relative-to flag
• Allow to specify plugin resolution in config eslint#12019 - Allow to specify plugin resolution in config
• ESLint fails to load plugins when using ESLint 6.x microsoft/vscode-eslint#696 - ESLint fails to load plugins when using ESLint 6.x
• Autodetect and propose working directories in mono repositories microsoft/vscode-eslint#708 - Autodetect and propose working directories in mono repositories
• New: Changing the Default Value of --resolve-plugins-relative-to #39 - New: Changing the Default Value of --resolve-plugins-relative-to
• New: ESLint Class Replacing CLIEngine #40 - New: ESLint Class Replacing CLIEngine
• New: Formatter v2 #45 - New: Formatter v2

[ilyavolodin]

General question. Why wouldn't we just use require.resolve for each plugin loaded in a given config file from the location of the config file? Unless --resolve-plugins-relative-to is provided.

[mysticatea]

True, this proposal intends to just use require.resolve to load each plugin from each config file.

But I thought we should warn confliction. For example, if there are the plugin foo in both ./node_modules/eslint-plugin-foo and ./subdir/node_modules/eslint-plugin-foo, then ./.eslintrc and ./subdir/.eslintrc load them, then it causes inunderstandable errors by the confliction.

[ilyavolodin]

Got it. Thanks for clarification. To be honest, I still think we are creating artificial constraints for ourselves. The whole scenario of using same plugin from multiple places/multiple versions doesn't seem like a real-world issue to me. I'm sure it will happen, but I'm also reasonably sure that it will be very rare and putting those constrains in on every design seems like an overkill to me.

[mysticatea]

I believe to print understandable errors are worthful regardless of the frequency, especially if the raw error is too difficult to find the cause.

[kaicataldo]

This is more a general topic, but I tend to agree with @ilyavolodin. While I agree that helpful error messages should be helpful, I don't think it should be a higher priority than an intuitive user experience.

[mysticatea]

Indeed, the shadowing that this RFC describes will not happen frequently. But if it happened, the error will appear as an "invalid option" or "rule not found" error. Please image that people opens an issue with the error. The error is too far from the cause, so I think that the validation in this RFC is worthful.

[ilyavolodin]

@mysticatea Oh, absolutely, I think we are on the same page on this. We should provide helpful error messages to point users to the correct solution (although, I can't say that it's been working out well so far). So just to clarify this RFC suggests using require.resolve to load plugins, but also provide meaningful error messages when plugin failed to load, correct?

[mysticatea]

Thank you for your feedback.

• I have updated this RFC largely to clarify. Now, this proposal clearly aims at loading plugins like require.resolve. Then it describes the plugin uniqueness in varied situations.
• I have changed about handling the --resolve-plugin-relative-to option. Now we can use the --resolve-plugin-relative-to option to rollback this change if a user needed.
• I have added about implementation. It will be simple changes.

[ilyavolodin]

Overall looks good. One question about performance.