Plugin in workspace not working anymore

[ChiefORZ]

From one day to the other the eslint plugin is not working for workspaces anymore... i have around 20 projects in my workspace and in every project is a yarn berry setup with the following config:

// project-a/.vscode/settings.json
{
  "eslint.nodePath": ".yarn/sdks",
  "eslint.workingDirectories": ["./frontend"],
  "search.exclude": {
    "**/.pnp.*": true,
    "**/.yarn": true
  }
}

when i open this project in a separate vscode window - it will work without any problems.

additional info:
when trying to selecting the node path in the workspace - it only offers the default

but when trying in the project itself it detects the eslint.nodePath defined in the settings.json

and outputs the correct loaded eslint library

[dbaeumer]

@ChiefORZ the root of this is the user confirmation that I added for the eslint.runtime setting to follow VS Code model (see https://github.com/microsoft/vscode-eslint/blob/main/README.md#version-2117)

This being said your setup should still work but needs some modifications which I have not thought about before. The short answer is: add the "eslint.nodePath": ".yarn/sdks" setting to your code-workspace file. Something like:

{
        "folders": [
                {
                        "path": "project-a"
                },
                {
                        "path": "project-b"
                }
        ],
        "settings": {
                "eslint.nodePath": ".yarn/sdks"
        }
}

Although the value can be defined in a workspace folder it was never honored as a different value across folders. The confirmation dialog now requires to have that value defined in the workspace folder.

I apologize for the breakage. Haven't thought about that case. Let me know if it addresses your problem?

[dbaeumer]

If it doesn't help can you point to to a git repository I can clone that demos what you are seeing

[shripadk]

@dbaeumer I had the same issue and yes your solution addresses the problem! I spent 3 hours wondering why ESLint just stopped working on me. Until I came across this issue. As you said above, adding "eslint.nodePath": ".yarn/sdks" to the code-workspace file works. Yarn 2 Berry auto-generates a .vscode/settings.json file (on pnpify) which also contains "eslint.nodePath": ".yarn/sdks". Is that now not going to be honoured? If so, then some sort of warning would help the developer know that they have to copy this line to code-workspace file too. Because this is clearly a breaking change.

Also, thank you for your work on VSCode ESLint. If not for ESLint being integrated into VSCode, I wouldn't bother much about formatting and linting. Would probably have been an afterthought. It definitely saves a lot of time and energy. Thanks again!

[dbaeumer]

@shripadk I apologize for this but that it worked in the past was more or less coincidence and not wanted. But I see the need to let users know about the fact the in a multi root workspace the settings need to be put into the settings setting of a code workspace. I will add a corresponding notification.

[dbaeumer]

I added a corresponding warning so that users are aware of this. The underlying reason for this not working in a multi folder setup is that I only start one node process and that therefore only one value can be used. This ensures that the right value is used.

[dbaeumer]

I will close the issue since I assume that this addresses @ChiefORZ problem as well.

[ChiefORZ]

re-opening the issue - i created a demo repository were we can discuss different things: https://github.com/ChiefORZ/vscode-eslint-workspaces

1. When we start on master, thats the setup that was always working for us - as @shripadk said yarn berry creates a .vscode/settings.json in each project, where the project's specific eslint version is pnpified (imagine project-a requiring eslint@^7.22.0 and project-b still using [email protected] - they are unfortunately not cross-compatible)
   so i imagine vscode-eslint correctly used multiple eslint instances depending on the workspace currently selected - am i right?

2. On the branch feature/nodepath-defined you can see that i tried to fix the issue by defining the eslint binding from project-a - but vscode-eslint runs into errors:
   

In the meantime i have to work with each project working in it's own window - but i have to admit, i really dont like it that way - the workspaces feature of vscode is a must-have <3

[ChiefORZ]

i now discovered that you can roll-back to a specific addon's version.
i rolled back vscode-eslint to v2.1.16, where everything is working perfectly fine.

[dbaeumer]

@ChiefORZ

As pointed out previously the eslint.nodePath value needs to be defined in the code-workspace file now since I need to let users confirm the value. To help identify this I show a notification and point that out now. When opening the workspace you provided I get the following notification:

Do you have a eslint.nodePath value globally defined (in the user settings)? Because that one would be used if present and would avoid showing the dialog.

After adding the value to the code-workspace file like this:

{
	"folders": [
		{
			"name": "project-a",
			"path": "project-a"
		},
    {
			"name": "project-b",
			"path": "project-b"
		}
	],
	"settings": {
  		"eslint.nodePath": ".yarn/sdks"
	}
}

I get the following dialog

After Confirming the nodePath value ESLint works for me and the different versions are loaded from each project.

The confirmation step is necessary due to VS Code's advice that settings that alter the execution behavior of launched programs need to ask for user consent.

[arcanis]

The confirmation step is necessary due to VS Code's advice that settings that alter the execution behavior of launched programs need to ask for user consent.

Kind off topic, but it'd be nice if there was a single switch to all such usages (from a same project). Currently engs at my company have to accept using the repository binaries for each of ESLint, Prettier, and TS (and probably others I forget).

[dbaeumer]

@arcanis This will come. See Trusted Workspaces on the VS Code plan: microsoft/vscode#118334