| | |

Biome 08 🧹 The Recommended Ruleset — What’s on by default

⏱️ Estimated read: 11 min | |

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

AspectDetail
The defaultThe recommended set is on
The severityThe error severity
The disableThe "recommended": false
The explicit rulesThe refinement of the baseline

The recommended rules by group

GroupThe recommended examples
correctnessnoUnusedVariables, noUnusedImports
suspiciousnoDebugger, noDoubleEquals
a11yuseAltText, useAnchorContent

The domains

DomainThe recommended rules
reactuseExhaustiveDependencies, useHookAtTopLevel
testnoFocusedTests, noExportsInTest
nextThe Next.js-specific rules

The non-recommended rules

RuleWhy not recommended
noShoutyConstantsToo opinionated, emits info
useNamingConventionThe 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

PitfallWhy It HappensFix
The recommended rules fail the CIThe severity is errorThe expected behavior, fix the violations
The explicit rule is ignoredThe recommended: false is setEnable the rule explicitly
The domain rule is not appliedThe domain is not enabledSet the domains entry
The nursery rule is not appliedThe nursery rules are opt-inSet "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

ItemValue
The defaultThe recommended set is on
The severityThe error severity
The disableThe "recommended": false
The domainsThe technology-specific recommended sets
The non-recommendedThe opt-in rules like noShoutyConstants
The nurseryThe 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 error severity, which fails the CLI and the CI . The recommended set is a subset of the rules that Biome ships.
  • The "recommended": false disables the whole set. A project that wants only a few rules sets the flag to false and 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 the test: "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 noShoutyConstants and the useNamingConvention are 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.

Was this helpful?


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!