Open justincorrigible opened 4 years ago
The solution offered by them is to use the --resolve-plugins-relative-to CLI option, which linter could have as its default, should the user enable using the global config.
linter-eslint
brings in ESLint directly with require
, it's not using the CLI interface. That being said... we already do this in the worker thread that runs ESLint:
https://github.com/AtomLinter/linter-eslint/blob/c14240d59a6b9aceaa58516d377521806bac806f/src/worker-helpers.js#L105-L118
Are you sure that the modules are installed at the same level as eslint
? If so, you could try adding a console.log
in there to see what the modulesDir
is getting resolved to make sure it's grabbing the right directory.
linter-eslint
brings in ESLint directly withrequire
, it's not using the CLI interface.
In this case, the global settings are not really global, as they still do require for you to install the plugins and ext-configs locally in the project.
I'm playing around with an option found in this ticket... https://github.com/eslint/eslint/issues/12450#issuecomment-542988227, which seems to work for the ext-configs (airbnb in my case), though I haven't quite figured out how to use for the plugins (because of the syntax. e.g. plugin:react/recommended
.)
Are you sure that the modules are installed at the same level as
eslint
?
That's right, as you can see at the bottom of the screen capture, which shows the global node_modules, which matches npm ls -g eslint
.
If so, you could try adding a
console.log
in there to see what themodulesDir
is getting resolved to make sure it's grabbing the right directory.
It doesn't seem to be, as it's just logging out .
.
However, fileDir
seems to be the folder that contains one of the files I have opened in a different tab, which makes me think that .
refers to the project itself.
Afterwards, in line 117, it takes to getESLIntFromDirectory
-> findESLintDirectory
, which in turn disregards modulesDir
when useGlobalEslint
is on; and that's how it finds my global ESLint regardless.
ESLint won't take the global modules by default, so we may have to play with the cliEngineOptions
instead. WIll check through their documentation and see if we can use a mix of the .resolvePluginsRelativeTo
and the resolve
approach from that issue mentioned above.
This seems to do part of the trick, indeed:
(I know it looks hacky, just trying to get it to work first, and clean up later 😜)
Edit: It works well by combining this little change in linter-eslint
with the configs + parsers being resolved directly. Will do some research on how to not depend on modifying the config file, and then open a PR with my changes.
Issue Type
Feature request. Hopefully, ideas for an interim solution without modifying my project's codebase?
Issue Description
The project I'm working on consists of an otherwise empty folder that contains a few individual projects, with their own package.JSON, etc. (microservices for the same app, so to say.) Since the parent folder is a mere container, I'd prefer using a global single ESLint config file, which is stored at '~' (a.k.a. personal configs, which are getting deprecated from the automatic lookup as of their v7.0; still available using
--config
afterwards.)Linter seems unable to find the globally installed plugins due to ESLint's own limitation while using global config files as described here.
The solution offered by them is to use the
--resolve-plugins-relative-to
CLI option, which linter could have as its default, should the user enable using the global config. In theory, the dependencies would be in the same 'node_modules' as ESLint itself. Alternatively, this package could offer an settings input field to manually set custom flags to be given to the CLI. 🤔Bad idea? I could try opening a PR if the maintainers see this as something useful.