Biome now supports Markdown. The vast majority of the parser was implemented by @jfmcdowell , who implemented the whole parser, the testing suite, and a great harness that makes sure the HTML generated by our parser complies with CommonMark. The parser has 100% CommonMark conformance coverage. Thank you for your great contribution!

The Markdown formatter is ~92% compatible with Prettier, and we expect compatibility to be even higher in real-world projects. Thank you @tidefield for the great help. The parser supports GitHub Flavored Markdown extensions, such as task items, tables, and short links, by default.

To enable frontmatter support, use the markdown.parser.frontmatter option.

Biome can format frontmatter, HTML and fenced code blocks. This capability is enabled by default, and you can disable it with the option markdown.formatter.formatEmbeds.

Biome can analyze (lint and assist) frontmatter, HTML and fenced code blocks. This capability is disabled by default, and you can enable it with the option markdown.analyzeEmbeds.

Example:
```js
const foo = 'bar'
const foo = "bar";
```

SCSS support was written entirely by Core Contributor @denbezrukov , who worked tirelessly to reach more than 90% compatibility with the official test suite. Most of the remaining cases involve legacy features, so we’re confident you won’t run into many bugs in modern projects.

Formatting works out of the box, and the existing CSS lint rules already work on SCSS files. Some rules can’t yet catch cases that involve SCSS constructs such as loops and mixins, because they depend on infrastructure we haven’t built yet. Refer to the documentation of each rule to learn about its current limitations.

We’ll add more capabilities in the coming months.

The Biome project owes Maintainer @l0ngvh a lot. They implemented the GraphQL parser, and now their YAML parser is ready!

The YAML parser ships with 100% conformance coverage against the official test suite, and the formatter has 100% compatibility with Prettier, courtesy of the amazing work of Core Contributor @dyc3 .

The YAML linter ships with a single rule for now. We plan to add more nursery rules in upcoming patches, as well as dedicated rules for GitHub workflows, mostly focused on security.

Thanks to the combined efforts of Core Contributor @siketyan and Core Contributor @ematipico , plugins gain new capabilities in Biome v2.6.

This milestone took a lot of work, but we’re excited to announce that JavaScript plugins are now available as a developer preview, so you can start creating and shipping custom lint rules.

We designed JavaScript plugins to mirror the architecture, shape, and APIs of Biome’s Rust lint rules as closely as possible, so writing one gives you a feel for how lint rules work in Biome. Here’s what a JavaScript plugin looks like:

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");
  },
});

Then add the plugin to your configuration file:

{
  "plugins": [
    "plugin.js"
  ]
}

There are some particular characteristics of Biome plugins worth mentioning:

• You can use .js files, or .ts files. Files with either extension are valid plugins. Under the hood, Biome strips the types during the loading phase, and the files are eventually loaded as JavaScript files. This is the same strategy adopted by Node.js.
• Biome uses a CST (Concrete Syntax Language), a particular form of syntax tree that stores all the information about a program. Working with a CST can be tedious and verbose, but it provides greater control because you can read all tokens (keywords, strings, comments, etc.).
• Biome’s parsers are error-resilient, which means that Biome is able to format and lint a program with syntax errors. When syntax errors occur, instead of bailing, the parser is able to recover to a known good state and continue parsing. Biome uses “bogus” nodes to decorate the invalid code. While navigating the CST nodes, you’ll have access to these bogus nodes. You can decide to ignore them, or attempt to visit them. This is a completely different model from other plugin systems such as ESLint, Prettier, Stylelint, oxlint, etc. so we encourage you to take your time, and get familiar with this new model.
• JavaScript plugins tap directly into our Rust infrastructure, which means they have access to a lot of information such as semantic model, control flow graph, file name, package manifest, module graph, type inference, and more. However, for this release, we intentionally decided to expose a subset of services. We see a lot of potential; however, this is uncharted ground for us too, so we need your feedback to build a good foundation.

Potentially, you would be able to write lint rules that use Biome’s module graph and type-inference engine.

Under the hood, Biome plugins use a JavaScript runtime built in Rust called boa. Boa is a very promising and upcoming project. The team are the authors of temporal_rs, the engine that powers the new Temporal APIs of V8 and Node.js.

