Error: Cannot read config package for shareable config using global eslint #4822
Labels
archived due to age
This issue has been archived; please open a new issue for any further discussion
triage
An ESLint team member will look at this issue soon
Running the following steps, which currently installs ESLint v1.10.3, results in the following error:
If the last command is replaced with
./node_modules/.bin/eslint index.js
the command completes without error. The error appears to result from"extends": "algolia"
being translated torequire("eslint-config-algolia")
which fails when run from a globaleslint
installation becauseeslint-config-algolia
is not installed globally.This has a few obvious workarounds:
eslint-config-algolia
can be installed globally. The downside is that now developers must determine which eslint modules a project requires, then install them globally before linting. It's workable, but painful for developers, and especially painful to new project contributors who are more likely to either forgo linting or contributing.extends
declaration can be made relative in.eslintrc
(e.g. by changing"extends": "algolia"
to"extends": "./node_modules/eslint-config-algolia/index.js"
or similar - and recursively for transitive dependencies). This appears to be a common idiom but it is both verbose and requires all transitive dependencies to use this strategy (which may be out of a project's control, and is not currently ubiquitous).eslint
can always be invoked through the project-local installation innode_modules
. This is both workable and has the added benefit of allowing projects to require a specific version ofeslint
. But it requires all programs which invoke eslint to comply, which is reasonably difficult to enforce on an ongoing basis. Nearly all programs I checked currently assumeeslint
is installed in$PATH
, which does the right thing when invoked vianpm run
but the wrong thing when launched by a user (e.g. via editor tools).There are likely other workarounds that I haven't considered. Even if such workarounds are generally straightforward, the current situation leaves some developers with an error message that they have to investigate and fix. It would be great if this pain could be avoided by a change to ESLint. For example, would it be possible to resolve referenced modules (config, plugin, etc.) relative to the current package and fallback to global resolution only if local resolution fails?
Thanks for considering,
Kevin
Note: There is some overlap with #3458, and a solution to either issue might affect the other.
The text was updated successfully, but these errors were encountered: