Biome 2.6 Explained: What It Can Replace in Prettier, ESLint and Stylelint

You end up looking after three tools, a Tailwind plugin, three config files and the rules that must keep them from disagreeing. When one of them updates, the others can start fighting over the same lines. This guide tests whether Biome 2.6 can replace all three, and where the Biome vs Prettier, ESLint and Stylelint swap still falls short.

Picture a common setup. A small team in Pune keeps a React and Tailwind CSS web app in one repository, with SCSS files, a Markdown README and docs, and YAML files for GitHub Actions. The repo is made up, but every command and output in this guide was run on real Biome versions.

The repo runs Prettier for layout, with prettier-plugin-tailwindcss inside its config to sort class names. ESLint checks JavaScript and Stylelint checks CSS. A new joiner must learn three configs before their first pull request. Biome would replace them with one config file, biome.json.

• Prettier formats JavaScript, CSS, SCSS, Markdown and YAML in this repo.
• ESLint lints the JavaScript and TypeScript.
• Stylelint lints the CSS and SCSS.
• The Tailwind Prettier plugin sorts long className strings into a standard order.

You need eight words: formatter, linter, rule, preset, nursery, CI, CommonMark and frontmatter. Each gets a plain meaning and one example from the repo.

• Formatter: a tool that rewrites spacing, quotes and line breaks without changing what the code does. Prettier is a formatter, and so is biome format.
• Linter: a tool that reads code and reports likely mistakes, such as a leftover debugger statement. ESLint and Stylelint are linters, and so is biome lint.
• Rule: one check inside a linter, with a name. Biome's noDebugger rule reports debugger statements, much like ESLint's no-debugger.
• Preset: a ready-made bundle of rules. Biome's default preset is recommended, its bundle of rules the team thinks most projects want.
• Nursery: Biome's group for new rules that are still experimental. A nursery rule can change behaviour in any release, so treat it like a preview.
• CI: continuous integration, the server that runs checks on every pull request. If a check fails, the pull request shows a red cross.
• CommonMark: the written standard for Markdown syntax. GitHub Flavored Markdown, or GFM, adds extras such as tables and task lists.
• Frontmatter: a block of YAML settings at the top of a Markdown file, between two lines of three dashes. Blog and docs site tools read it for titles and dates.

Biome has a check command that runs the formatter and linter together, and a ci command that does the same without changing files. Most teams run biome check on their laptop and biome ci in CI. Each problem Biome reports is called a diagnostic.

In the Pune repo, Biome 2.6 can take over formatting for every file type the team uses. It can also take over linting, but only for rules with a Biome match. In our Stylelint test, 4 of 7 rules had one.

Before 2.6, Biome simply skipped Markdown, SCSS and YAML. We ran Biome 2.5.15 on a Markdown, an SCSS and a YAML file, and it reported No files were processed for all three. Version 2.6.3 formatted all three. We did not benchmark speed, so this guide makes no speed claims.

It added a parser and a formatter for all three languages, and Biome's lint rules now run on these files. A parser is the part that reads a file and builds a tree of its structure, which the formatter and linter then use.

All the compatibility numbers below come from Biome's v2.6 blog post, and they are Biome's own figures, not results on your files. We ran small sample files to see what changes in practice.

Markdown: formatted, with linting mostly off by default

Biome claims its Markdown parser covers 100% of CommonMark and says its formatter is about 92% compatible with Prettier. The blog does not say how that figure was measured. GFM extras such as tables are on by default, and our table was aligned correctly.

Here is what Biome 2.6.3 did to two lines of our README:

Before:
Some *emphasis*  and __bold__ text.
* item one

After biome format --write:
Some _emphasis_ and **bold** text.
- item one

It also formatted the JavaScript inside a fenced code block, a code sample between two lines of three backticks. Prettier 3.9.10 gave a slightly different file. It collapsed a double space in our README heading, not shown above, and added a blank line before the list.

Three Markdown lint rules exist in 2.6.3, and none runs with the default config. useTopLevelHeading and useConsistentHeadingLevel are nursery rules that check headings, and noEmptySource reports a file with only blank lines and HTML comments. When we enabled them, they flagged a file that started at a level-two heading, a jump from level two to four, and a file holding only a comment. biome explain lists both heading rules as available since 2.5.8, but 2.5.15 skipped .md files in our test, so 2.6 is where they start to matter.

Biome can also lint the code inside fenced blocks, frontmatter and HTML blocks, but only after you set markdown.analyzeEmbeds to true. With that on, a debugger statement inside a js code block was reported by the normal noDebugger rule.

{
  "markdown": {
    "parser": {
      "frontmatter": true
    },
    "analyzeEmbeds": true
  }
}

SCSS: formatted like Prettier, linted with the CSS rules

SCSS files now get the same formatter and lint rules as CSS. Biome claims more than 90% compatibility with the official SCSS test suite, and says some rules cannot yet see inside loops and mixins.

Our test showed exactly that edge. A mixin is a named group of SCSS lines you can reuse, and an @each loop repeats lines for every item in a list. The noUnknownProperty rule caught a typo, colr, in a normal block, inside a mixin and inside an each loop. The noDuplicateProperties rule caught two color lines in a normal block but stayed silent when the same two lines sat inside a mixin.

With space indentation, Biome's SCSS output was identical to Prettier's on our sample. Two older styles were still ignored by 2.6.3: Sass indented syntax, which uses indentation instead of braces and ends in .sass, and Less files ending in .less.

YAML: formatted, but linting is a single rule

Biome claims 100% conformance with the official YAML test suite and 100% Prettier compatibility for formatting. Our YAML sample came out identical to Prettier's output.

The blog says YAML linting ships with one rule, without naming it. The changelog names noEmptySource as the rule that gained YAML support, and it is not on by default. One YAML file can hold several documents, separated by --- lines. When we enabled the rule, it reported an empty file and an empty second document.

Duplicate keys, such as two name lines in the same block of settings, were not reported by any default rule in our test. Keep your existing YAML checks, such as a schema check for workflow files, for now.

Several pieces are marked as unfinished, either by Biome or by what we saw in testing. Plan around them rather than assuming full parity with the tools you are replacing.

• JavaScript plugins: developer preview, with breaking changes allowed in patch releases.
• Tailwind rules, including useTailwindSortedClasses: nursery, so behaviour can change in any release.
• HTML formatting and Vue, Svelte and Astro support: marked experimental on Biome's language support page.
• Markdown linting: two nursery heading rules plus noEmptySource, all off by default. Linting embedded code is also off by default.
• YAML linting: one rule, noEmptySource, which you must switch on.
• SCSS linting: some rules do not look inside mixins and loops, as our duplicate-property test showed.
• Plugins for SCSS, YAML and Markdown: not started, per the language support page.

Install Biome, create a config, then run three migrate commands that read your old configs and write matching Biome settings. Keep Node.js installed: the blog says the Stylelint migrator needs it to load your config and its plugins.

1. 1

   Install and pin

   Run npm i -D -E @biomejs/[email protected] in the repo. The -E flag saves the exact version. Avoid 2.6.0 and 2.6.1, which install but fail to start.

2. 2

   Create biome.json

   Run npx biome init. Inside a Git repo, 2.6 sets vcs.enabled and vcs.useIgnoreFile to true, so Biome reads your .gitignore and skips those files.

3. 3

   Port Prettier settings

   Run npx biome migrate prettier --write. It copies options such as quote style and line width, and turned our .prettierignore lines into exclusion patterns. It does not carry over prettier-plugin-tailwindcss.

4. 4

   Port ESLint rules

   Run npx biome migrate eslint --write. Biome's migration guide says this replaces the linter settings in biome.json, so run it before the Stylelint step.

5. 5

   Port Stylelint rules

   Run npx biome migrate stylelint --write. It accepts JSON or JavaScript Stylelint configs only, and the guide says it merges into biome.json.

6. 6

   Decide on the preset

   Both lint migrators set the rule preset to none. Change preset back to recommended if you want Biome's default bundle as well.

7. 7

   Turn on Tailwind sorting

   In our test, migrate prettier wrote no Tailwind setting and gave no warning. Merge the useTailwindSortedClasses block shown below into the existing linter.rules, or keep the Prettier plugin until you are ready.

8. 8

   Check and commit

   Run npx biome check --write . to apply formatting and safe fixes, the ones Biome says cannot change what code does. Then run npx biome ci . and fix what it reports. Remove the old tools in a separate commit.

{
  "linter": {
    "rules": {
      "nursery": {
        "useTailwindSortedClasses": {
          "level": "error",
          "fix": "safe"
        }
      }
    }
  }
}

Biome marks this rule's fix as unsafe, meaning it might change what the code does, so --write normally skips it. Setting fix to safe tells Biome to apply it. With this block merged into biome.json, biome check --write sorted our Button.jsx classes on 2.6.3.

About the order of steps 4 and 5: in our tiny test on 2.6.3, running Stylelint before ESLint also kept both sets of rules. The documented order is still the safer habit.

What the Stylelint migrator actually moved

We fed it a Stylelint config with seven rules, one override for legacy files and one ignore pattern. It reported that 4 of the 7 rules, 57%, were fully covered by Biome.

It moved the rules for empty blocks, duplicate properties, duplicate font names and unknown pseudo-classes. It left out color-named, color-no-invalid-hex and max-nesting-depth, and listed them in its report as having no Biome equivalent yet. The override and the dist ignore pattern came across correctly.