Refer to the relative guide to learn about how they work, and the APIs at your disposal.

You can now distribute configuration files, GritQL plugins, and JavaScript plugins together in a single npm package. Create a biome-manifest.json file at the root of your package, and use it to share opinionated configuration files, GritQL plugins, JavaScript plugins, and rule presets.

A package can also import other Biome packages and distribute them under its own umbrella, a technique usually called aliasing.

Here’s what a biome-manifest.json file could look like. It exposes:

• Via configs, two configuration files, one called strict and one called recommended.
• Via plugins, two lint rules, one called useCompanyLogger implemented in JavaScript, one called noLegacyLibrary implemented in GritQL.
• Via plugins, two presets, one called recommended, which enables the rule useCompanyLogger, and one called strict, which enables the rules useCompanyLogger and noLegacyLibrary.

{
  "version": 1,
  "configs": [
    { "recommended": "./configs/recommended.json" },
    { "strict": "./configs/strict.json" }
  ],
  "plugins": {
    "rules": [
      { "useCompanyLogger": "./rules/useCompanyLogger.js" },
      { "noLegacyLibrary": "./rules/noLegacyLibrary.grit" }
    ],
    "presets": {
      "recommended": ["useCompanyLogger"],
      "strict": ["useCompanyLogger", "noLegacyLibrary"]
    }
  }
}

Users can then consume the configurations, rules, and presets in their biome.json. Assuming your package is called @org/biome-plugin, the following example enables configs/strict and presets/strict:

{
  "extends": ["@org/biome-plugin/configs/strict"],
  "plugins": ["@org/biome-plugin/presets/strict"]
}

Read the guide to publishing packages to learn what you can publish and how users can consume your packages.

You can still distribute a configuration file the old way, but that approach is now considered legacy.

Biome 2.6 introduces the resolutionKind option for object-syntax plugin entries, making plugins easier to reuse from shared configurations.

By default, Biome resolves plugin paths in a shared configuration from the directory containing the configuration that extends it. To load a plugin that ships with the shared configuration, set resolutionKind to "config":

{
  "plugins": [
    {
      "path": "./plugins/no-object-assign.grit",
      "resolutionKind": "config"
    }
  ]
}

Then extend the shared configuration:

{
  "extends": ["./biome.shared.jsonc"]
}

Biome resolves the plugin path from the directory containing biome.shared.jsonc, while includes globs are still resolved from the directory containing the extending configuration.

See plugins.<ITEM>.resolutionKind for the full option reference.

Thank you @soconnor-seeq for contributing this feature.

Biome 2.6 brings Tailwind-aware linting and class sorting closer to the way developers like to use Tailwind in their projects.

In patches leading up to this release, we’ve improved our Tailwind parser and expanded Tailwind class detection across HTML, Vue, Svelte, and Astro, and introduced new rules like useTailwindShorthandClasses and noTailwindRawColors. After lots of testing and fixing many bugs, we’re finally ready to really close the gap on our native Tailwind support.

We’ve revamped class sorting and added new rules inspired by @shadcn/lint designed to make agents produce high-quality, idiomatic Tailwind styles. We’re excited for you to try them out and to listen to your feedback as we continue iterating on them.

You’ve been waiting for this one for a long time, and it’s long overdue. We’re excited to finally ship Tailwind class sorting, one of our oldest and most requested features (460 👍 reactions)! The nursery rule useTailwindSortedClasses (formerly useSortedClasses) has been updated to the sorting semantics of Tailwind v4.

Tailwind v4 introduced “design systems”, where you define your application’s appearance as variables in CSS, and those automatically become available as Tailwind classes. Biome is now able to read this configuration stylesheet and it takes your design system into account when sorting classes.

{
  "tailwind": {
    "stylesheet": "app/global.css"
  }
}

Thanks to @johncarmack1984 for the help with the sorting implementation, and Core Contributor @dyc3 for working on the Tailwind parser!

Your design system probably defines a small set of colors to use, and where to use them. How many times have you told your agent something like “make the danger button red”, and it does something silly like this:

