Linting via nx can produce different outputs than the VSCode extension

[phwetteronline]

Current Behavior

When using ESLint (with flat config), it is possible to write rules for certain file pathes, with or without globs. If the configured path is explicitly relative to the project or workspace root, nx lint ... produces a different output than the ESLint extension for VSCode / invoking eslint path-to-file directly

Expected Behavior

nx lint .... should produce the same reports as when executing eslint path-to-file directly, especially should it produce the same results as the VSCode extension.

GitHub Repo

https://github.com/phwetteronline/nx-eslint-paths-bug-demo

Steps to Reproduce

0. Have VSCode with the ESLint extension installed (optionally clone the demo repo)
1. Create a new nx monorepo. I created an angular repo, but I guess the framework doesn't matter. When creating it, make sure eslint is included. What matters is, that the monorepo should include at least one project that has its own eslint.config.cjs
2. In the eslint config of the project, add some config that only applies to a specific file or file pattern. Make sure to write the file or pattern in such a way that it is relative to the workspace root / project root. For example "apps/my-app/src/some-file.ts" for a workspace root path or "src/some-file.ts" for a project relative path.
3. Run nx lint my-app. Compare the linting results with the ones from the VSCode extension. I expected them to be equal, but the are different, depending on which of the file patterns above is used (workspace root-relative or project-root-relative)

You will get results equal to the VSCode extension if you

1. cd apps/my-app
2. npx eslint src/main.ts

=> The Pathes inside the rules seem to be relative to the working directory where eslint is executed. I suppose the working directory is the monorepo root when running nx lint ... which explains the different interpretations of paths.

Nx Report

Node           : 22.13.1
OS             : linux-x64
Native Target  : x86_64-linux
npm            : 10.9.2

nx (global)            : 20.3.3
nx                     : 20.3.3
@nx/js                 : 20.3.3
@nx/jest               : 20.3.3
@nx/eslint             : 20.3.3
@nx/workspace          : 20.3.3
@nx/angular            : 20.3.3
@nx/devkit             : 20.3.3
@nx/eslint-plugin      : 20.3.3
@nx/module-federation  : 20.3.3
@nx/web                : 20.3.3
@nx/webpack            : 20.3.3
typescript             : 5.6.3
---------------------------------------
Community plugins:
angular-eslint : 19.0.2

Failure Logs

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[phwetteronline]

Okay, I have been thinking of a possible workaround and tried to place a config file deeper within the project structure. In my real case, we have some e2e tests inside the project, dirtree looks like this:

• apps
  • my-app
    • eslint.config.cjs
    • e2e
      • some more dirs and TS files
      • newly created eslint.config.cjs

I required the eslint config from the main project dir inside the e2e specific eslint.config.cjs and tried to extend it like this:

const baseConfig = require('../eslint.config.cjs');

module.exports = [
  ...baseConfig,
  {
    files: ['**/*.ts'],
    rules: {
      // ... my rules
    },
  },
];

Unfortunately, this does not work either.

Nx seems to statically use the eslint config at the project root. This can in fact be verified by adding console.logs to the config files. Here you can also see that it only consumes the apps/my-app/eslint.config.cjs, not the apps/myapp/e2e/eslint.config.cjs

The rules written in the e2e/eslint.config.cjs are reported as expected via VSCode extension, but they do not appear in the output of nx lint my-app

In my opinion this is also a misbehaviour, at least I understand the eslint-docs like: "start at the directory, where the file to be linted is, look for an eslint.config.[mc]?js, if there is none, repeatedly go one dir up, look for config file there, until a config file is found or / is reached.