What just happened? The migrator copied the four rules Biome can match and named the three it could not. It also switched the preset to none, so biome.json now holds fewer checks than your old tools ran.

Adding --include-inspired, which also migrates rules that only resemble the originals, changed nothing for this config. A YAML Stylelint config was rejected with a clear error.

Think of the recommended preset as a restaurant thali: you get the full plate without naming each dish. The migrators cancel the thali and order a la carte, only the dishes your old config named. Where the picture breaks: a thali's dishes stay fixed, but Biome's recommended bundle changes between releases. The blog says some rules promoted in 2.6 are now recommended, so an upgrade can add findings.

Run these commands and compare the output with what is shown here. Each one checks a different thing that commonly goes wrong.

npx biome --version
# Version: 2.6.3

npx biome ci .
# Checked N files in ...ms. No fixes applied.

echo $?
# 0   (in PowerShell: $LASTEXITCODE)

# inspect shows one setting and the file it came from
npx biome inspect config formatter.indentStyle
# i The key formatter.indentStyle has the following value.
#     "indentStyle": "space",
# i This value is provided by the root configuration.

• The version line proves the pinned binary runs. If you see Cannot find module followed by a package such as @biomejs/cli-linux-x64 or @biomejs/cli-win32-x64, you installed 2.6.0 or 2.6.1.
• The files count in biome ci should include your .md, .yaml and .scss files, unless you excluded them on purpose. Time is shown in ms (milliseconds) or µs (microseconds).
• Exit code 0 means no errors. Any format difference or error-level diagnostic gives exit code 1, which fails a CI job.
• The inspect line shows a setting's value and its source. After migrate prettier, expect your Prettier indent style, usually space. A config written only by biome init shows tab, Biome's own default.

This section is for teams already on Biome 2.5, not for the Pune repo. CI can fail for three reasons: new file types, a renamed rule and newly recommended rules.

For the first reason, we used a small separate test repo with a JavaScript file, our three sample files and an unchanged biome.json. Biome 2.5.15 ran biome ci on 2 files and exited with code 0. Biome 2.6.3 checked 5 files, found 3 format errors and exited with code 1.

The second reason stops CI before any file is checked. A config that still names useSortedClasses is rejected by 2.6.3 with Found an unknown key. The third reason is in the blog post: 59 nursery rules moved to stable groups, and some are now recommended, so new JavaScript findings can appear.

1. 1

   Pin the version

   Install with npm i -D -E @biomejs/[email protected], so every laptop and the CI runner use the same formatter.

2. 2

   Migrate the config

   Run npx biome migrate --write. It renames useSortedClasses and updates the schema link, the URL at the top of biome.json that editors use for autocomplete.

3. 3

   Option A: format new files once

   Run npx biome format --write . and commit the result alone. Reviewers can then skip that commit when reading history.

4. 4

   Option B: exclude them for now

   Skip this if you chose option A. Add the exclusion patterns shown below to files.includes, so Biome checks the same file types as 2.5.

5. 5

   Handle promoted rules

   Run npx biome lint . and fix or turn off any new findings in their own commit.

6. 6

   Run CI locally

   Run npx biome ci . and expect exit code 0.

{
  "files": {
    "includes": [
      "**",
      "!**/*.md",
      "!**/*.yaml",
      "!**/*.yml",
      "!**/*.scss"
    ]
  }
}

With this exclusion, our 2.6.3 run on the test repo went back to 2 files checked and exit code 0. Remove the patterns one at a time as you format each language.

Two things changed: the rule's name and its sort order. The rule useSortedClasses is now useTailwindSortedClasses, and its order was rewritten to follow Tailwind v4.

Tailwind class sorting means putting the utility classes in a className string into one fixed order, so diffs stay small. If the Pune repo moves from the Prettier Tailwind plugin, only the order matters. If you used Biome's rule on 2.5, both changes affect you.

The rename breaks an old config

Biome 2.6.3 refuses a config that still says useSortedClasses, and Biome 2.5.15 refuses the new name in the same way. You cannot write one config that works on both versions.

Running npx biome migrate --write fixed our config in one step. It renamed the rule, updated the schema link to 2.6.3, and moved the old functions option to a new top-level tailwind.mergeFunctions setting.

{
  "$schema": "https://biomejs.dev/schemas/2.6.3/schema.json",
  "linter": {
    "rules": {
      "nursery": {
        "useTailwindSortedClasses": {
          "level": "error",
          "fix": "safe"
        }
      }
    }
  },
  "tailwind": {
    "mergeFunctions": [
      "clsx",
      "cn"
    ]
  }
}