<button class="bg-red-500">Danger</button>

You might even have a skill that tells the agent not to do that, but maybe it decided not to read it. Frustrating, right? You wanted it to use the --color-danger you have defined in your config.

In case you missed its debut in 2.5.15, noTailwindRawColors inspired by no-raw-colors, flags these cases, and points you or your agent to your design system’s existing colors.

<button class="bg-danger">Danger</button>

Now, in 2.6.0, it will actively suggest existing colors in your design system, if any are close.

src/App.jsx:1:37 lint/nursery/noTailwindRawColors ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  × This Tailwind CSS class uses a raw palette color.
  > 1 │ export const pink = <div className="bg-pink-500" />;
      │                                     ^^^^^^^^^^^
    2 │ export const gray = <div className="hover:text-slate-100/80" />;
    3 │
  i Raw palette colors couple components to specific colors, making design-system changes harder.
  i Use a color from your design system. These classes are the closest matches:
  - bg-brand
  - bg-danger

Many of you have your own component library to keep your application’s visual style consistent. Not just the colors, but the whitespace, borders, font size, and animations are all the little things that make your user experience consistent and beautiful. That consistency crumbles when your agent forces new styles on your components.

// The Button's styles are overridden
<Button className="bg-red-500 text-white rounded-none" />;

The new nursery rule noTailwindRestyledComponents, inspired by no-restyle, reports utilities that change a component’s color, typography, spacing, shape, effects, or motion.

// Use the variant the design system provides instead
<Button variant="danger" />;

You can also add exceptions, which can help with adopting this rule:

{
  "linter": {
    "rules": {
      "nursery": {
        "noTailwindRestyledComponents": {
          "level": "error",
          "options": {
            "allow": [
              { "components": ["Card"], "categories": ["spacing"] },
              { "components": ["Button"], "classes": ["hover:shadow-lg"] }
            ]
          }
        }
      }
    }
  }
}

Tailwind relies on string matching in order to detect tailwind classes. It scans your source code for the exact class strings, and only emits CSS for the matches. Without proper guidance, agents have a tendency to dynamically construct tailwind class strings. This causes the styles to be missing from your build output.

// Tailwind can't see the class!
<div className={`bg-${color}`} />;

The new nursery rule useTailwindStaticClassStrings, inspired by require-static-classes, flags dynamically built strings used to build class strings. It encourages using merge functions like clsx and cn instead.

<div className={active ? "bg-red-500" : "bg-blue-500"} />;
<div className={clsx(active && "bg-red-500", "text-white")} />;

All Tailwind rules will detect class strings in the exact same way, across JSX, TSX, HTML, Vue, Svelte and Astro files. The default settings should work out of the box for the majority of users, but you can configure how Biome detects class strings with the new tailwind top-level configuration:

{
  "tailwind": {
    "mergeFunctions": ["clsx", "cn", "twMerge"],
    "variantFunctions": ["cva", "tv"],
    "attributes": ["class", "className"]
  }
}

The new command biome inspect is the first step towards having better debugging tooling for both maintainers and users.

This command allows you to inspect the whole configuration or single values inside your project. What’s powerful about it is that this command is able to resolve extended configurations via extends, path overrides, configuration files inside monorepos, and you can also inspect single fields using the dot-notation style.

You can start by running the default command from the root of your project, and you’ll receive the final representation of your configuration file:

biome.jsonc configuration ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  i Resolved configuration from biome.jsonc.
  Configuration files used (merge order):
    - biome.jsonc
  {
    "formatter": {
      "lineWidth": 100
    },
    "overrides": [
      {
        "formatter": {
          "lineWidth": 120
        },
        "includes": [
          "**/*.test.js"
        ]
      }
    ]
  }
  i Overrides are included but were not evaluated because no --path was provided.

If you need to evaluate overrides, you must provide a --path to a file.

biome inspect config --path ./src/components

You can also inspect portions of the configuration file, or fields, using the dot-notation style. To inspect arrays, you must provide a number. Here are a few examples:

biome inspect config formatter # inspect the whole "formatter" object
biome inspect config formatter.lineWidth # inspect the "formatter.lineWidth" field
biome inspect config linter.rules.suspicious.noDebugger # inspect a lint rule
biome inspect config plugins.1 # inspect the first item in the "plugins" array

This command resolves all the plugins loaded by your project and lists all the rules that are enabled in your configuration file. This is useful if you use multiple plugins and you enable rules via presets, so it provides you with a clear list of all rules.

The command also shows if rules were improved from a local source (your project) or an external source (an npm package). Here’s an example of the output:

configuration ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  i The configuration enables 4 plugin rules for src/app.test.ts.
  @acme/accessibility
  - noAutofocus (listed directly, presets/recommended)
  - noPositiveTabindex (presets/recommended)
  - noRedundantRoles (presets/recommended)
  @acme/javascript
  - noAlert (presets/recommended, presets/strict)
  @acme/security
  - noDocumentWrite (presets/recommended)
  - noDynamicRequire (presets/recommended)
  @acme/testing
  - expectExpect (listed directly, presets/recommended, presets/strict)
  - noConditionalExpect (presets/recommended, presets/strict)

Given a file, this command shows debugging information such as its CST, typed CST, formatter IR, and Semantic Mode (if available). We think this command might come in handy if you write a plugin, and you need to look at the shape of the CST without looking at the playground. The command must accept a path to a file:

biome inspect file path/to/file.ts

Biome v2.6 now allows you to extend configuration files and plugins from many ancestors. We still have a hardcoded depth limit of ten levels to avoid possible overflows or cycles. This means that external packages can use extends from external packages, and so on. The end user just needs to consume the final configuration file or plugin.

With this update, we added a migration path from Stylelint. Biome can now automatically migrate your existing Stylelint configuration using the following subcommand:

biome migrate stylelint --write

This command will read your Stylelint configuration and attempt to port its rules and overrides to Biome, along with ignore patterns from both the ignoreFiles key in the configuration and the .stylelintignore file.

Given the following Stylelint configuration:

{
  "ignoreFiles": ["dist/**"],
  "rules": {
    "block-no-empty": true,
    "font-family-no-duplicate-names": true,
    "keyframe-declaration-no-important": true
  },
  "overrides": [
    {
      "files": ["*.scss"],
      "rules": {
        "block-no-empty": null
      }
    }
  ]
}

Running biome migrate stylelint --write will produce the following biome.json:

{
  "$schema": "<a href="https://biomejs.dev/schemas/2.6.0/schema.json" rel="nofollow">https://biomejs.dev/schemas/2.6.0/schema.json</a>",
  "vcs": { "enabled": false, "clientKind": "git", "useIgnoreFile": false },
  "files": { "ignoreUnknown": false },
  "formatter": { "enabled": true, "indentStyle": "tab" },
  "linter": {
    "enabled": true,
    "rules": {
      "preset": "none",
      "suspicious": {
        "noDuplicateFontNames": "error",
        "noEmptyBlock": "error",
        "noImportantInKeyframe": "error"
      }
    },
    "includes": ["**", "!dist/**"]
  },
  "javascript": { "formatter": { "quoteStyle": "double" } },
  "overrides": [
    {
      "includes": ["*.scss"],
      "linter": { "rules": { "suspicious": { "noEmptyBlock": "off" } } }
    }
  ],
  "assist": {
    "enabled": true,
    "actions": { "source": { "organizeImports": "on" } }
  }
}

The command needs Node.js to resolve the stylelint configuration file with its plugins. For now, biome migrate stylelint only supports Stylelint configurations written in JSON or JavaScript. YAML configurations are not supported yet.

By default, the command migrates identical rules only. Pass the --include-inspired flag to migrate inspired rules as well.

Promoted 59 nursery rules to stable groups.

Promoted the following rules to the correctness group with error severity. All of them are recommended:

• noDuplicateFieldDefinitionNames
• noVueRefAsOperand
• noVueImportCompilerMacros
• noVueVOnNumberValues
• useVueValidVFor
• noComponentHookFactories
• noJsxNamespace
• useReactAsyncServerFunction
• noReactNativeRawText
• useReactNativePlatformComponents
• useQwikLoaderLocation
• noPlaywrightMissingAwait
• usePlaywrightValidDescribeCallback

