nx 18 - linting error after upgrade cannot exclude projects
Current Behavior
After upgrading to nx 18 project without a lint target are being linted when running nx run-many --all --target=lint
Expected Behavior
since the project doesn't contain a lint target in its config it should be ignored.
✖ nx run theming:lint
Oops! Something went wrong! :(
ESLint: 8.48.0
You are linting ".", but all of the files matching the glob pattern "." are ignored.
If you don't want to lint these files, remove the pattern "." from the list of arguments passed to ESLint.
If you do want to lint these files, try the following solutions:
* Check your .eslintignore file, or the eslintIgnore property in package.json, to ensure that the files are not configured to be ignored.
* Explicitly list the files from this glob that you'd like to lint on the command-line, rather than providing a glob as an argument.
Warning: run-commands command "eslint ." exited with non-zero status code
GitHub Repo
No response
Steps to Reproduce
- create a workspace
- add a lib
- make sure there is no lint target in project.json
- run
nx run-many --all --target=lint
Nx Report
Node : 18.16.0
OS : darwin-arm64
yarn : 1.22.4
nx (global) : 16.3.2
nx : 18.0.2
lerna : 4.0.0
@nx/js : 18.0.2
@nx/jest : 18.0.2
@nx/linter : 18.0.2
@nx/eslint : 18.0.2
@nx/workspace : 18.0.2
@nx/angular : 18.0.2
@nx/cypress : 18.0.2
@nx/devkit : 18.0.2
@nx/eslint-plugin : 18.0.2
@nrwl/tao : 18.0.2
@nx/web : 18.0.2
@nx/webpack : 18.0.2
typescript : 5.3.3
---------------------------------------
Community plugins:
@compodoc/compodoc : 1.1.19
@ngrx/component-store : 17.0.1
@ngrx/store : 17.0.1
ng-mocks : 14.12.1
Failure Logs
No response
Package Manager Version
No response
Operating System
- [X] macOS
- [ ] Linux
- [ ] Windows
- [ ] Other (Please specify)
Additional Information
Alternatively, the ability to configure exclusions would be helpful if the intent is to be bullish on linting.
Hi there @LPCmedia ! Thanks for filing an issue. I think your issue may be related to our recent changes with Inferred Tasks. If your project has a eslint config file (list of files can be found here: https://nx.dev/nx-api/eslint#how-nxeslint-infers-tasks), it will be linted. So even if you don't see a lint target in project.json, if you have a eslint config file, it will be linted.
If that is not your issue, let me know and I will look into it more.
I have the same issue.
Have a docs/ folder for my empty(isch) storybook project for the whole workspace.
(https://nx.dev/recipes/storybook/one-storybook-for-all)
It has NO .eslintrc.json file.
But it is still linted (by the auto generated target) when running:
npx nx run-many --all --target=lint --fix
When looking in the Nx Console it lists the following targets for docs
- nx-release-publish
- lint
- build-storybook
- storybook
- test-storybook
- static-storybook
- build
So I guess lint and nx-release-publish should not be available?
(nx-release-publish is visible for each project.. but I'm not using it.. -> dealing with Jenkins sadly)
nx run docs:lint
Oops! Something went wrong! :(
> NX Running target lint for 23 projects
ESLint: 8.56.0
With additional flags:
You are linting ".", but all of the files matching the glob pattern "." are ignored.
If you don't want to lint these files, remove the pattern "." from the list of arguments passed to ESLint.
If you do want to lint these files, try the following solutions:
⠙ nx run docs:lint
* Check your .eslintignore file, or the eslintIgnore property in package.json, to ensure that the files are not configured to be ignored.
* Explicitly list the files from this glob that you'd like to lint on the command-line, rather than providing a glob as an argument.
> NX Report complete - copy this into the issue template
Node : 20.11.0
OS : win32-x64
npm : 10.1.0
nx : 18.0.2
@nx/js : 18.0.2
@nx/jest : 18.0.2
@nx/linter : 18.0.2
@nx/eslint : 18.0.2
@nx/workspace : 18.0.2
@nx/angular : 18.0.2
@nx/cypress : 18.0.2
@nx/devkit : 18.0.2
@nx/eslint-plugin : 18.0.2
@nx/playwright : 18.0.2
@nx/storybook : 18.0.2
@nrwl/tao : 18.0.2
@nx/web : 18.0.2
@nx/webpack : 18.0.2
typescript : 5.3.3
---------------------------------------
Community plugins:
@compodoc/compodoc : 1.1.23
@ngrx/operators : 17.1.0
@ngrx/signals : 17.1.0
@storybook/angular : 7.6.12
@testing-library/angular : 15.2.0
ngxtension : 2.0.0
The .eslintignore seems to be ignored as well. (but that might be a separate bug 🤔 )
@mandarini
Thanks for the reply, I can confirm that both libs do NOT have an eslint config file.
I ran into the same issue with projects that have a root .eslintrc.json but no {projectRoot}/.eslintrc.json in a spesific project that dosn't contains any js files.
And so, getEslintConfigsForProject always returns at least one item expect from the root package.json since there is always one .eslintrc.json at the root of the workspace.
Here is a workaround in the meantime to get you unstuck, a custom Nx plugin to filter out the bad targets :
import { CreateNodes } from '@nx/devkit';
import {
createNodes as eslintCreateNodes,
EslintPluginOptions,
} from '@nx/eslint/plugin';
import { dirname } from 'path';
const [eslintGlob, eslintSetup] = eslintCreateNodes;
export const createNodes: CreateNodes<EslintPluginOptions> = [
eslintGlob,
async (configFilePath, options, context) => {
// Call the original Nx eslint plugin
const originalResult = await eslintSetup(configFilePath, options, context);
// If the object returned is {}, we don't need to do anything
if (Object.keys(originalResult).length === 0) {
return originalResult;
}
// Extract the inputs from the original result
const inputs = Object.values(originalResult?.projects)[0].targets[
options.targetName
].inputs;
// Look for a eslint config in the project root
const projectRoot = dirname(configFilePath);
const includesProjectRoot = inputs.some(
(value) => typeof value === 'string' && value.includes(projectRoot)
);
// No eslint config found in the root of the project, skipping
if (!includesProjectRoot) {
return {};
}
// Return original result
return originalResult;
},
];
import the plugin file from the nx.json instead of the official nx plugin and you should be good to go until this get fixed in Nx direclty! I can open a Pr to fix it upstream but I'm not sure if this expected behaviour or not
It's also possible to override lint target in a project. Project configuration has higher priority than inferred plugins.
https://nx.dev/concepts/inferred-tasks#overriding-inferred-task-configuration
Add a dummy command for example.
libs/shared/styles/project.json
"targets": {
"lint": { "command": "echo Ignored in project configuration!" }
},
nx lint shared-styles --skip-nx-cache
> nx run shared-styles:lint
Ignored in project configuration!
...
nx report --version
18.0.3
i got the same error, but i had an eslintrc.json and also wanted to lint, but the ignorePatterns was ignored. i created an .eslintignore with the content
!**/*
and then it worked again.
I'll see if I can reproduce it in an empty project in the next few days
The docs for the eslint plugin state:
Because ESLint applies configuration files to all subdirectories, the @nx/eslint plugin will also infer tasks for projects in subdirectories. So, if there is an ESLint configuration file in the root of the repository, every project will have an inferred ESLint task.
I think this is surprising and frustrating behaviour, as we often want a 'base' eslintrc.json config in the root dir, but don't want every project in the monorepo to be linted.
Workarounds:
Option 1. Rename the base .eslintrc.json file
E.g., change it to .eslintrc.base.json.
Question for the nx team: Will this mean we miss potential future migrations of this file when we run nx migrate?
Option 2. Configure a noop lint executor
In project.json where you don't want linting add this:
{
"targets": {
"lint": { "executor": "nx:noop" }
}
}
Unfortunately for us, we're getting some inferred "projects" in our github actions folders containing package.json files 🙄. We could add project.json files to these too, with the noop executor though.
Option 3. Remove the plugin from nx.json
In your nx.json file, remove the @nx/eslint/plugin entry from the plugins array, then it will no longer automatically infer projects.
Any projects with a lint target explicitly configured in their project.json will still get linted, so there's no ill effects.
This is really annoying. We're generating prisma clients into libraries like foo/prisma-client/src/generated
Prisma writes there the client js and d.ts files alongside the package.json. Which then is treated as project by nx and it tries to lint it. Even if the foo/prisma-client/project.json has the dummy lint target.
In the result the foo-prisma-client project is not linted, but the prisma generated thing is linted. So we see errors like that:
✖ nx run prisma-client-e99a320803e0acf230d3e12286994a4c0540fc5a7f25c78cd5ffc2ef9c04d028:lint
Oops! Something went wrong! :(
ESLint: 8.57.0
You are linting ".", but all of the files matching the glob pattern "." are ignored.
If you don't want to lint these files, remove the pattern "." from the list of arguments passed to ESLint.
If you do want to lint these files, try the following solutions:
* Check your .eslintignore file, or the eslintIgnore property in package.json, to ensure that the files are not configured to be ignored.
* Explicitly list the files from this glob that you'd like to lint on the command-line, rather than providing a glob as an argument.
Warning: command "eslint ." exited with non-zero status code
prisma-client-e99a320803e0acf230d3e12286994a4c0540fc5a7f25c78cd5ffc2ef9c04d028 is the name in the generated package.json
This issue was fixed by https://github.com/nrwl/nx/pull/22944 and released in Nx v18.3.4. Please update your Nx version to at least that version to get the fix.
The @nx/eslint plugin will correctly consider the configuration of the ESLint ignored files. Please ensure your ESLint configuration correctly excludes anything you don't want linting running for.
If you still have issues after updating, please create a new issue with clear reproduction steps, and we'll look into it.
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.