New: Simplify the resolution of third-party plugins/configs/parsers #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nzakas
requested changes
Jan 2, 2019
|
Updated to make the requested changes. I decided to keep the term "project root" at least for now, since the choice to make it equivalent to the CWD is an explicit design choice worth reviewing as part of the RFC. If the RFC gets approved, we can just refer to it as the CWD in documentation without introducing the term "project root". |
|
@eslint/eslint-tsc I'm moving this PR into the final commenting period, as described in the lifecycle documentation here. |
not-an-aardvark
added
Final Commenting
nzakas
approved these changes
Jan 29, 2019
|
I think this is a good near-term solution to some of the confusion we have with configs right now. 👍 |
kaicataldo
approved these changes
Jan 29, 2019
| ## Alternatives | ||
|
|
||
| * Along with configs/parsers, ESLint could load plugins relative to the configs that depend on them. That would introduce the possibility of having two plugins with the same name, requiring a disambiguation mechanism for configuring that plugin's resources; see [RFC #5](https://github.com/eslint/rfcs/pull/5) for an example. This RFC is intended to be a simpler step to solve some problems, while allowing additional work to proceed on that problem if desirable. | ||
| * To mitigate some compatibility impact, ESLint could fall back to the existing behavior when it fails to load a package using the new behavior, instead of throwing a fatal error. However, this would likely cause more confusion because users wouldn't understand why ESLint was finding their packages in certain cases, which would make it more difficult to debug problems. This fallback is only provided for the `espree` package (which falls back to the default parser if no user-installed version of the pacakge is found). |
There was a problem hiding this comment.
Agree with having less magic and making this easier to debug 👍
mysticatea
approved these changes
Jan 31, 2019
btmills
approved these changes
Jan 31, 2019
ilyavolodin
approved these changes
Jan 31, 2019
|
Finally something eslint agrees on :) |
|
The final comment period has been going on for over 7 days and there are 6 TSC members in favor with none opposed, so this RFC is accepted. |
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Feb 13, 2019
This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Feb 13, 2019
This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Feb 19, 2019
This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Feb 22, 2019
This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Feb 22, 2019
This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
not-an-aardvark
added a commit
to eslint/eslint
that referenced
this pull request
Apr 4, 2019
…1388) This change updates ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This simplifies ESLint's package-loading, resulting in fewer confusing errors about missing packages. It also fixes an existing design bug where ESLint would sometimes fail to load plugins in valid setups. Implements eslint/rfcs#7.
maxwell-k
added a commit
to maxwell-k/applications
that referenced
this pull request
Mar 10, 2020
Prefer to install inside node_modules of each project. A [RFC] for eslint proposed simplifying the process of package loading. This change was implemented in eslint 6.0.0 and [reduced the level of support] for installing plugins globally A ["highly dangerous and ugly package"] was published as a workaround. At the same time eslint addressed [another issue] about loading packages. After [this change] packages are loaded relative to where they are specified in a configuration file. One simple way for the configuration and the location of the configuration files to match is to install from the same `package.json`. [another issue]: eslint/eslint#10125 ["highly dangerous and ugly package"]: https://github.com/wintercounter/eslint-global-patch [rfc]: eslint/rfcs#7 [reduced the level of support]: https://eslint.org/docs/user-guide/migrating-to-6.0.0#plugins-and-shareable-configs-are-no-longer-affected-by-eslints [this change]: eslint/eslint@25cc63d
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This change would update ESLint to load plugins relative to the user's project root, and other packages relative to where they're specified in a config. This would simplify ESLint's package-loading, resulting in fewer confusing errors about missing packages. It would also fix an existing design bug where ESLint would sometimes fail to load plugins in valid setups.
Related Issues