Promoted the following rules to the suspicious group:

• noLoopFunc
• noJsxLeakedDollar
• noReactStringRefs (recommended)
• noReactNativeDeepImports (recommended, error severity)
• noDrizzleDeleteWithoutWhere (recommended, error severity)
• noDrizzleUpdateWithoutWhere (recommended, error severity)
• noConditionalExpect
• useExpect
• noIdenticalTestTitle (recommended)
• noPlaywrightForceOption
• noPlaywrightNetworkidle
• noPlaywrightPagePause
• noPlaywrightWaitForNavigation
• noPlaywrightWaitForTimeout
• noDuplicateSelectors
• noEmptyObjectKeys
• noUntrustedLicenses
• useBaseline
• useScopedStyles (recommended)

Promoted useIframeSandbox to the security group with error severity.

Promoted the recommended rule useDomNodeTextContent to the performance group with warning severity.

Promoted the following rules to the complexity group:

• useArraySome
• useRegexpTest
• noUnnecessaryTemplateExpression
• noPlaywrightUselessAwait
• noExcessiveSelectorClasses
• useMathMinMax (recommended, warning severity)
• noExcessiveNestedCallbacks

Promoted the following rules to the style group with information severity:

• useVueConsistentDefinePropsDeclaration
• useVueNextTickPromise (recommended)
• noReactNativeLiteralColors
• useConsistentTestIt
• useTestHooksInOrder
• useTestHooksOnTop
• noPlaywrightEval
• noPlaywrightElementHandle
• noPlaywrightWaitForSelector
• useReduceTypeParameter
• useNamedCaptureGroup
• useUnicodeRegex
• useImportsFirst
• useVarsOnTop
• useThisInClassMethods
• noInlineStyles
• useDomQuerySelector
• noTopLevelLiterals

You can now install Biome on any platform using our new standalone installer:

# Linux or macOS
curl -fsSL <a href="https://biomejs.dev/install" rel="nofollow">https://biomejs.dev/install</a> | bash
# Windows PowerShell
irm <a href="https://biomejs.dev/install.ps1" rel="nofollow">https://biomejs.dev/install.ps1</a> | iex`

Among other things, Biome has undergone a very substantial rewrite of its architecture.

The main problem to solve was responsiveness in editors. Even though Biome is written in Rust and is superfast, working with an editor requires a completely different mindset from working with the CLI. In an editor, you need to provide a lot of information and a snappy DX as the user types, such as by reporting errors immediately.

This problem has surfaced multiple times for users with large files who have experienced delays in seeing diagnostics while typing. Not only that, but many of Biome’s internal operations were also repeated rather than cached, including the Node.js resolver, type inference, internal settings, and so on. This would result in a slowdown and a poor DX.

That’s where salsa comes into play. salsa is a framework for on-demand, incrementalized computation. Salsa is currently maintained by some members of the Astral team, and it currently powers the type inference system of ty.

Let’s use the computation of the semantic model with salsa as an example. When the semantic model of a JavaScript file is requested a second time and it hasn’t changed since the last operation, we get the semantic model from the salsa database. We avoid recomputing the same information every time.

salsa also provides a cancellation system that allows in-flight operations to be cancelled. Think of it as an advanced debounce. This is a very useful feature in editors. As you type, the LSP-based client (your editor) sends requests to the language server (Biome) with every keystroke, such as requests for diagnostics and code actions. Ordinarily, you wouldn’t see any problems with files of ~2k LoC, but at a larger scale, even the fastest language server would start having problems. With salsa’s cancellation system, we are guaranteed that an in-flight reading operation is cancelled if a writing operation changes the source code and that the latest operation is always executed.

The rewrite has been challenging. salsa has a completely different model that didn’t fit with how Biome used to work. Biome has the concept of a thread-friendly workspace server, which means that it can be sent across different threads and modified by them. On the other hand, salsa uses a model in which snapshots of its database are sent across different threads, and write operations can be performed only when those threads have gone out of scope.

