Detect root via lockfiles; do not treat package.json as root

[kapral18]

Fixes #2077

• Stop marking package.json as a project root by itself in projectFolderIndicators
• Treat lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb etc...) as roots
• Add workspace/monorepo markers (pnpm-workspace.yaml, lerna.json, nx.json, rush.json, .yarnrc.yml) as roots
• Preserve flat config priority via existing eslint.config.* entries
• Refactor logic to prefer flat configs at/above lockfile roots (ESLint best practices)
• Fall back to uppermost package.json when no lockfiles exist
• Performance: Use single fs.readdirSync per directory instead of multiple fs.existsSync calls

This ensures auto working directory detection stops at real project roots (lockfiles) while allowing nested package.json without lockfiles to bubble up to where root configs live. The refactored logic is more modular, performant, and follows ESLint flat config best practices.

A few examples of package.json-containing packages that are not roots:

https://github.com/remix-run/react-router/blob/main/packages/react-router/package.json
https://github.com/elastic/kibana/blob/main/packages/kbn-dependency-usage/package.json
https://github.com/facebook/react/blob/main/packages/react-art/package.json

[dbaeumer]

@kapral18 thanks for the PR.

Should the logic not be like this:

• if it has a packag.json and one of the lock files take it as the root
• if it has only a package.json traverse upwards. In not better match is found treat that one as the root.

[kapral18]

@kapral18 thanks for the PR.

Should the logic not be like this:

• if it has a packag.json and one of the lock files take it as the root
• if it has only a package.json traverse upwards. In not better match is found treat that one as the root.

yes that + logic for flat config files also signaling root, would be a better root detection probably, especially considering that there can be eslintConfig blocks inside package.json (which are no longer supported in v9+ but still)

[kapral18]

@microsoft-github-policy-service agree

[kapral18]

@dbaeumer I split the indicators into semantic groups so that the priority and connection is a little clearer to read and easier to work with. Priority is handled a little more explicitly I think now, but check out and let me know what you think? I didn't add test infrastructure to avoid exploding this PR's size since there is no testing infra for server available in the first place. But I tested locally so let me know if this can work

[kapral18]

@dbaeumer actually I just realized that this very repository is breaking my assumptions about eslint.config.js usage. In my proposal I am looking at eslint.config.js as a primary boundary indicator superior to lock files, because flat config files like eslint.config.js are supposed to be used in project roots, but here you have lock roots and eslintrc.js root file in server and client respectively while putting an eslint.config.js on the .git root level. Can you kindly help me understand what is the grand design here?

[dbaeumer]

@kapral18 the eslintrc.json files are obsolete and not needed anymore. I deleted them.

[kapral18]

@dbaeumer I still see them in https://github.com/microsoft/vscode-eslint/blob/main/server/src/eslint.ts#L816 or what do you mean? Do you mean VSCode extension no longer supports .eslintrc.json files specifically?