New: Changing the Default Value of --resolve-plugins-relative-to

[mysticatea]

Summary

This RFC changes the default value of --resolve-plugins-relative-to CLI option to work on more varied environments.

Related Issues

• New: add --resolve-plugins-relative-to flag eslint#11696 - New: add --resolve-plugins-relative-to flag
• Personal config (~/.eslintrc) doesn't load global-installed configs/parsers/plugins eslint#11914 - Personal config (~/.eslintrc) doesn't load global-installed configs/parsers/plugins
• 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

[kaicataldo]

LGTM

[zbrogz]

Can this be merged?

[kaicataldo]

@zbrogz Please read the documentation here about our RFC approval process.

[platinumazure]

I've identified one small typo (provided a suggestion to hopefully make the fix trivial).

Two questions:

1. Just to confirm: For the case where someone is using --config without --resolve-plugins-relative-to but has plugins installed in their project, they can fix by simply adding something like --resolve-plugins-relative-to ., right?
2. As an alternative, would it make more sense to always try resolving packages from the location of config files first, and only fall back to --config and --resolve-plugins-relative-to if they are not found attached to the config files? (I'm thinking of monorepo cases where someone could break the linting workflow by trying to use --resolve-plugins-relative-to . without realizing that some of the plugins are in sub-packages. My understanding of this RFC is that --resolve-plugins-relative-to completely stops any other plugin searching, and I wonder if the UX would be better if we implicitly always searched for plugins that are installed next to config files.

[mysticatea]

Just to confirm: For the case where someone is using --config without --resolve-plugins-relative-to but has plugins installed in their project, they can fix by simply adding something like --resolve-plugins-relative-to ., right?

Yes, you are right.

As an alternative, would it make more sense to always try resolving packages from the location of config files first, and only fall back to --config and --resolve-plugins-relative-to if they are not found attached to the config files?

It sounds a good idea. I didn't think to load plugins from multiple bases. I will consider it.

[platinumazure]

Current RFC text looks good to me, but please let me know what you think about my alternative proposed plugin load strategy (once you have thought about it some more).

[mysticatea]

I rollbacked this RFC from the final commenting because I have a plan to update this RFC largely.

This RFC has a problem in CLIEngine#getRules() and formatter's rulesMeta property because when ESLint verifies multiple files, it loses the guarantee of the identification of plugin rules.

[mysticatea]

I have separated this RFC to #39 (this) and #47.

• New: Changing the Default Value of --resolve-plugins-relative-to #39 is minimal now. It just uses the directory of --config option as the value of --resolve-plugins-relative-to option. This will be convenient as a successor of personal config file functionality.
• New: Plugin Loading Improvement #47 is the proposal that tries to solve the monorepo problem. That's a large spec a bit.

[kaste]

This feels so unproductive. I'm basically saying: This is poor wording, and you keep telling me how the software works.

### About personal config file (`~/.eslintrc`)

This RFC is essentially unrelated to the handling of personal config files. In particular, we do 
not detect if the user provides `--config ~/.eslintrc` and handle it any different. Therefore, with 
this in effect, we would set `resolvePluginsRelativeTo` to the HOME dir in such cases. This can 
confuse users which might expect we handle a personal config file differently i.e. by instead 
resolving globally installed packages. It could also encourage users to install into the HOME dir. 
However, we clearly do not recommend users install anything into `~/node_modules`. 

Something like that. So I basically change "intuitively" to "confuse".

Does that help?

[kaste]

Add

• Given a personal config file, user might feel encouraged to install packages into the HOME dir. See discussion above.

Probably remove "The new logic is complex a bit" because it is not.

[kaste]

Also, just to make it clear (and, yes, I know that I'm coming from nowhere here, and leave comments in a repo I may not belong to). IMO (and as a Windows user) a) this is YAGNI and probably has more maintenance cost as the core change, b) this is unrelated and should get its own RFC.

[mysticatea]

I'm closing this RFC because I re-thought that we should not change the default value of --resolve-plugins-relative-to option by --config option while I refresh #47.

Thank you for many feedbacks. Because #47 is the successor of this RFC, please track that!