fix(linter): prepend framework configs before baseConfig in flat config generation#34898
fix(linter): prepend framework configs before baseConfig in flat config generation#34898FrozenPandaz merged 1 commit intomasterfrom
Conversation
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit ce7c868
☁️ Nx Cloud last updated this comment at |
7cc74c4 to
5402a74
Compare
In flat config, later array entries override earlier ones. Framework generators appended predefined configs (flat/react, flat/angular, etc.) after baseConfig, causing framework rules to override user root rules. Implement the checkBaseConfig option in addBlockToFlatConfigExport to find the ...baseConfig spread element and insert before it. Framework generators pass checkBaseConfig: true so their configs are placed before baseConfig, giving user root config higher priority. When baseConfig is not found (root standalone projects), falls back to appending. Also scope the parser/plugins config entries in flat/typescript, flat/javascript, and flat/angular to their respective file types. Previously these entries had no files restriction, applying the TypeScript parser to all files globally (including .html, .json, etc.). This completes the scoping fix started in PR #28381 which only scoped the rules/extends but missed the parser entries. Refactor addPredefinedConfigToFlatLintConfig to use an options object instead of positional params for optional arguments.
There was a problem hiding this comment.
Important
At least one additional CI pipeline execution has run since the conclusion below was written and it may no longer be applicable.
Nx Cloud has identified a possible root cause for your failed CI:
We classified vue:build-base as an environment issue rather than a code change because the failure is caused by a missing devkit build artifact (dist/packages/devkit/index.d.ts), which is a CI pipeline dependency ordering problem unrelated to this PR's ESLint flat config changes. Our analysis confirms devkit is not in the set of touched projects, and the same error does not appear on master. Rerunning the pipeline after devkit:build completes should resolve this.
No code changes were suggested for this issue.
Trigger a rerun:
🔔 Heads up, your workspace has pending recommendations ↗ to auto-apply fixes for similar failures.
🎓 Learn more about Self-Healing CI on nx.dev
|
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
Current Behavior
Framework generators append predefined configs (
flat/react,flat/angular, etc.) afterbaseConfigin the flat config array. In flat config, later entries override earlier ones, so framework rules override user root rules.Additionally, the parser/plugins config entries in
flat/typescript,flat/javascript, andflat/angularhave nofilesrestriction, applying the TypeScript parser to all files globally — including.html,.json, and other non-TS/JS files. This was partially fixed in PR #28381 (which scoped rules/extends) but the parser entries were missed.Expected Behavior
Framework configs are inserted before
baseConfig, giving user root config higher priority. Root standalone projects (nobaseConfig) are unaffected.Parser/plugins entries are scoped to their respective file types, so
.htmlfiles get the correct parser (Angular template parser, or ESLint default) instead of the TypeScript parser.Changes
checkBaseConfigoption inaddBlockToFlatConfigExportto insert before...baseConfigwhen present@nx/react,@nx/angular,@nx/next, etc.) passcheckBaseConfig: trueflat/typescriptto**/*.ts, **/*.tsx, **/*.cts, **/*.mtsflat/javascriptto**/*.js, **/*.jsx, **/*.cjs, **/*.mjsflat/angularto**/*.tsaddPredefinedConfigToFlatLintConfigto use an options object for optional params[.]instead of\.— avoidsno-useless-escapelint errors and fixes a latent bug where\.in a string literal matched any character instead of a literal dotRelated Issue(s)
Fixes #32923