Regression after switching to pre-release - Eslint no longer loading against project files.

[cefn]

Eslint was loaded and the files were successfully linted inline by the release version on the project using 8.57.0 and flat configs, if project paths were explicitly listed in the workspace settings.json.

I upgraded to the pre-release version to try and get better support for eslint flat configs in the hope that {mode:"auto"} could be made to work. Unfortunately, the pre-release version fails to load Eslint or to show linting errors against files even with projects explicitly listed. The previously working workspace settings.json is below.

{
  "eslint.workingDirectories": [
    "apps/counter-dom-commonjs",
    "apps/counter-dom-esm",
    "apps/counter-dom-tiny",
    "apps/counter-dom-ts",
    "apps/counter-preact-ts",
    "apps/counter-react-js",
    "apps/counter-react-ts",
    "apps/counter-react-ts-edit",
    "apps/fast",
    "apps/tiny",
    "packages/nevermore"
  ],
  "eslint.experimental.useFlatConfig": true
}

I noted the requirement to switch from "eslint.experimental.useFlatConfig": true to "eslint.useFlatConfig": true. Neither works to bring back eslint integration for the pre-release version of the eslint extension.

The requirement to create configs with explicit paths is an unnecessary failure mode and is a productivity issue. On both release and pre-release the use of [{mode:"auto"}] to list the project paths was non-functional, in spite of all workspace globs being explicitly declared in the top-level package.json.

You could prove eslint was previously loading against the files by clicking on the {} control at the bottom right of the VSCode editor, which showed eslint as one of the integrations, and also it was previously redlining linting errors in the source files of the explicitly-listed projects.

My monorepo commit which recreates the failure is https://github.com/cefn/watchable/tree/03844d8468c9e88e6d6ef93a0e5e773ea4a69d60

[dbaeumer]

I tried to clone the repository but the commit 03844d8468c9e88e6d6ef93a0e5e773ea4a69d60 doesn't exist.

So I cloned head , run npm instal and opened the workspace with `3.0.5-pre-release and it works for me out of the box

Any additional steps on how to reproduce this?

[jludwiggreenaction]

I noticed the same behavior on the current release where mode: auto no longer is working. For me, I can see the issue in any repo where there are multiple eslint configs -- usually mode: auto handles that.

Although eslint does attach to the file, there are simply no messages/diagnostics reported from the eslint server.

[dbaeumer]

@jludwiggreenaction do you have a repository I can clone that demos that.

[cefn]

Sorry to make life difficult, @dbaeumer .

For reference, below is a procedure to check out a commit to a named branch. It would have been easier if I provided you with a branch name alias already pushed rather than just the commit hash.

git clone git@github.com:cefn/watchable.git
cd watchable
git checkout -b eslint-failure # for convenience
git fetch origin 03844d8468c9e88e6d6ef93a0e5e773ea4a69d60
git reset --hard 03844d8468c9e88e6d6ef93a0e5e773ea4a69d60

...gets you to...

commit 03844d8468c9e88e6d6ef93a0e5e773ea4a69d60 (HEAD -> eslint-failure)
Author: Cefn Hoile <github.com@cefn.com>
Date:   Sun Apr 28 12:37:37 2024 +0100
    Fix promise array typing. Update typescript, eslint

For now I've pushed that commit to https://github.com/cefn/watchable/tree/eslint-failure so it's easier to check it out.

[dbaeumer]

@cefn still not able to reproduce. Here is what I see on branch eslint-failure