Secondly, Biome must offer the same DX in both the CLI and the LSP. However, the two clients work differently from an architectural perspective. For example, the CLI is a one-shot operation, while the LSP is a long-running process in which different requests can come from different clients at different times in the process’s life cycle. The CLI is stateless, while the LSP is stateful and must keep track of information between operations.

After weeks of whiteboards and retries, we eventually found the perfect architecture for the new Biome. The CLI has become slightly faster and less noisy; it doesn’t have to recompute the settings every single time. The LSP is now snappier and faster, uses less memory, and can take advantage of the cancellation engine provided by salsa.

We have now completely rewritten our type inference engine.

Previously, Biome scanned the whole project and built all the types in one go before you could even use it. This meant that Biome built types for files that might not have needed to be analyzed. This was clearly more work—work that didn’t need to be done until a request arrived.

Now, with salsa, inference - specifically operations such as normalization, substitution, or transformation - is done on demand. When you run the noMisusedPromises lint rule, we first inspect a candidate expression and then try to infer and normalize the types from that expression. If a rule happens to inspect the same expression and request the same type, we get the memoized value, so we don’t do the same work twice.

The memoization strategy can work at the type level too. For example, let’s start with the premise that the engine wants to infer the return type of a function. Consider two functions that return Foo and Bar, respectively. The first time Biome needs to infer their types, it does so for both functions. If you edit Foo to Lorem, the next time Biome attempts to infer the types of those two functions, only the first function is inferred, while the type of the second function is retrieved from the salsa database because it hasn’t changed.

As mentioned before, all the types were inferred and normalized after the scanning phase. Additionally, we didn’t have in place a proper system to track the normalization. As a result, we had a lot of issues tracking down what parts of the engine were slower than the others.

With the rewrite, we also introduced a predictable way to measure the different parts of the inference engine. Biome v2.6 ships a new CLI argument --profile-type-inference that you can pass to the lint or check commands. Here’s an example of the output:

profiler ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  i Type inference profile (Biome <version>)
  src/index.ts
    Requests (top 5 of 12 groups; 28 source records; 46 executions)
      1. Promise classification <- nursery/noFloatingPromises
      ...
    Queries (top 8 of 25 groups; 61 source records; 94 executions)
      1. Promises / infer_expression_is_promise
      ...
    Whole-module inference (top 1 of 1 group; 1 source record; 1 execution)
      1. Import depth limit
      ...
  68 files omitted.
  ℹ To show all the information, use the --verbose option. The output might be very verbose, so it's advised to analyze a single file.
  $ biome lint --profile-type-inference --verbose ./path/to/file.ts

This will help both maintainers and end users triage bugs in the inference engine.

This blog post highlights the changes that we deem most exciting; however, many more changes await you, such as a Git-aware init command, new lint rule options, and more. Consult the detailed changelog to discover all changes.

I want to remind you that Biome is a project led by volunteers who enjoy programming, care about open source, and embrace the Biome philosophy, so any help is welcome.

Join our Discord server, and grab the @team-testers role. We will ping you from time to time, and we will ask you to test preview releases before they are released.

If you are familiar with Biome and would like to contribute to its outreach, you can assist us by translating the website into your native language. In this dashboard, you can check the supported languages and whether they are up-to-date.

Join our Discord server, and engage with the community. Chatting with the community and being part of the community is a form of contribution.

If you like the technical aspects of the project, and you want to make your way into the Rust language, or practice your knowledge around parsers, compilers, analysers, etc., Biome is the project for you!

There are numerous aspects to explore; I assure you that you won’t get bored. Here is a small list of the things you can start with:

• Create new lint rules! We have so many rules that we haven’t implemented yet (ESLint, ESLint plugins, Next.js, Solid, etc.). We have a very extensive technical guide.
• Implement new capabilities in our LSP (Language Server Protocol), or add new features in one of our editor extensions: VS Code, Zed, and JetBrains IntelliJ.

If you believe in the future of the project, you can also help with a financial contribution via Open Collective or GitHub Sponsors.

Additionally, the project provides an enterprise support program where you as a company can employ one of the core contributors to work on a specific aspect of the Biome toolchain.