Biome overrides: Per-Path Config Overrides
The overrides array lets you apply different Biome settings to files matching a glob, such as relaxing rules in tests.
Overrides are how you say "these settings, but not for that folder". Each entry matches paths and supplies its own formatter, linter, or language block.
What it does
overrides is an array; each entry has an includes glob (v2; "include" in v1) and optional formatter, linter, javascript, json, or css blocks that override the top-level config for matching files. Later matching entries win, layered over the base config.
Common usage
{
"overrides": [
{
"includes": ["**/*.test.ts", "**/*.spec.ts"],
"linter": { "rules": { "suspicious": { "noConsole": "off" } } }
},
{
"includes": ["**/*.json"],
"formatter": { "indentWidth": 4 }
}
]
}Options
| Key | What it does |
|---|---|
| includes (v2) | Globs the override applies to (was "include" in v1) |
| formatter | Formatter settings for matched files |
| linter.rules | Rule overrides for matched files |
| javascript / json / css | Language-specific overrides |
In CI
Overrides resolve the same in CI as locally, so a rule relaxed for tests will not fail biome ci on those files. Order matters: put broad matches first and specific exceptions later, since later entries take precedence.
Common errors in CI
On v2, using the v1 key "include" inside an override yields "Found an unknown key include"; the v2 key is "includes". A glob that never matches silently does nothing, so a rule you meant to disable still fires; test the glob with biome check on one path. Overrides cannot turn on rules that the base config disabled at the group level unless you re-enable them.