Skip to content

fix: error on unknown rule names in config#1232

Draft
swwind wants to merge 3 commits into
mainfrom
fix/unknown-rule-config-validation
Draft

fix: error on unknown rule names in config#1232
swwind wants to merge 3 commits into
mainfrom
fix/unknown-rule-config-validation

Conversation

@swwind

@swwind swwind commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Summary

Unknown, misspelled, or unregistered rule names in rules (e.g. rules: { 'non-existent-rule-name': 'error' }) were silently ignored. The config-time validation step from #1243 now also resolves every enabled rule name, so unknown names are reported alongside rule-options failures. Rules set to "off" are exempt, same as ESLint.

  • internal/config: ValidateRuleOptions becomes ValidateRules(config, registry, eslintPlugins) — one pass collects unknown-name errors (unknown rule "x", unknown rule "p/x": plugin "p" has no such rule, unknown rule "p/x": plugin "p" is not registered) and options failures, deduplicated and sorted by rule name. Mounted ESLint-plugin rules resolve through the passed plugin entries, not the registry's placeholders — the placeholders may be unregistered yet at validation time, or stale leftovers from an earlier request in a long-lived process. Declaring a prefix under plugins grants no exemption: enabling a plugin's rules without supplying that plugin's rule names is an error.
  • CLI / IPC API: every failure is fatal — the CLI prints all failures and exits 1 before linting starts; the API rejects the request (and assembles its plugin entries before validating, so a metadata-free request can no longer resolve rule names through another request's stale placeholders).
  • LSP: failures are downgraded to logged warnings and the offending rules are set to "off" in the committed snapshot; every other rule keeps running and the config transaction commits normally. When the plugin host is degraded the catalog carries no plugin entries, so mounted plugin rules surface as harmless warnings instead of rejecting a valid config.

Breaking Changes

--rule with an unknown rule name now also fails with exit code 1 (previously silently ignored), matching ESLint's --rule behavior. Use "off" if you don't want a rule validated.

Related Links

Fixes #1228

Checklist

  • Tests updated (or not required).
  • Documentation updated (or not required).

Copilot AI review requested due to automatic review settings July 8, 2026 07:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Jul 8, 2026

Copy link
Copy Markdown

Deploying rslint with  Cloudflare Pages  Cloudflare Pages

Latest commit: 515e5bc
Status: ✅  Deploy successful!
Preview URL: https://3f940bec.rslint.pages.dev
Branch Preview URL: https://fix-unknown-rule-config-vali.rslint.pages.dev

View logs

@swwind
swwind marked this pull request as draft July 9, 2026 03:43
@swwind

swwind commented Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

We might implement this alongside with the new schema validation system. Hold short.

@swwind
swwind force-pushed the fix/unknown-rule-config-validation branch from 5295f45 to 515e5bc Compare July 15, 2026 04:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Unknown rules in configuration are silently ignored instead of throwing configuration errors

2 participants