Do not always run eslint from the project's root directory

First off, thanks for all the great work you’ve been doing so far! 👍

I just ran into an issue:

I’m working on a project with a structure like this:

project
|- server-app
|- web-app-1
|- web-app-2

when I open vscode for a web-app via code /path/tp/project/web-app-1 vscode-eslint works as expected.

If I open the whole project via code /path/tp/project however I get plenty of linting errors on files that worked before. Errors look like:

Resolve error: ENOENT: no such file or directory, open /path/tp/project/package.json'  import/no-unresolved

and indeed, there’s no package.json in the project root. It’s in /path/tp/project/web-app-1/package.json

The output is the very same as if I did

cd /path/tp/project
node web-app-1/node_modules/eslint/bin/eslint.js web-app-1/src/path/to/file

So I assume vscode-eslint calls eslint from the project root, rather than from the web-app’s root which causes issues with e.g. eslint-plugin-import.

Is there a way to fix this? Maybe by looking for the root package.json for each .js file and calling eslint from its directory?

[dbaeumer]

I couldn’t get it to work either. I did the following enhancement. The workingDirectories take an object literal as well which allows you to tell ESLint to change the process.cwd as well. Changing this has to be used with care and is therefore off by default. A config looks like this:

{
	"eslint.workingDirectories": [
		{ 
			"directory": "web-app", 
			"changeProcessCWD": true
		}
	]
}

[danielberndt]

Thanks for the quick reply, @dbaeumer!

From my perspective the simplest approach seems to be to spin up one server per web-app. This would probably also make it quite straight forward to support various eslint versions and rules that might be present in each of the different web-apps.

And rather than guessing where to locate the web-apps, I personally would be fine with an option within the settings:

eslint.roots: ["."] //default
eslint.roots: ["./web-app-1". "./web-app-2"] // for the use case explained above

As a bonus the servers could be spun up lazily. I.e. if you’re not touching any file within web-app-2 its server is not started.