That is the config migrate wrote for us; the fix line came from our old config. Biome calls a fix unsafe when it might change what the code does, and biome lint --write skips unsafe fixes unless you add --unsafe. This rule's fix is marked unsafe. With fix set to safe, a plain biome lint --write sorted our classes.

The sort order really changed

Pause and predict: we gave Biome 2.5.15 and 2.6.3 the same six unsorted class strings. Will they sort them the same way?

They did not. Five of the six came out in a different order on 2.6.3. We then ran Prettier 3.9.10 with prettier-plugin-tailwindcss 0.8.1 and Tailwind 4.3.3, and its output matched Biome 2.6.3 on all six strings.

The fourth row matches the rule page: classes that Tailwind does not know come first and keep their original order. Biome 2.5.15 had placed my-card in the middle of the list. If you define custom utilities, point tailwind.stylesheet at your main CSS file so Biome can read your theme.

Biome 2.6 also added three nursery rules that the blog says were inspired by shadcn's lint project: noTailwindRawColors, noTailwindRestyledComponents and useTailwindStaticClassStrings. Being nursery rules, none of them is on by default.

It shows what Biome resolved without changing any file. In 2.6.3 it has three parts: config, plugins and file.

• biome inspect config prints the merged configuration and the files it came from. Give it a key, such as formatter.lineWidth, to see one value and its source.
• Add --path with a file name to see the value for that file after overrides. Our legacy override for lineWidth 120 showed up with the override and the matching pattern named.
• biome inspect plugins lists plugin rules from loaded plugins and presets. For JavaScript plugins it names the file only, because Biome does not run them during inspection.
• biome inspect file prints the syntax tree of one file, plus formatter and semantic details. It is mainly useful when you write plugins.

Config files can now extend other configs up to ten levels deep, according to the blog post. The inspect command is the quickest way to see which level set a value.

A JavaScript plugin is a small .js or .ts file with your own lint rule, loaded through the plugins list in biome.json. It is a developer preview, and the docs warn that breaking changes can land even in patch releases.

Before 2.6, custom rules had to be written in GritQL, a pattern language Biome adopted for plugins. JavaScript plugins let you write the rule in a language most front-end developers already know.

import { ast, defineRule, registerDiagnostic } from "@biomejs/runtime/plugin";

const RESTRICTED = new Set(["eval", "setTimeout", "setInterval"]);

export const restrictedCallee = defineRule({
  query: ast("JS_CALL_EXPRESSION"),
  run(node) {
    const callee = node.callee;
    if (callee?.kind !== "JS_IDENTIFIER_EXPRESSION") return;
    if (!RESTRICTED.has(callee.text)) return;
    registerDiagnostic(callee, "error", "Restricted callee");
  },
});

This is the example from the v2.6 blog post, saved as plugin.js next to a biome.json that lists it under plugins. We ran it on 2.6.3 without installing any extra package. It flagged setTimeout and eval, but not window.setTimeout, because that call goes through an object first.

The same plugin made 2.5.15 fail with a plugin loading error. Plugins also cannot reach Node.js: importing node:fs failed with module not found, and process and require were undefined. The docs do not describe the runtime in that detail; this is what 2.6.3 did on 26 October 2026.

Their platform binaries were never published. Biome ships its compiled program in separate npm packages per operating system, such as @biomejs/cli-linux-x64, and the main package only points at them.

On 26 October 2026, npm had @biomejs/biome 2.6.0 and 2.6.1, both published on 21 October. All ten platform binary packages, for Linux, macOS, Windows and Android, skip 2.6.0 and 2.6.1 and resume at 2.6.2. Installing 2.6.0 succeeded, but running it failed with Cannot find module @biomejs/cli-linux-x64/biome.

That error comes from a small Node.js launcher script in the main package, which npx biome runs to find the binary. The changelog at the release tag has no 2.6.0 or 2.6.1 section either; the 2.6 feature list sits under 2.6.2. Use 2.6.2 or later, and pin the exact version.

Treat it as a developer-tooling decision with trade-offs, not a tool you like. Interviewers want to hear how you would roll it out without breaking the team.

1. 1

   Name the problem

   Three tools, a plugin and three configs for formatting and linting cost time, and they can disagree. One tool with one config reduces that.

2. 2

   Say what Biome 2.6 covers

   It formats JS, TS, CSS, SCSS, JSON, GraphQL, Markdown and YAML, and lints most of them. Quote compatibility numbers as Biome's own claims.

3. 3

   Name the gaps

   JavaScript plugins are a preview, Tailwind rules are nursery, and the migrators only port rules that have a Biome match.

4. 4

   Describe a safe rollout

   Pin the version, migrate configs, run biome ci in a branch, and put mass reformatting in its own commit.

5. 5

   Say how you would measure it

   Compare CI time and the number of lint findings before and after, and keep the old linter for rules Biome lacks.