fix(config): don't enable rules with domains when categories are enabled

[dyc3]

Summary

When a user enables an entire category of rules, Biome shouldn't enable rules that have domains if those domains aren't enabled.

One question from a UX perspective is: should --skip=correctness have the same behavior, or should it skip all of the rules that are in correctness, even if a rule is manually enabled and outside the enabled domains?
Also: should project and typed be excluded from this behavior?

From an issue raised on discord: https://discord.com/channels/1132231889290285117/1132231889911029825/1484172669854416978

Generated by gpt 5.4, but the change is fairly small.

This is on main because I consider it unintentional behavior, particularly because recommended rules behavior already excluded domain-tagged rules. But an argument could be made that this is a breaking enough change to go on next instead.

Test Plan

added cli tests

Docs

TODO once we've figured out the semantics here

[changeset-bot]

🦋 Changeset detected

Latest commit: 7f088c0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@biomejs/biome	Patch
@biomejs/cli-win32-x64	Patch
@biomejs/cli-win32-arm64	Patch
@biomejs/cli-darwin-x64	Patch
@biomejs/cli-darwin-arm64	Patch
@biomejs/cli-linux-x64	Patch
@biomejs/cli-linux-arm64	Patch
@biomejs/cli-linux-x64-musl	Patch
@biomejs/cli-linux-arm64-musl	Patch
@biomejs/wasm-web	Patch
@biomejs/wasm-bundler	Patch
@biomejs/wasm-nodejs	Patch
@biomejs/backend-jsonrpc	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

Merging this PR will not alter performance

✅ 1 untouched benchmark
⏩ 215 skipped benchmarks¹

---

_{Comparing dyc3/broad-rule-filter-adjust (17d722f) with main (607ebf9)}

Footnotes

1. 215 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ematipico]

Assuming users don't have any dependencies that enable a particular domain, I think it's fair to consider this current behaviour a bug.

As for --skip and --only, I believe this doesn't count. These options are meant to mirror the intent of the user, and they are also meant to bypass the defaults.

For example, if you have noDebugger disabled and you run --only=noDebugger, the CLI applies noDebugger. Same for the other way around, if noDebugger is enabled in your configuration, but then you run --skip=noDebugger, Biome should skip it.

So, to answer your question: no, --skip=correctness should NOT run all rules in that group.

Same for --only=correctness, Biome should run all rules that belong to correctness. Users can mix and match if they need, which would solve the problem of OP (Discord) in case they want to surgically run the CLI:

biome lint --only=correctness --skip=qwick

While I understand that it isn't ideal, it's also true that we have rules that don't play well with each other, and that's a known fact. Users will come to understand how things work. (still, we need to fix the default behaviour)

[dyc3]

Makes sense to me, i've reverted the behavior changes to --only and --skip

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fa8b84cd-0c5a-492f-9c61-f7f583cb046f

📥 Commits

Reviewing files that changed from the base of the PR and between 7f088c0 and 17d722f.

📒 Files selected for processing (1)

• .changeset/fix-domain-group-enables.md

✅ Files skipped from review due to trivial changes (1)

• .changeset/fix-domain-group-enables.md

---

Walkthrough

A changeset and tests were added to ensure enabling a whole linter rule group (e.g. linter.rules.correctness = "error") no longer implicitly enables rules that are scoped to specific domains (like React or Qwik). A new trait accessor non_domain_rules_as_filters() and generated NON_DOMAIN_RULES_AS_FILTERS exclude domain-tagged rules from plain group-level enables; group-level logic now uses these non-domain filters. Several CLI tests were added/updated to assert group-enable and domain-enable behaviours are additive and distinct.

Possibly related PRs

• fix(lint): enable rules via dependencies when setting domains in config #8658: Changes domain-aware rule-enabling logic in the file handlers/service layer that affects when domain-tagged rules are activated.
• feat(lint): move some rules to the react domain #7548: Moves specific lint rules into the React domain, making them subject to the new group-enable/domain-enable distinction.

Suggested labels

A-Linter, A-Tooling

Suggested reviewers

• ematipico

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main fix: preventing domain-tagged rules from being enabled when only their parent category is enabled.
Description check	✅ Passed	The description explains the motivation, references the relevant Discord discussion, discloses AI assistance, and documents open UX questions about the implementation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dyc3/broad-rule-filter-adjust

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}