Failed to load globally installed configs/plugins

[justincorrigible]

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.

[Arcanemagus]

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:

linter-eslint/src/worker-helpers.js

Lines 105 to 118 in c14240d

	export function refreshModulesPath(modulesDir) {
	if (Cache.LAST_MODULES_PATH !== modulesDir) {
	Cache.LAST_MODULES_PATH = modulesDir
	process.env.NODE_PATH = modulesDir || ''
	// eslint-disable-next-line no-underscore-dangle
	require('module').Module._initPaths()
	}
	}
	export function getESLintInstance(fileDir, config, projectPath) {
	const modulesDir = Path.dirname(findCached(fileDir, 'node_modules/eslint') || '')
	refreshModulesPath(modulesDir)
	return getESLintFromDirectory(modulesDir, config, projectPath)
	}

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.

[justincorrigible]

linter-eslint brings in ESLint directly with require, 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... eslint/eslint#12450 (comment), 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 the modulesDir 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.

[justincorrigible]

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.