Linter
Biome’s linter statically analyzes your code to find and fix common errors and to help you write better, modern code. It supports multiple languages and provides a total of 237 rules.
The following command runs the linter on all files in the src
directory:
The command accepts a list of files and directories.
For more information about all the available options, check the CLI reference.
Rules
Section titled RulesThe linter is organized into rules.
A rule emits a diagnostic when it encounters a code that doesn’t meet its requirements.
For example, the noDebugger rule reports using the debugger
instruction in JavaScript code.
A rule emits diagnostics with a warn
or error
severity.
Diagnostics with an error
severity cause the command to exit with a non-zero code,
While diagnostics with a warn
severity don’t cause the command to fail.
You can turn warnings into errors --error-on-warnings
CLI option:
By default, the Biome linter only runs recommended rules.
Recommended rules emit diagnostics with the error
severity.
Rules are organized into groups.
For example, the noDebugger
rule is part of the suspicious
group.
A Rule from this group detects code that is likely to be incorrect or useless.
The description of each group can be found on the rules page.
Unlike other linters, we don’t provide any rules that check for code formatting. This kind of checking is covered by our code formatter.
Many rules provide a code fix that can be automatically applied. Biome distinguishes between safe and unsafe code fixes.
Safe fixes
Section titled Safe fixesSafe fixes are guaranteed to not change the semantic of your code. They can be applied without explicit review.
To apply safe fixes, use --apply
:
Unsafe fixes
Section titled Unsafe fixesUnsafe fixes may change the semantic of your program. Therefore, it’s advised to manually review the changes.
To apply unsafe fixes, use --apply-unsafe
:
Note that this command also applies safe fixes.
Rule pillars
Section titled Rule pillarsWe believe that rules should be informative and explain to the user why a rule is triggered and tell the user what they should to do fix the error. A rule should follow these pillars:
- Explain to the user the error. Generally, this is the message of the diagnostic.
- Explain to the user why the error is triggered. Generally, this is implemented with an additional node.
- Tell the user what they should do. Generally, this is implemented using a code action. If a code action is not applicable a note should tell the user what they should do to fix the error.
If you think a rule doesn’t follow these pillars, please open an issue.
Configuration
Section titled ConfigurationA rule is enabled whether its severity is error
or warn
.
You can turn off a rule with off
.
The following configuration disables the recommended noDebugger
rule
and enables the noShoutyConstants
and useNamingConvention
rules.
The warn
severity is useful in cases where there’s a refactor going on and there’s a need to make the CI pass.
Rule options
Section titled Rule optionsA few rules have options. You can set them by shaping the value of the rule differently.
level
will indicate the severity of the diagnostic;options
will change based on the rule.
Ignoring code
Section titled Ignoring codeThere are times when a developer wants to ignore a lint rule for a specific line of the code. You can achieve this by adding a suppression comment above the line that emits the lint diagnostic.
Suppression comments have the following format:
Where
biome-ignore
is the start of a suppression comment;lint
suppresses the linter;/suspicious/noDebugger
: optional, group and name of the rule you want to suppress;<explanation>
explanation why the rule is disabled
Here’s an example:
Ignoring files
Section titled Ignoring filesBiome doesn’t provide ignore comments that ignore an entire file. However, you can ignore a file using the Biome configuration file.
You can ignore files for all tools, including the linter,
using the files.ignore
configuration.
By default, Biome ignores the protected files.
If you want to exclude files from being linted, you can use linter.ignore
:
Note that you can also ignore the files ignored by your VCS.
Migrating from other linters
Section titled Migrating from other lintersMany of Biome lint rules are inspired from other linters.
If you want to migrate from other linters such as ESLint or typescript-eslint
,
check the rules sources page
If you are migrating from ESLint,
we have a dedicated migration guide.