Repository navigation
fix: resolve exadev rules set by a block with no files after the shared config - #132
Conversation
…ed config A block placed after the shared config that sets an exadev rule and carries no files also applies to tsconfig.json, other JSON files and Markdown, where the plugin was not registered, so ESLint failed at config load with could not find plugin "exadev". The shared config now opens with a block that registers the plugin for every file. The rules that read JavaScript or TypeScript syntax, scope analysis or parser services return no listeners for a file of another language, so they no longer throw when such a block hands them one.
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
🎉 This PR is included in version 3.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
An unscoped block of this package's rules after the shared config (the shape the README documents for
exadev/barrel-policy,exadev/test-file-kindand others) fails at config load withcould not find plugin "exadev"in a repository that lints a JSON or Markdown file.The plugin was registered only in the blocks that select JS/TS files,
package.jsonand the files each preset wires. A block with nofilesalso applies totsconfig.json, other JSON and Markdown, and ESLint resolves the rule id per file. In 2.12.1 JSON was not linted at all, so such a block never reached one. Bisected against the published releases: with a plain*.jsonfile the first bad version is 2.14.0 (RFC 8785 canonical JSON bundled), with onlytsconfig*.json,turbo.jsonor*.jsoncit is 2.16.0 (JSONC config added). 2.12.1 to 2.13.0 and 2.15.0 respectively are fine.The shared config now starts with a block that registers the plugin and nothing else, so the namespace resolves for every file. Registering it was not enough on its own: ESLint then runs the rule on the JSON or Markdown source, and the rules that need scope analysis, parser services or a JSX program threw there. Each of them now returns no listeners unless the source is an ESTree
Program. JSON and Markdown rules declaremeta.languages, and ESLint refuses to enable those for a JS file by design, so they still needfiles; the README says so.The new integration test builds a temporary project with
tsconfig.json,package.json, plain JSON, Markdown and TypeScript, applies...exadevConfig()plus an unscoped rules block, and enables every non-JSON rule of the plugin in turn. It fails on 3.0.0 (44 of 46 cases) and passes here.