Biome 08 🧹 The Recommended Ruleset — What’s on by default
The Biome linter runs only the recommended rules by default. This is the first thing to understand about the default configuration: a project that adds Biome and does nothing else gets a curated set of rules that the Biome team considers the baseline for correctness and good practice . The recommended rules emit diagnostics with the error severity, which means they fail the CLI and the CI pipeline . The recommended set is not every rule that Biome ships; it is a subset, and the subset is the mechanism that keeps the default configuration useful without being overwhelming.
The recommended flag is the single switch that controls the whole set. The "recommended": true is the default, and the "recommended": false disables the entire curated set, which is the mechanism for a project that wants only the few rules it explicitly lists . The recommended rules are spread across the groups—the correctness rules that catch the definite errors, the suspicious rules that catch the likely errors, and the a11y rules that catch the accessibility problems. The recommended set is the baseline, and the explicit rules are the refinement.
Key point: The Biome linter runs only the recommended rules by default. The recommended rules emit the error severity, which fails the CLI and the CI. The "recommended": false disables the whole set, and the explicit rule configuration is the mechanism that enables the rules that are not in the recommended set. The recommended rules are a subset of the rules that Biome ships, not the complete set.
Why the recommended set is the default
The curated baseline problem. A linter that enables every rule by default produces hundreds of diagnostics on a new project, and the developer cannot distinguish the important ones from the noise. The recommended set is the curated baseline, and the curation is the mechanism that makes the default configuration useful . The recommended rules are the ones that the Biome team considers the minimum for a healthy codebase, and the set is the starting point rather than the complete configuration.
The severity problem. The recommended rules emit the error severity, and the error fails the CLI . The default configuration is therefore strict: a project that adds Biome and runs the check command will fail on the recommended violations. The strictness is the mechanism that makes the default useful, and the --error-on-warnings is not needed for the recommended set because the severity is already error.
The disable problem. A project that wants only a few rules sets "recommended": false and lists the rules it wants. The disable is the mechanism that turns off the whole curated set, and the explicit rules are the refinement . The "recommended": false is the escape hatch for the project that finds the curated set too broad.
The domain problem. The recommended set is not the only default. The domains—the react, the next, the test, and the others—are the technology-specific rule sets that the project can enable. The linter.domains.react: "recommended" enables the React-specific recommended rules, and the domain is the mechanism that adds the technology-specific checks to the baseline . The domain is the refinement of the recommended set, and the combination is the complete configuration.
a. The recommended rules across the groups
The recommended rules are spread across the groups. The correctness group has the rules that catch the definite errors, and the noUnusedVariables and the noUnusedImports are the recommended rules in that group . The suspicious group has the rules that catch the likely errors, and the noDebugger and the noDoubleEquals are the recommended rules in that group . The a11y group has the accessibility rules, and the useAltText and the useAnchorContent are the recommended rules in that group .
// biome.json — the recommended set is on by default
{
"linter": {
"rules": {
"recommended": true
}
}
}
The recommended: true is the default, and the configuration above is the explicit form of the default. The recommended rules are enabled, and the rules that are not in the recommended set are off unless they are explicitly enabled. The explicit form is the mechanism that documents the intent, and the default is the mechanism that keeps the configuration short.
The rules that are not recommended are the ones that the Biome team considers too opinionated, too new, or too narrow for the baseline. The noShoutyConstants is the example from the Biome documentation: it is not recommended by default, and when it is triggered it emits the info severity . The useNamingConvention is another example: it is a style rule that the project must configure with the naming convention it wants, and the configuration is the mechanism that makes it useful .
// biome.json — the explicit rules beyond the recommended set
{
"linter": {
"rules": {
"recommended": true,
"style": {
"useNamingConvention": {
"level": "error",
"options": { "strictCase": false }
}
}
}
}
}
The useNamingConvention is not in the recommended set, and the explicit configuration is the mechanism that enables it. The rule is the style rule, and the options are the naming convention the project wants. The explicit rule is the refinement of the baseline, and the baseline is the recommended set.
b. The domains and the recommended extension
The domains are the technology-specific rule sets. The linter.domains object maps the domain name to the "recommended" string, and the string enables the recommended rules of that domain . The React domain is the example, and the react: "recommended" enables the React-specific rules that the Biome team considers the baseline for the React projects.
// biome.json — the React domain
{
"linter": {
"rules": { "recommended": true },
"domains": {
"react": "recommended"
}
}
}
The react domain enables the rules like the useExhaustiveDependencies and the useHookAtTopLevel, which are the React-specific recommended rules . The domain is the mechanism that adds the technology-specific checks to the baseline, and the baseline is the recommended set. The domain is the refinement, and the combination is the complete configuration.
The test domain is the second example. The test: "recommended" enables the rules like the noFocusedTests and the noExportsInTest, which are the test-specific recommended rules . The domain is the mechanism that adds the test-specific checks, and the checks are the refinement of the baseline. The domain is the technology-specific layer, and the recommended set is the language-agnostic baseline.
// biome.json — the test domain
{
"linter": {
"rules": { "recommended": true },
"domains": {
"test": "recommended"
}
}
}
The test domain is the mechanism that adds the test-specific rules. The noFocusedTests is the recommended rule that catches the test.only calls, and the noExportsInTest is the recommended rule that catches the exports in the test files. The domain is the refinement, and the baseline is the recommended set.
Complete Example Session
// ============================================
// PART 1: THE DEFAULT CONFIGURATION
// ============================================
{
"linter": {
"rules": {
"recommended": true
}
}
}
// The recommended set is on.
// The recommended rules emit the error severity.
// ============================================
// PART 2: THE RECOMMENDED RULES IN THE CORRECTNESS GROUP
// ============================================
// The noUnusedVariables and the noUnusedImports are recommended.
// The recommended rules fail the CLI.
// ============================================
// PART 3: THE RECOMMENDED RULES IN THE SUSPICIOUS GROUP
// ============================================
// The noDebugger and the noDoubleEquals are recommended.
// The noDebugger catches the stray debugger statements.
// ============================================
// PART 4: THE RECOMMENDED RULES IN THE A11Y GROUP
// ============================================
// The useAltText and the useAnchorContent are recommended.
// The useAltText catches the missing alt attributes.
// ============================================
// PART 5: THE DISABLED RECOMMENDED SET
// ============================================
{
"linter": {
"rules": {
"recommended": false,
"suspicious": {
"noDebugger": "error"
}
}
}
}
// The recommended set is off.
// Only the explicit rule is enabled.
// ============================================
// PART 6: THE EXPLICIT RULE BEYOND THE RECOMMENDED SET
// ============================================
{
"linter": {
"rules": {
"recommended": true,
"style": {
"useNamingConvention": {
"level": "error",
"options": { "strictCase": false }
}
}
}
}
}
// The useNamingConvention is not recommended.
// The explicit configuration enables it.
// ============================================
// PART 7: THE REACT DOMAIN
// ============================================
{
"linter": {
"rules": { "recommended": true },
"domains": { "react": "recommended" }
}
}
// The react domain adds the React-specific recommended rules.
// ============================================
// PART 8: THE TEST DOMAIN
// ============================================
{
"linter": {
"rules": { "recommended": true },
"domains": { "test": "recommended" }
}
}
// The test domain adds the test-specific recommended rules.
// ============================================
// PART 9: THE NURSERY RULES
// ============================================
{
"linter": {
"rules": {
"recommended": true,
"nursery": "on"
}
}
}
// The nursery rules are enabled with the "on".
// The nursery rules are not recommended by default.
// ============================================
// PART 10: THE CHECKLIST
// ============================================
// [ ] The recommended set is on by default.
// [ ] The recommended rules emit the error severity.
// [ ] The recommended: false disables the whole set.
// [ ] The explicit rules are the refinement.
// [ ] The domains add the technology-specific rules.
// [ ] The nursery rules are opt-in.
The ten parts covered the default configuration, the recommended rules in the correctness group, the recommended rules in the suspicious group, the recommended rules in the a11y group, the disabled recommended set, the explicit rule beyond the recommended set, the React domain, the test domain, the nursery rules, and the checklist. The through-line is that the recommended set is the baseline, and the explicit rules and the domains are the refinement.
Quick Reference
The recommended set
| Aspect | Detail |
|---|---|
| The default | The recommended set is on |
| The severity | The error severity |
| The disable | The "recommended": false |
| The explicit rules | The refinement of the baseline |
The recommended rules by group
| Group | The recommended examples |
|---|---|
correctness | noUnusedVariables, noUnusedImports |
suspicious | noDebugger, noDoubleEquals |
a11y | useAltText, useAnchorContent |
The domains
| Domain | The recommended rules |
|---|---|
react | useExhaustiveDependencies, useHookAtTopLevel |
test | noFocusedTests, noExportsInTest |
next | The Next.js-specific rules |
The non-recommended rules
| Rule | Why not recommended |
|---|---|
noShoutyConstants | Too opinionated, emits info |
useNamingConvention | The project must configure the convention |
Best Practices
✅ Do This:
// Use the recommended set for the baseline
{ "linter": { "rules": { "recommended": true } } } // ✅
// Use the domains for the technology-specific rules
{ "linter": { "domains": { "react": "recommended" } } } // ✅
// Disable the recommended set for the explicit-only configuration
{ "linter": { "rules": { "recommended": false } } } // ✅
❌ Don’t Do This:
// Assume the recommended set is every rule
// The recommended set is a subset. // ❌
// Assume the non-recommended rules are off permanently
// The explicit configuration enables them. // ❌
Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| The recommended rules fail the CI | The severity is error | The expected behavior, fix the violations |
| The explicit rule is ignored | The recommended: false is set | Enable the rule explicitly |
| The domain rule is not applied | The domain is not enabled | Set the domains entry |
| The nursery rule is not applied | The nursery rules are opt-in | Set "nursery": "on" |
Real-World Examples
1. The default recommended set
{ "linter": { "rules": { "recommended": true } } }
2. The disabled recommended set
{ "linter": { "rules": { "recommended": false } } }
3. The explicit rule
{ "linter": { "rules": { "style": { "useNamingConvention": "error" } } } }
4. The React domain
{ "linter": { "domains": { "react": "recommended" } } }
5. The test domain
{ "linter": { "domains": { "test": "recommended" } } }
6. The nursery rules
{ "linter": { "rules": { "nursery": "on" } } }
7. The recommended noDebugger
{ "linter": { "rules": { "suspicious": { "noDebugger": "error" } } } }
8. The recommended noDoubleEquals
{ "linter": { "rules": { "suspicious": { "noDoubleEquals": "error" } } } }
9. The recommended useAltText
{ "linter": { "rules": { "a11y": { "useAltText": "error" } } } }
10. The explicit useNamingConvention
{ "linter": { "rules": { "style": { "useNamingConvention": { "level": "error" } } } } }
Visual
The Recommended Baseline
┌──────────────────────────────────────────────────────────────┐
│ THE RECOMMENDED SET IS THE BASELINE │
│ │
│ Default configuration │
│ ┌─────────────────────┐ │
│ │ recommended: true │ The curated set is on │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ The recommended │ The error severity │
│ │ rules are enabled │ The CLI fails on the violations │
│ └─────────────────────┘ │
│ │
│ The explicit rules and the domains are the refinement. │
└──────────────────────────────────────────────────────────────┘
The Domains
┌──────────────────────────────────────────────────────────────┐
│ THE DOMAINS ADD THE TECHNOLOGY-SPECIFIC RULES │
│ │
│ recommended: true │
│ ┌─────────────────────┐ │
│ │ The baseline rules │ The language-agnostic set │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ domains.react: "recommended" │
│ ┌─────────────────────┐ │
│ │ The React-specific │ The useExhaustiveDependencies, │
│ │ rules │ the useHookAtTopLevel │
│ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
The Non-Recommended Rules
┌──────────────────────────────────────────────────────────────┐
│ THE NON-RECOMMENDED RULES ARE OPT-IN │
│ │
│ noShoutyConstants │
│ ┌─────────────────────┐ │
│ │ Not recommended │ The info severity when triggered │
│ │ Opt-in │ │
│ └─────────────────────┘ │
│ │
│ useNamingConvention │
│ ┌─────────────────────┐ │
│ │ Not recommended │ The project must configure the │
│ │ Opt-in │ naming convention │
│ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Summary
| Item | Value |
|---|---|
| The default | The recommended set is on |
| The severity | The error severity |
| The disable | The "recommended": false |
| The domains | The technology-specific recommended sets |
| The non-recommended | The opt-in rules like noShoutyConstants |
| The nursery | The opt-in rules under development |
Key takeaways:
- The Biome linter runs only the recommended rules by default. The recommended set is the curated baseline, and the rules emit the
errorseverity, which fails the CLI and the CI . The recommended set is a subset of the rules that Biome ships. - The
"recommended": falsedisables the whole set. A project that wants only a few rules sets the flag tofalseand lists the rules it wants. The disable is the mechanism that turns off the curated baseline . - The domains add the technology-specific rules. The
react: "recommended"and thetest: "recommended"are the mechanisms that enable the React-specific and the test-specific recommended rules . The domain is the refinement of the baseline. - The non-recommended rules are opt-in. The
noShoutyConstantsand theuseNamingConventionare not in the recommended set, and the explicit configuration is the mechanism that enables them . - The nursery rules are the opt-in development rules. The
"nursery": "on"enables the rules that are still under development, and the rules are not recommended by default because they may still have the bugs or the performance problems.
Remember: The Biome linter is the recommended set by default. The recommended rules emit the error severity, and the "recommended": false is the disable. The domains add the technology-specific rules, and the non-recommended rules are the opt-in refinement. The recommended set is the baseline, and the explicit rules are the customization.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!