Biome | Blog

Biome v2.4—Embedded Snippets, HTML Accessibility, and Better Framework Support

Tue, 10 Feb 2026 00:00:00 GMT

Biome v2.4 is the first minor release of the year! After more than ten patches from v2.3, today we bring to you a new version that contains many new features!

Once you have upgraded to Biome v2.4.0, migrate your Biome configuration to the new version by running the migrate command:

biome migrate --write

Highlights

Among all the features shipped in this release, here are the ones we think you’re going to like most!

Embedded snippets in JavaScript
Editor inline configuration
Major improvements to HTML-ish languages
HTML accessibility rules
Rule profiler
Configuration file discovery

Embedded snippets in JavaScript

One of the most significant new features in Biome 2.4 is the ability to format and lint embedded CSS and GraphQL snippets within JavaScript files. Enable this experimental feature to automatically format and lint CSS and GraphQL code within template literals.

Biome recognizes CSS snippets from styled-components, Emotion, and similar CSS-in-JS libraries:

styled-components.js

import styled from "styled-components";

const Foo = styled.div`
  display: flex;
  color: red;
`;

GraphQL queries and mutations within JavaScript are now properly formatted and linted:

graphql-query.js

import gql from "graphql-tag";

const PeopleCountQuery = gql`
  query PeopleCount {
    allPeople {
      totalCount
    }
  }
`;

To enable these features, add this to your configuration:

biome.json

{
  "javascript": {
    "experimentalEmbeddedSnippetsEnabled": true
  }
}

Editor inline configuration

Editors can now inject a Biome configuration to the Biome Language Server without affecting the project’s configuration.

If you have a Biome extension compatible with your LSP-ready editor, you can map inlineConfig. The configuration will be merged with the project’s configuration and it will take precedence.

In the following example, the editor won’t emit any diagnostics for the rule noConsole, but the CLI will still conform to the configuration of the project.

Zed
VS Code

.zed/settings.json

{
  "lsp": {
    "biome": {
      "settings": {
         "inline_config": {
        "linter": {
          "rules": {
            "suspicious": {
              "noConsole": "off"
            }
          },
        }
      }
      }
    }
  }
}

.vscode/settings.json

{
  "biome.lsp": {
    "inlineConfig": {
    "linter": {
      "rules": {
        "suspicious": {
          "noConsole": "off"
        }
      },
    }
  }
  }
}

Major improvements to HTML-ish languages

In Biome v2.3, we announced experimental full support for HTML-ish languages such as Vue, Svelte, and Astro. We’ve since focused on improving the developer experience based on community feedback. Several improvements were shipped in patch releases.

Biome 2.4 brings significantly improved parsing for Vue and Svelte, resulting in better formatting across the board. Additionally, the rules noUnusedVariables, useConst, useImportType and noUnusedImports have been substantially improved, so you will see fewer false positives.

All these improvements are visible only when the flag html.experimentalFullSupportEnabled is set to true. If you previously used the overrides configuration workaround to disable certain rules, you can now remove it. If you encounter false positives, please report them in this issue. We now have the infrastructure to address these problems.

The CSS parser can now parse Vue SFC syntax such as :slotted, :deep, and v-bind(), as well as :global and :local inside .astro, .svelte and .vue files.

HTML accessibility rules

Biome 2.4 introduces 15 comprehensive accessibility-focused lint rules for HTML, helping you build more accessible web applications:

These rules work seamlessly with Vue, Svelte, and Astro files. Please help us to ship more a11y rules.

Rule profiler

The commands lint and check now have a --profile-rules flag. This flag enables the new internal profiler, which allows you to capture the execution time of lint rules, assist actions, and GritQL plugins.

The profiler tracks only the execution time of the rule, and it doesn’t track the time spent in querying Biome’s CST. The flag will print an output similar to this one:

Rule execution time (does not include any preprocessing)
  total       avg         min         max         count rule
    42.069ms     1.010µs    41.000ns   227.625µs  41633  correctness/noUnusedVariables
    23.131ms   452.000ns    42.000ns   330.750µs  51096  suspicious/noFocusedTests
     9.864ms   193.000ns     0.000ns   149.375µs  51046  suspicious/noConsole
     8.074ms   198.000ns     0.000ns   141.208µs  40721  correctness/noUnusedFunctionParameters
     7.963ms   137.000ns     0.000ns   263.958µs  57899  style/useNodejsImportProtocol
     6.711ms     4.355µs    41.000ns   686.000µs   1541  source/organizeImports
     4.076ms   664.000ns     0.000ns   132.792µs   6130  correctness/noUnusedImports
     4.015ms    55.000ns     0.000ns   131.250µs  72343  correctness/noTypeOnlyImportAttributes
     3.320ms   524.000ns     0.000ns   115.791µs   6334  style/useImportType
   384.101µs   164.000ns     0.000ns    74.875µs   2328  correctness/noNodejsModules
   384.042µs     2.782µs    42.000ns   163.417µs    138  correctness/noDuplicatePrivateClassMembers
    10.753µs   282.000ns    83.000ns   833.000ns     38  correctness/noSuperWithoutExtends

One way to interpret the data is to check the rules/actions that have low counts, and check their execution time. For example, if the execution time feels way too high compared to what it should be, maybe it’s a good place to look for possible optimizations. Since we landed this feature, we have found some bottlenecks that we have fixed since then.

Configuration file discovery

Biome 2.4 improves configuration file discovery in two major ways:

Hidden configuration files: Biome now loads .biome.json and .biome.jsonc files. The loading order is: biome.json → biome.jsonc → .biome.json → .biome.jsonc
Config home directories: Biome now attempts to load configuration files from platform-specific config directories:
- $XDG_CONFIG_HOME or $HOME/.config/biome on Linux
- /Users/$USER/Library/Application Support/biome on macOS
- C:\Users\$USER\AppData\Roaming\biome\config on Windows

The priority order is: project folder (working directory) → parent folders → config home.

Linter and Assist

New Assist Actions

Remove Duplicate CSS Classes

Biome 2.4 introduces the noDuplicateClasses assist action to detect and remove duplicate CSS classes.

For JSX files: Supports class, className attributes and utility functions like clsx, cn, cva.

For HTML files: Checks class attributes. This is the first assist action for HTML.

example.jsx

// Before
<div class="flex p-4 flex" />;

// After
<div class="flex p-4" />;

Thank you @mldangelo .

Sort Interface Members

Added a new assist action useSortedInterfaceMembers that sorts TypeScript interface members for improved readability. It includes an autofix.

Before:

example.ts

interface MixedMembers {
  z: string;
  a: number;
  (): void;
  y: boolean;
}

After:

example.ts

interface MixedMembers {
  a: number;
  y: boolean;
  z: string;
  (): void;
}

Enhanced Lint Rules

`useSortedKeys` with `groupByNesting` Option

Added groupByNesting option to the useSortedKeys assist. When enabled, object keys are grouped by their value’s nesting depth before sorting alphabetically.

Simple values (primitives, single-line arrays, and single-line objects) are sorted first, followed by nested values (multi-line arrays and multi-line objects).

biome.json

{
  "assist": {
    "actions": {
      "source": {
        "useSortedKeys": {
          "level": "on",
          "options": {
            "groupByNesting": true
          }
        }
      }
    }
  }
}

`useHookAtTopLevel` with `ignore` Option

Added ignore option to the useHookAtTopLevel rule. You can now specify function names that should not be treated as hooks, even if they follow the use* naming convention.

biome.json

{
  "linter": {
    "rules": {
      "correctness": {
        "useHookAtTopLevel": {
          "options": {
            "ignore": ["useDebounce", "useCustomUtility"]
          }
        }
      }
    }
  }
}

`useIterableCallbackReturn` with `checkForEach` Option

The rule useIterableCallbackReturn now supports a checkForEach option. When set to false, the rule will skip checking for forEach() callbacks for returning values.

Improved `useHookAtTopLevel` Detection

Updated useHookAtTopLevel to better catch invalid hook usage. The rule now generates diagnostics if:

A hook is used at the module level (top of the file, outside any function)
A hook is used within a function or method which is not a hook or component, unless it is a function expression (such as arrow functions commonly used in tests)

`useImportExtensions` with Custom Mappings

Added the extensionMappings option to useImportExtensions. This allows you to specify custom file extensions for different module types. For example, to ban all .ts imports in favor of .js imports:

biome.json

{
  "linter": {
    "rules": {
      "nursery": {
        "useImportExtensions": {
          "level": "error",
          "options": {
            "extensionMappings": {
              "ts": "js"
            }
          }
        }
      }
    }
  }
}

`useUnifiedTypeSignatures` Enhancements

Added 2 options from typescript-eslint to useUnifiedTypeSignatures:

ignoreDifferentlyNamedParameters - Ignores overload signatures whose parameter names differ
ignoreDifferentJsDoc - Ignores overload signatures whose JSDoc comments differ

Ignore Options for CSS Rules

Added ignore option to noUnknownProperty, noUnknownFunction, noUnknownPseudoClass, and noUnknownPseudoElement. If an unknown property/function/selector name matches any of the items provided in ignore, a diagnostic won’t be emitted.

Improved Svelte Variables Detection

Improved the rule noUnusedVariables in Svelte files by correctly detecting variables defined in the JavaScript blocks and used inside the templates.

New Linter Domain: `types`

Biome 2.4 introduces a new linter domain called types. This domain enables all rules that require the type inference engine to function.

As opposed to the project domain (which only enables rules that require the module graph), the types domain specifically targets rules that need type information.

The following nursery rules have been moved to the types domain:

useArraySortCompare
useAwaitThenable
useFind
useRegexpExec
noUnnecessaryConditions
noMisusedPromises
noFloatingPromises

This allows you to enable or disable type-based linting more granularly using the --only and --skip flags.

Promoted Rules

Biome 2.4 promotes 24 nursery rules to stable groups, making them production-ready.

Correctness Rules

Promoted the following rules to the correctness group:

noUnresolvedImports - Reports imports that cannot be resolved
noVueReservedProps - Reports Vue reserved props usage
noVueReservedKeys - Reports Vue reserved keys usage
noVueDataObjectDeclaration - Reports Vue 2 data declared as an object instead of a function
noNextAsyncClientComponent - Reports async Next.js client components
noVueDuplicateKeys - Reports duplicate keys in Vue component options
noVueSetupPropsReactivityLoss - Reports destructuring of props in Vue 3 setup which causes reactivity loss
useQwikMethodUsage - Enforces correct Qwik framework method usage
useQwikValidLexicalScope - Enforces valid lexical scope in Qwik framework

Suspicious Rules

Promoted the following rules to the suspicious group:

noImportCycles - Reports circular imports
noDeprecatedImports - Reports imports of deprecated symbols
noReactForwardRef - Reports usage of React.forwardRef
noUnusedExpressions - Reports expressions that are never used
noEmptySource - Reports empty source files
useDeprecatedDate - Enforces use of GraphQL @deprecated directive with date
noDuplicateDependencies - Reports duplicate dependencies in package.json

Complexity Rules

Promoted the following rules to the complexity group:

noUselessUndefined - Reports useless undefined initialization and returns
useMaxParams - Enforces a maximum number of function parameters
noUselessCatchBinding - Reports useless catch binding parameters

Style Rules

Promoted the following rules to the style group:

useConsistentArrowReturn - Enforces consistent return in arrow functions
noJsxLiterals - Reports literal strings in JSX

Formatter

Embedded Snippets Formatting

Biome 2.4 can now format embedded CSS and GraphQL snippets within JavaScript files. See the Embedded snippets in JavaScript section in Highlights for details and examples.

Trailing Newline Option

Added the formatter option trailingNewline. When set to false, the formatter will remove the trailing newline at the end of formatted files. The default value is true, which preserves the current behavior.

This option is available globally and for each language-specific formatter configuration:

biome.json

{
  "formatter": {
    "trailingNewline": false
  },
  "javascript": {
    "formatter": {
      "trailingNewline": true
    }
  }
}

CLI flags are also available: --formatter-trailing-newline, --javascript-formatter-trailing-newline, --json-formatter-trailing-newline, etc.

Top-Level Suppression Comments

Added support for the top-level suppression comment biome-ignore-all format: <explanation>. When placed at the beginning of the document, Biome won’t format the code.

generated.js

// biome-ignore-all format: generated

const a = [];
const b = [];

Formatting Applied with Code Fixes

Formatting is now applied when applying safe/unsafe fixes via biome check. This ensures your code is properly formatted after applying automated fixes.

CSS Parser Improvements

CSS `@function` At-Rule Support

Added support for parsing and formatting the CSS @function at-rule from the CSS Mixins Module Level 1 specification:

styles.css

@function --transparent(--color <color>, --alpha <number>: 0.5) returns <color> {
  result: oklch(from var(--color) l c h / var(--alpha));
}

CSS Modules Auto-Detection

Biome now automatically enables CSS modules parsing for *.module.css files. If your codebase only uses *.module.css files, you can remove the manual parser configuration.

CSS Properties Ordering Update

Updated the CSS properties ordering to align with stylelint-config-recess-order v7.4.0, adding support for containment properties, font synthesis properties, ruby properties, color adjustment properties, view transitions properties, shapes properties, motion path properties, and more.

CSS Module Syntax in Vue/Svelte/Astro

Added support for parsing :global and :local inside .astro, .svelte and .vue files, in the <style> portion of the file. This capability is only available when experimentalFullHtmlSupportEnabled is set to true.

CLI

Enhanced `--skip` and `--only` Flags

Added --only and --skip options to biome check and biome ci, covering both lint diagnostics and assist actions. You can now run or exclude specific:

Lint rules
Assist actions
Groups of rules and actions
Domains (including the new types domain)

Examples:

biome check --only=suspicious/noDebugger src/**/*.js
biome ci --skip=project src/**
biome lint --only=types  # Run only type-based rules

Multiple Reporters and Reporter Output to Files

Biome 2.4 adds support for multiple reporters and the ability to save reporter output to arbitrary files.

Combine Multiple Reporters in CI

If you run Biome on GitHub, you can now use both the default reporter and the GitHub reporter:

biome ci --reporter=default --reporter=github

Save Reporter Output to a File

With the new --reporter-file CLI option, it’s now possible to save the output of all reporters to a file:

biome ci --reporter=rdjson --reporter-file=/etc/tmp/report.json
biome ci --reporter=summary --reporter-file=./reports/file.txt

You can combine these two features. For example, have the default reporter written on terminal, and the rdjson reporter written on file:

biome ci --reporter=default --reporter=rdjson --reporter-file=/etc/tmp/report.json

The --reporter and --reporter-file flags must appear next to each other.

New SARIF Reporter

Added a new reporter --reporter=sarif, that emits diagnostics using the SARIF format. This is particularly useful for integrating Biome with security and code quality platforms.

biome ci --reporter=sarif --reporter-file=biome-results.sarif

File Watcher Control

Added new CLI options to the commands lsp-proxy and start that allow control over the Biome file watcher:

--watcher-kind (env: BIOME_WATCHER_KIND): Controls how the Biome file watcher behaves. Options: recommended (default), polling, or none.
--watcher-polling-interval (env: BIOME_WATCHER_POLLING_INTERVAL): The polling interval in milliseconds when using polling mode (defaults to 2000ms).

Enhanced Logging Options

Revamped the logging options for all Biome commands. The commands format, lint, check, ci, search, lsp-proxy and start now accept consistent logging CLI options with environment variable aliases:

--log-file (env: BIOME_LOG_FILE) - Optional path/file to redirect log messages to
--log-prefix-name (env: BIOME_LOG_PREFIX_NAME) - Allows changing the prefix applied to the file name of the logs (daemon only)
--log-path (env: BIOME_LOG_PATH) - Allows changing the folder where logs are stored (daemon only)
--log-level (env: BIOME_LOG_LEVEL) - The level of logging: debug, info, warn, error, or none
--log-kind (env: BIOME_LOG_KIND) - What the log should look like

Stacktrace for Fatal Errors

It’s now possible to provide the stacktrace for a fatal error. The stacktrace is only available when the environment variable RUST_BACKTRACE=1 is set:

RUST_BACKTRACE=1 biome lint

Additional Features

GritQL JSON Support

Added JSON as a target language for GritQL pattern matching. You can now write Grit plugins for JSON files, enabling:

Searching and transforming JSON configuration files
Enforcing patterns in package.json and other JSON configs
Writing custom lint rules for JSON using GritQL

Example patterns:

Match all key-value pairs:

pattern.grit

language json
pair(key = $k, value = $v)

Match objects with specific structure:

pattern.grit

language json
JsonObjectValue()

Supports both native Biome AST names (JsonMember, JsonObjectValue) and TreeSitter-compatible names (pair, object, array) for compatibility with existing Grit patterns.

For more details, see the GritQL documentation.

LSP and Editor Features

LSP Progress Reporting

The Biome Language Server now reports progress while scanning files and dependencies in the project, providing better feedback during long-running operations.

Configuration and Editor Support

Cursor Files Support

Added support for Cursor files. When Biome sees a Cursor JSON file, it will parse it with comments enabled and trailing commas enabled:

$PROJECT/.cursor/
%APPDATA%\Cursor\User\ on Windows
~/Library/Application Support/Cursor/User/ on macOS
~/.config/Cursor/User/ on Linux

Other Improvements

Vue SFC CSS Syntax Support

The Biome CSS parser is now able to parse Vue SFC syntax such as :slotted, :deep, and v-bind(). These pseudo-functions and directives are only correctly parsed when the CSS is defined inside .vue components.

This capability is only available when experimentalFullHtmlSupportEnabled is set to true.

e18e ESLint Plugin Support

Added e18e ESLint plugin as a recognized rule source. Six Biome rules now reference their e18e equivalents: useAtIndex, useExponentiationOperator, noPrototypeBuiltins, useDateNow, useSpread, and useObjectSpread.

More Improvements

In addition to the features highlighted above, Biome 2.4 includes numerous bug fixes, performance improvements, and smaller enhancements across the toolchain. For a complete list of changes, refer to the changelog page.

I like where this is going, how can I help?

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

Translations

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 if they are up-to-date.

Chat with us

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

Code contributions

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.
Help building Biome parsers! One interesting fact about Biome parsers is that they are recoverable parsers error resilient which emit a CST instead of a classic AST.
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.

Financial help

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 a specific aspect of the Biome toolchain.

Roadmap 2026

Wed, 21 Jan 2026 00:00:00 GMT

In this article, we want to share with you all our roadmap for 2026!

The roadmap is a collection of ideas and interests that the maintainers of the project collect from various sources: user’s feedback, personal interests, time available to dedicate to the project, user’s proposal from GitHub discussions.

The roadmap represents the overall direction that we want to take; however, things can change overtime.

2025 achievements

We shipped Biome v2, which brought amazing new features to the ecosystem:
- Support for nested configuration files, and better support in monorepos.
- First tool to ship type-aware lint rules that don’t rely on the TypeScript compiler (commonly known as tsc), thanks to its inference engine, sponsored by Vercel.
- Support for project lint rules, such as noImportCycle.
- Shipped the new concept of linter domains, a way to group different rules under different umbrellas, and a way to turn on those rules automatically based on your dependencies.
- Added support for plugins via GritQL. Throughout the year the plugin engine has become even more powerful, allowing users to query the Biome CST and report custom diagnostics.
- Shipped the new JavaScript import and export organizer that provides advanced features like import merging, and custom import groups.
We shipped three new minors after v2, which have added many new features:
- Support for Tailwind syntax in CSS files
- Experimental full support of parsing, formatting, linting for Vue, Svelte, and Astro. The language capabilities of Biome have improved and allow them to inspect multiple languages in the same document.
- We improved and fixed many bugs around the Biome watcher and scanner. Some of those bugs caused some memory leaks, causing Biome to be unusable for some users.
Depot has become a platinum sponsor.
We have surpassed 15 million monthly downloads.
GritQL has now become part of the Biome organization.

Past mistakes

Of course, Biome and team are far from being perfect, so we want to acknowledge some of our past mistakes that we hope to address this year. We want to address them moving forward.

Monorepo out of the box

Biome is able to discover nested ignore files and nested configuration files out of the box, without any particular configuration. While this provides an optimal DX, it uncovered some undesired situations where memory leaks get out of hand. Also, in some cases, users don’t have enough control over the folders that are real libraries.

Difficult to debug

With so many features, we overlooked the debugging capabilities of the tool. With the rise of tools such as ultracite, big monorepos, overrides, extends, and more, it has become difficult to understand and debug a complex configuration file. This is frustrating for both maintainers and users.

Poor communication

Later last year, we announced the experimental full support of Vue, Svelte, and Astro. Many users weren’t happy about how we framed the announcement, especially after some users rightfully complained about the poor support of the Svelte files.

2026 roadmap

I can’t stress enough that Biome is a community-driven project, all the features we want to implement are driven by our passions and needs. We can’t promise that all of these features will be implemented. Alas, we will try our best to stay aligned and deliver what’s listed below.

JavaScript embedded languages: improve the DX of the embedded languages in JavaScript, such as CSS and GraphQL.
Stabilize everything around HTML
- Improve HTML formatting so that its formatting matches Prettier’s as much as possible.
- Enhance existing lint rules so that they work for HTML-ish languages too, notably Vue, Svelte, and Astro
Cross-language lint rules: we want to explore and deliver lint rules that work across languages. Now that Biome has the infrastructure to do so, we might be able to achieve it. What’s a cross-language lint rule, you ask? Here’s an example: have you ever discovered a CSS class not used anywhere? What if there was a lint rule able to discover all your CSS styles, and check if they are actually used inside JSX/HTML-ish files? That’s where a cross-language lint rule comes into play!
Opt-in, improved workspaces: this is mostly an idea, but we want to address the poor DX introduced by monorepo-out-the-box, by making it opt-in and offer better control. For example, we envision a solution where the configuration might look like this:
biome.json
```
{
  "workspaces": [
    "packages/*",
    "utilities/*"
  ]
}
```
With a configuration like this, Biome knows where to look for possible nested configuration files. We believe a solution like this might improve the DX and the performance of the tool.
SCSS support: we want to ship SCSS support. It was our most wanted. We recently closed it, and started the works.
More lint rules and assist actions: keep shipping new lint rules, and assist actions. We recently started implementing Accessibility lint rules for HTML-ish languages.
Improve LSP features: we want to explore and ship more LSP features. Internally, Biome has a module graph that can analyze and link with each other different files, such as JavaScript, CSS, and more. We want to explore and ship more IDE capabilities, such as the ability to highlight a reference such as a CSS class inside a JSX snippet, and allow users to navigate to its declaration inside the CSS file with a click.
Stabilize YAML: our YAML parser is almost ready! Once the parsing is stable enough, formatting is just right there.

Markdown

We really wish to implement the parsing of Markdown; however, we don’t have enough time and resources to look into it. If there’s someone who wishes to help, please let us know on Discord! We’re looking for a champion who would help with the implementation and the reviews.

Can I help move Biome’s roadmap forward?

We’re glad you asked! Biome is a project led by volunteers who like programming, open-source, and who embrace the Biome philosophy, so any help is welcome 😁

Chat with us

Join our Discord server, and engage with the community. You may always ask around if there’s something you can help with.

We also have a GitHub umbrella issue that you can check out, but please be cautious to not start any work until you’ve engaged with the community first. This way we can be mindful of your contributions too.

Financial help

If you believe in the long-term vision of Biome, you can also help with a financial contribution, via Open Collective or GitHub Sponsors.

Additionally, the project provides an enterprise support program that companies can use to contract a core contributor to work on a specific aspect of the Biome toolchain.

GritQL accepted by the Biome organisation

Thu, 18 Dec 2025 00:00:00 GMT

Today, we are happy and grateful to make a special announcement regarding the continuation of GritQL.

Some observant members of the Biome and GritQL communities may have already spotted that something big was happening behind the scenes: Biome is now the proud owner of the GritQL repositories.

Ever since Biome 2.0, GritQL plugins have been supported as a mechanism to add custom linter rules to your project. We took a big gamble here, as GritQL was being pioneered by a startup led by Morgante Pell and the future of the language was still uncertain.

We took a leap of faith, because we believed in Morgante’s vision of how GritQL can make plugin writing more intuitive for our end users. The expressive power of GritQL makes it so that end users can intuitively understand how to write plugins, even if they’re not familiar with the internals of AST structures themselves.

When Honeycomb acquired Grit earlier this year, and the future of the language looked unclear, it appeared our gamble was coming back to bite us. But thankfully, we’re excited to share that Morgante and Honeycomb have graciously agreed to donate the GritQL repositories to Biome.

So, does that mean Biome is now responsible for the development of GritQL?

Yes, it does.

But Morgante’s gift came with something even more precious: he personally joined the Biome maintainers team. From under the Biome umbrella, he can continue working on GritQL and our plugin infrastructure as he sees fit.

Please keep in mind that all Biome maintainers are volunteers, as most of us work on Biome in our free time. We have a respectful community that understands this, and this is something we continue to treasure.

What does this mean for Biome’s plugin infrastructure, concretely?

It’s hard to say exactly.

Early 2024, we drafted our initial Plugin Proposal RFC. The release of Biome 2.0 in June 2025 saw the first realisation of Biome’s vision in the form of GritQL linter plugins. That leaves a lot of work on the table still, but as usual we’ll keep you posted.

Where does this leave JavaScript/TypeScript plugins?

We do recognise that not everyone likes writing plugins using GritQL.

As the RFC mentioned, we also intend to work towards support for JS/TS plugins too. This August, we integrated Boa as a JavaScript interpreter that we can integrate into Biome. Back in 2024, Morgante also proposed a TypeScript API for GritQL so that users may or may not be able to use both forms of plugin functionality together. We don’t know how this will pan out yet, but hopefully with Morgante’s commitment, some of the work may speed up a bit.

Can I help move Biome’s plugin efforts forward?

We’re glad you asked! Biome is a project led by volunteers who like programming, open-source, and who embrace the Biome philosophy, so any help is welcome 😁

Chat with us

Join our Discord server, and engage with the community. We have a dedicated #plugins channel that can be used for this purpose. You may always ask around if there’s something you can help with.

Financial help

If you believe in the long-term vision of Biome, you can also help with a financial contribution, via Open Collective or GitHub Sponsors.

Additionally, the project provides an enterprise support program that companies can use to contract a core contributor to work on a specific aspect of the Biome toolchain.

Acknowledgements

Thanks again to both Morgante and Honeycomb for making this possible! And another round of thanks for our amazing community whom we are enjoying so much trust from! 💗

Depot becomes Biome's exclusive platinum sponsor

Mon, 01 Dec 2025 00:00:00 GMT

As of today, we’re happy to announce that Depot has become Biome’s exclusive platinum sponsor!

Biome by the numbers

Biome is a big Rust project, that keeps growing over time. As of 17 November (time of writing of the blog post), the project has the following stats:

A total of 90 internal crates (AKA biome_* crates) that are compiled and shipped in production.
~651,971 lines of code between production code and test code.
~3,217 Rust files, between production code and test code.

Since Rust is a compiled language, with complex syntax, the resources required for compilation, testing, etc. are bound to increase over time. Before Depot came to the rescue, Biome used to use GitHub Action runners. Here’s a few numbers:

Linting for pull requests took around ~15 minutes.
Tests for pull requests took around ~20 minutes.
Benchmarks for pull requests took around ~30 minutes. Benchmarks take longer because the code is compiled in production mode, and we make sure to stress test our infrastructure by feeding the benchmarks very complex inputs.
A release might have required up to ~45 minutes.
At some point, Biome on Windows couldn’t compile due to the memory required, which exceeded the memory available in the GitHub Actions runners.

Enter Depot

I discovered Depot by chance on social media. Someone thanked them for sponsoring their Rust project, so I reached out to see if they’d be willing to sponsor Biome. Jacob Gillespie, CTO and Co-Founder at Depot, was incredibly responsive and eager to support us.

Depot started sponsoring Biome’s GitHub infrastructure months ago as a gold sponsor. With their faster GitHub Actions runners, our workflows saw dramatic improvements:

Workflow	Before (GitHub runners)	After (Depot)
Linting	~15 minutes	~2 minutes
Tests	~20 minutes	~4 minutes
Benchmarks	~30 minutes	~15 minutes
Releases	~45 minutes	~25 minutes

Depot’s impact on the ecosystem

These aren’t just numbers. Having a faster CI has had a significant positive impact to maintainers, contributors and end-users.

Maintainers

We’ve seen positive outcomes throughout the entire project management process. We’re able to get faster feedback from our CI jobs, release more frequently and with more confidence, and we can fix CI issues faster. As you know, CI is a YOLO practice!

Contributors

Contributors can see the effect of their PRs way faster than before, and they can fix possible bugs promptly. This means that by the time a maintainer comes and reviews the PR, it might be approved already because the CI is green! One reason why we’re able to ship so many fixes in every patch release.

End-users

End-users - you, the developers - can enjoy that fix you needed sooner than before!

Depot’s endorsement

As Vercel did before, Depot believes that Biome’s inference engine can and will improve the developer experience even further.

Depot believes in Biome’s mission, a unified toolchain where users can think less about their tools and dependencies, and more about building their own software using modern practices.

Thank you, Depot!

I like where this is going, how can I help?

I want to remind you that Biome is a project led by volunteers who like programming, open-source, and embrace the Biome philosophy, so any help is welcome 😁

Translations

Chat with us

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

Code contributions

If you like the technical aspects of the project, and you want to make your way into the Rust language, or you wish to practice your knowledge around parsers, compilers, analysers, etc., Biome is the project that does 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.
Help building Biome parsers! One interesting fact about Biome parsers is that they are recoverable parsers error resilient which emit a CST instead of a classic AST.
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.

Financial help

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 that allows companies to employ one of the core contributors to work on a specific aspect of the Biome toolchain.

Biome v2.3—Let's bring the ecosystem closer

Tue, 07 Oct 2025 00:00:00 GMT

We’re excited to announce the release of Biome 2.3, bringing several features that have been highly requested by the community. This release marks a significant milestone in our journey to support the broader web ecosystem.

Once you have upgraded to Biome v2.3.0, migrate your Biome configuration to the new version by running the migrate command:

biome migrate --write

Full support for Vue, Svelte, and Astro

Biome 2.3 introduces full support for Vue, Svelte, and Astro files. This means you can now format and lint the JavaScript and TypeScript code inside <script> tags, as well as the CSS inside <style> tags in these frameworks. The HTML/template portions of these files are also parsed and formatted according to Biome’s HTML formatting rules.

This achievement wouldn’t have been possible without the great efforts of Core Contributor @ematipico and Core Contributor @dyc3 .

This is a feature that many developers have been asking for, and we’re thrilled to finally deliver it. Achieving this has had its challenges, and it required extensive trials to get the architecture right based on the constraints of the toolchain.

However, this feature is marked as experimental for several important reasons. First, these frameworks have their own specific syntaxes and idioms that extend beyond standard HTML, CSS, and JavaScript. While we’ve done extensive work to handle many patterns, there are cases and framework-specific syntaxes that may not yet be fully supported (for example Svelte control-flow syntax, or Astro JSX-like syntax). We encourage you to avail of this new feature, and fine-tune it based on your needs and possible limitations found.

Please open a discussion if you find something that hasn’t been implemented, or an issue if there’s a parsing error that should be handled correctly.

To enable the feature, you’ll have to opt in the new html.experimentalFullSupportEnabled option:

biome.json

{
  "html": {
    "experimentalFullSupportEnabled": true
  }
}

Script and style indentation

Additionally, you can configure specific formatting options for HTML content, such as whether to indent the content of <script> and <style> tags:

biome.json

{
  "html": {
    "formatter": {
      "indentScriptAndStyle": true
    }
  }
}

file.vue

<script setup lang="ts">
const foo = "bar";
    const foo = "bar";
</script>

file.svelte

<script lang="ts">
const foo = "bar";
    const foo = "bar";
</script>

file.astro

---
const foo = "bar";
    const foo = "bar";
---

By default, indentScriptAndStyle is set to false to match Prettier’s behavior.

Possible inconsistencies

With this release, we step into something new that needs to be addressed and discussed. In Biome you can configure each language as you see fit, which means that a project might end up with different formatting (as example).

In the following configuration file, JavaScript files are formatted using double quotes, while CSS files are formatted using single quotes.

{
  "html": {
    "formatter": { "enabled": true },
    "experimentalFullSupportEnabled": true
  },
  "javascript" : {
    "formatter": {
      "quoteStyle": "double"
    }
  },
  "css": {
    "formatter": {
      "quoteStyle": "single"
    }
  }
}

Why would someone want that? That’s not for us to answer, however with a configuration like this you would end with different quotes inside your HTML-ish files. This could cause inconsistencies inside the same. We created a GitHub discussion to understand if this is a problem, and if so, how Biome should solve it. Please let us know what do you think.

New ignore syntax

Biome 2.3 introduces a refined syntax for ignoring paths in your project, addressing important problems that arose since the introduction of multi file analysis and TypeScript inference.

When Biome 2.0 came out, we internally introduced the concept of “paths being indexed”. When a path is indexed, Biome parses it and updates the module graph and the type inference, if enabled.

However, we slowly came to the realization that multi-file analysis and type inference are very complex problems that can get out of hand easily.

For example, type inference can enter a very nasty loop where tons of types are recursively indexed, consuming a lot of memory.

As for multi-file analysis, the node_modules/ folder can be a rabbit hole, full of symbolic links with high depths and path names that exceed the maximum allowed characters.

Solving these complex problems takes time, a lot of testing and patience from us and the community. With this new syntax, users have now more control over what Biome can and can’t do.

With this release, two syntaxes are now available:

! (single exclamation mark): Ignores the path from linting and formatting, but still allows it to be indexed by the type system. This is useful for generated files or third-party code that you don’t want to format or lint, but still need for type inference and imports.
!! (double exclamation mark): Completely ignores the path from all Biome operations, including type indexing. This is useful for files that should be entirely excluded from Biome’s analysis, such as dist/ folders.

This distinction is particularly important when working with TypeScript projects that rely on type inference from dependencies or generated code. By using !, you can exclude these files from formatting and linting while still maintaining correct type information across your project.

Here’s an example configuration:

biome.json

{
  "files": {
    "includes": [
      "**",
      "!**/generated",
      "!!**/dist"
    ]
  }
}

In this configuration, files in the generated/ directory are ignored for formatting and linting but remain indexed for types and module graph, while files in dist/ directory are completely excluded from all Biome operations.

This is an important tool at your disposal that allows you to control Biome, and avoid possible slowness and memory leaks.

As result, the option files.experimentalScannerIgnores has been deprecated. We plan to remove this option in the next releases. Run the biome migrate command update your configuration file.

Great shoutout to Core Contributor @arendjr for implementing this new feature.

Tailwind v4 support

Core Contributor @dyc3 worked really hard, and he shipped for us native support of tailwind files!

This is a opt-in feature of the CSS parser, and you can enable it using the new css.parser.tailwindDirectives option:

biome.json

{
  "css": {
    "parser": {
      "tailwindDirectives": true
    }
  }
}

tailwind.css

@utility container {
    margin-inline: auto;
    padding-inline: 2rem;
}
@theme {
    --color-*: intial;
}

Lint rules

Promoted rules

Promoted noNonNullAssertedOptionalChain to the suspicious group
Promoted useReactFunctionComponents to the style group
Promoted useImageSize to the correctness group
Promoted useConsistentTypeDefinitions to the style group
Promoted useQwikClasslist to the correctness group
Promoted noSecrets to the security group

Removed rules

Removed nursery lint rule useAnchorHref, because its use case is covered by useValidAnchor.

Updated the `react` domain

The following rules are now a part of the react domain, and they won’t be enabled automatically unless you enabled the domain, or Biome detects react as a dependency of your closest package.json:

lint/correctness/noChildrenProp (recommended)
lint/correctness/noReactPropAssignments
lint/security/noDangerouslySetInnerHtml (recommended)
lint/security/noDangerouslySetInnerHtmlWithChildren (recommended)
lint/style/useComponentExportOnlyModules
lint/suspicious/noArrayIndexKey (recommended)

Improved `--skip` and `--only` flags

The flags --skip and --only have been enhanced, and they can accept lint domains too.

In the following example, the lint command runs only the rules that belong to the project domain:

biome lint --only=project

In the following example, the lint command runs all the rules that you configured, expect for the rules that belong to the test domain:

biome lint --skip=test

Enhanced `init` command

The init command now checks if the project contains ignore files and dist/ folders. If supported ignore files are found, Biome will enable the VCS integration, and if dist/ folder is found, it will exclude it using the new ignore syntax. This should help reducing the friction when starting with Biome:

{
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  }
}

New reporters

Two new CLI reporters have been added:

checkstyle reporter via the new option --reporter=checkstyle
RDJSON reporter via the new option --reporter=rdjson

New CLI flags

We added the new CLI flags to better control Biome without relying on the configuration file. Here’s the list:

--format-with-errors: CLI flag that allows to format code that contains parse errors.
--css-parse-css-modules: CLI flag to control whether CSS Modules syntax is enabled.
--css-parse-tailwind-directives: CLI flag to control whether Tailwind CSS 4.0 directives and functions are enabled.
--json-parse-allow-comments: CLI flag to control whether comments are allowed in JSON files.
--json-parse-allow-trailing-commas: CLI flag to control whether trailing commas are allowed in JSON files.

`lineEnding` format option

The option lineEnding now has a variant called auto to match the operating system’s expected line-ending style: on Windows, this will be CRLF (\r\n), and on macOS / Linux, this will be LF (\n).

This allows for cross-platform projects that use Biome not to have to force one option or the other, which aligns better with Git’s default behavior on these platforms.

biome.json

{
  "formatter": {
    "lineEnding": "auto"
  }
}

biome format --line-ending auto

And more!

More features and fixes have been shipped, like React v19 support, baseUrl support inside tsconfig.json, and more. Refer to the changelog page for a detailed breakdown of the features.

I like where this is going, how can I help?

I want to remind you that Biome is a project led by volunteers who like programming, open-source, and embrace the Biome philosophy, so any help is welcome 😁

Translations

Chat with us

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

Code contributions

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.
Help building Biome parsers! One interesting fact about Biome parsers is that they are recoverable parsers error resilient which emit a CST instead of a classic AST.
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.

Financial help

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 a company you can employ one of the core contributors to work a specific aspect of the Biome toolchain.

Biome v2.1

Tue, 08 Jul 2025 00:00:00 GMT

Biome 2.0 was released less than a month ago, and since then we have seen an amazing uptake! Our Discord is buzzing, our downloads are spiking, and bugs are rolling in :)

Faster scanner

Probably the main point of contention is that Biome 2.0 introduced a new scanner, which we use for discovering nested configuration files as well as for populating our module graph, if project rules are enabled. The reason for this contention is that having a scanner makes things slower, while people want Biome to be fast.

To mitigate the impact, we already made the project rules opt-in for 2.0, so that users can choose between features and speed for themselves. But ideally, we’d have both. And unfortunately, even without project rules, the scanner still caused some noticeable overhead.

For Biome 2.1 we’re changing the logic for how the “light scanner” (the one where project rules are disabled) works. Previously, it would always scan the entire project from its root, whereas now it will use the files and folders that you ask Biome to operate on as a hint for which parts of the project should be scanned.

This means if you run Biome without any arguments from the project root, you are not going to notice a difference. But if you specify specific files to check, or if you run Biome inside a nested folder, the scanner will know which parts of the project you are interested in, and only scan those.

Note that if you have enabled project rules, these improvements don’t apply. This is because project rules often need to pull information from other files, including ones you didn’t specify, so we still scan the entire project for now.

Improved type inference

When we released Biome 2.0, we mentioned that our type inference was able to detect ~75% of cases that our noFloatingPromises rule should ideally detect. Since then, we’ve been able to improve this to ~85%, and cases such as these can now be successfully inferred:

// We know that this evaluates to a `Promise`:
true && Promise.reject("logical operator bypass");

// But this doesn't:
false && Promise.reject("logical operator bypass");

// Similarly, we now detect that this may return a `Promise`:
const condition = Math.random() > -1; // Always true, but dynamic to linter
condition ? Promise.reject("ternary bypass") : null;

// On the other hand, we know the following is never a `Promise`:
const alwaysFalsy = 0;
alwaysFalsy ? Promise.reject("ternary bypass") : null;

// This will now get flagged because the `Promise`s are not handled:
[1, 2, 3].map(async (x) => x + 1);

Additionally, we have added support for getters, call signatures, comma operators, and more. Our goal is for you to not have to worry about which parts of TypeScript are supported, and the vast majority of cases to “just work”. It’s still a work in progress, but we’re happy with the progress we are seeing.

And finally we have also added the related rule noMisusedPromises.

Rule updates

The following new rules have been added in 2.1.0:

Other notable change:

The rule noUnusedFunctionParameters has been enhanced with an ignoreRestSiblings option.

Notable bug fixes

If you ignore a nested configuration file from your root configuration, it will now be properly ignored.
When extending a configuration from another, we now correctly ignore the root of the other configuration. This one led to some confusion in several use cases.

What’s next

It’s still early days in our 2.x journey. Both the scanner are type inference are likely to see further improvements. Additionally, our Core Contributors will focus on moving forward the Roadmap for 2025, and focus on the following features:

Make HTML support stable.
Expand HTML to support other frameworks such as Vue, Svelte, Astro and, hopefully, Angular too.
Work on Markdown support, starting from the parser.
and more!

Installation and migration

Install or update the @biomejs/biome package. If you upgrade the package, run the migrate command.

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome migrate --write

The migrate command takes care of breaking changes of the configuration, so you don’t have to.

I like where this is going, how can I help?

Biome is a project led by volunteers who like programming, open-source, and embrace the Biome philosophy, so any help is welcome 😁

Translations

Chat with us

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

Code contributions

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 an extensive technical guide.
Help building Biome parsers! One interesting fact about Biome parsers is that they are recoverable parsers error resilient which emit a CST instead of a classic AST.
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.

Financial help

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 as a company you can contract one of the core contributors to work on a specific aspect of the Biome toolchain.

Biome v2—codename: Biotype

Tue, 17 Jun 2025 00:00:00 GMT

We are happy to announce that Biome v2 is officially out! 🍾 Biome v2—codename: Biotype, the first JavaScript and TypeScript linter that provides type-aware linting rules that doesn’t rely on the TypeScript compiler! This means that you can lint your project without necessarily installing the typescript package.

With this release, the Core Contributors of the project want to show to the whole community and web ecosystem that Biome is here to stay and deserves to earn its place as the next-generation toolchain for the web. No other tools have achieved this great milestone in such a short amount of time (two years) and resources. This has been possible thanks to the companies and people who believed in the project, with a special shoutout to Vercel for sponsoring the type inference work.

Preliminary testing shows that our noFloatingPromises rule, which is based on our new type inference work, can detect floating promises in about 75% of the cases that would be detected by using typescript-eslint, at a fraction of the performance impact. And needless to say, we have plenty of ideas on how to improve this metric even further.

Keep in mind that your mileage may vary, as these early numbers are based on a limited set of use cases. Nevertheless, we look forward to people trying it out and reporting their experiences so that we can quickly reach a level of confidence that would be sufficient for most projects.

Installation and migration

Install or update the @biomejs/biome package. If you upgrade the package, run the migrate command.

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome migrate --write

The migrate command will take care of all the breaking changes of the configuration, so you don’t have to. However, there are some other changes that we couldn’t automate. We created a migration guide that explains them, together with manual migration paths, if applicable. Please get accustomed to the changes, as some of them fundamentally change some of the core functionalities of Biome (for the better!).

Relevant features

Biome is packed with new features, some big and some small. We will focus on the ones that we believe are worth mentioning. For a complete list of the new features, refer to the web version of the changelog.

Multi-file analysis and type inference

These two features are closely related. You can’t create a type inference engine without the ability to query types imported from other modules.

Before version 2.0, Biome lint rules could only operate on one file at a time. This brought us far, but many of the more interesting rules require information from other files too.

To accomplish this, we have added a file scanner to Biome that scans all the files in your project and indexes them, similar to what an LSP service might do in your IDE.

A file scanner comes with its baggage: slowness. We acknowledge that many users choose Biome for its speed. During the beta period, users raised some concerns about how this could affect their workflow.

As for this release, the file scanner has the following characteristics:

It’s opt-in; which means migrating from v1 to v2 won’t significantly affect the performance of formatting and linting your projects.
By default, the scanner is only used for discovering nested configuration files. This should be very fast, although a slight increase compared to v1 may be experienced.
A full scan (which scans all your project files and node_modules) is performed only when project rules are enabled.
Users can control the scanned files using files.includes, with the exception of node_modules.
Lint rules that need to collect types or query the module graph will never be recommended outside the project domain. We put speed and performance first, and users have control over the rules.

Monorepo Support

We’ve significantly improved our support for monorepos. This means that lint rules that rely on information from package.json files will now use the package.json from the right package. But perhaps more importantly: We now support nested configuration files.

Every project should still have a single biome.json or biome.jsonc at its root, similar to Biome v1. But projects are allowed to have any number of nested biome.json/biome.jsonc files in subdirectories. Nested configuration files must be explicitly marked as such, in one of two ways.

The first looks like this:

biome.jsonc

{
    "root": false,
    // ...
}

By setting the root field to false, you tell Biome this is a nested file. This is important, because if you run Biome inside the nested folder, it will know that the configuration is part of a bigger project and continue looking for the root configuration as well.

It is important to stress that the settings within the nested folder do not inherit from the root settings by default. Rather, we still want you to use the extends field that already existed in Biome v1 if you want to extend from another configuration.

Which brings us to the second way a nested configuration can be defined:

biome.jsonc

{
    "extends": "//",
    // ...
}

This is a convenient micro-syntax that sets both the root field to false, and will tell Biome that this nested configuration extends from the root configuration.

Say goodbye to wonky relative paths such as "extends": ["../../biome.json"] 👋

We prepared a small guide that should help you set everything up.

Plugins

Biome 2.0 comes with our first iteration of Linter Plugins.

These plugins are still limited in scope: They only allow you to match code snippets and report diagnostics on them.

Here is an example of a plugin that reports on all usages of Object.assign():

`$fn($args)` where {
    $fn <: `Object.assign`,
    register_diagnostic(
        span = $fn,
        message = "Prefer object spread instead of `Object.assign()`"
    )
}

It’s a first step, but we have plenty of ideas for making them more powerful, and we’re eager to hear from our users about what they would like to see prioritised.

As for now, we intentionally left out the distribution method of plugin for different reasons. However, we would like to hear from you. Please join the discussion and share your ideas with us.

Import Organizer Revamp

In Biome 1.x, our Import Organizer had several limitations:

Groups of imports separated by a blank line were considered separate chunks, meaning they were sorted independently. This meant the following didn’t work as expected:
example.js
```
import { lib2 } from "library2";

import { util } from "./utils.js";
import { lib1 } from "library1";
```
It would correctly sort "library1" to be placed above "./utils.js", but it wouldn’t be able to carry it over the blank line to the top. This is what we got:
organizer_v1.js
```
import { lib2 } from "library2";

import { lib1 } from "library1";
import { util } from "./utils.js";
```
But instead, what we really wanted was this:
organizer_v2.js
```
import { lib1 } from "library1";
import { lib2 } from "library2";

import { util } from "./utils.js";
```
Imports from the same module were not merged. Consider the following example:
example.js
```
import { util1 } from "./utils.js";
import { util2 } from "./utils.js";
```
What we wanted was this:
organizer_v2.js
```
import { util1, util2 } from "./utils.js";
```
No custom ordering could be configured. Perhaps you didn’t really like the default approach of ordering by “distance” from the source that you’re importing from. Perhaps you wanted to organise the imports like this:
organizer_v2.js
```
import { open } from "node:fs";

import { internalLib1 } from "@company/library1";
import { internalLib2 } from "@company/library2";

import { lib1 } from "library1";
```

In Biome 2.0, all these limitations are lifted. In fact, if you look at the examples above, all snippets labeled organizer_v2.js can be produced just like that by our new import organizer.

Other improvements include support for organizing export statements, support for “detached” comments to explicitly separate import chunks if necessary, and import attribute sorting.

You can find more in the documentation of the action.

Assists

The Import Organizer has always been a bit of a special case in Biome. It was neither part of the linter, nor of the formatter. This was because we didn’t want it to show diagnostics like the linter does, and its organizing features exceeded what we expect from the formatter.

In Biome 2.0, we have generalised such use cases in the form of Biome Assist. Assist provides actions, which are similar to the fixes in lint rules, but without the diagnostics.

The Import Organizer has become an assist, but we’ve started using this approach for new assists too: useSortedKeys can sort keys in object literals, while useSortedAttributes can sort attributes in JSX.

For more information about assists, see the relative page.

Improved suppressions

In addition to the // biome-ignore comments we already supported, we now support // biome-ignore-all for suppressing a lint rule or the formatter in an entire file.

We also added support for suppression ranges using // biome-ignore-start and // biome-ignore-end. Note that // biome-ignore-end is optional in case you want to let a range run until the end of the file.

For more information about suppressions, see the relative page.

HTML formatter

After several months of hard work, we are pleased to announce that the HTML formatter is now ready for users to try out and report bugs! This is a huge step towards Biome fully supporting HTML-ish templating languages used in frameworks such as Vue and Svelte.

For now, the HTML formatter only touches actual .html files, so it doesn’t format HTML in .vue or .svelte files yet. It also won’t format embedded languages like JavaScript or CSS yet. HTML’s options like attributePosition, bracketSameLine, and whitespaceSensitivity have been implemented.

The HTML formatter is still in the experimental stage, so it will remain disabled by default for the full 2.0 release. At the time of writing, Biome can parse most of the Prettier’s HTML test suite, and format 46/124 of them correctly. Despite not matching Prettier yet, we’re pretty confident that it should output adequately formatted documents without destroying anything. If you find a case where it doesn’t, please let us know!

You can enable the HTML formatter by adding the following to your config file:

{
  "html": {
    "formatter": {
      "enabled": true
    }
  }
}

Shout-outs

And now, let’s give credits where credits are due!

Special thanks to Vercel, our platinum sponsor, for sponsoring the type inference work, led by Core Contributor @arendjr .

Special thanks to Depot, our gold sponsor, for providing the project with powerful and fast CI runners. A huge time saver and reliability booster!

Congratulations to Core Contributor @siketyan , who recently became a Core Contributor of the project! Thanks to their contributions, the JetBrains extension is now stable and supports multiple workspaces.

Thanks to Core Contributor @conaclos for their massive work in implementing many features such as the Import Organizer revamping, the new glob engine, many new linting rules.

Thanks to Core Contributor @arendjr for creating the multi-file architecture, the continuous work on the type inference, plugins, and miscellaneous improvements.

Props to Core Contributor @nhedger for authoring the GitHub Action, and shipping the new version of the VS Code extension.

Thanks to Core Contributor @dyc3 for leading the work on the HTML parser and formatter. They are both very complex pieces of software, especially when it comes to matching Prettier’s formatting experience.

Last but not least, a great thanks to all our other sponsors and contributors as well!

What’s next

No software is exempt from bugs, so we will ensure that we squash them and release patches.

The Core Contributors will focus on moving forward the Roadmap for 2025, and focus on the following features:

Make HTML support stable.
Expand HTML to support other frameworks such as Vue, Svelte, and Astro.
Work on Markdown support, starting from the parser.
Continue working on the inference infrastructure, so we can cover more cases and add new rules.
and more!

I like where this is going, how can I help?

I want to remind you that Biome is a project led by volunteers who like programming, open-source, and embrace the Biome philosophy, so any help is welcome 😁

Translations

Chat with us

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

Code contributions

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.
Help building Biome parsers! One interesting fact about Biome parsers is that they are recoverable parsers error resilient which emit a CST instead of a classic AST.
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.

Financial help

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 a company you can employ one of the core contributors to work a specific aspect of the Biome toolchain.

VS Code extension V3

Tue, 29 Apr 2025 00:00:00 GMT

We’re excited to announce that version 3 of the Biome VS Code extension is now available! This release includes a range of new features and improvements to make your development experience even better:

🗄️ Support for multi-root workspaces
📝 Support for single-file mode
👻 Support for unsaved files
🔄 Automatic reload after updating Biome
⚙️ Automatic reload after configuration changes
✨ Improved status indicator

Multi-root workspaces

The Biome extension now supports multi-root workspaces, so you can work on multiple projects side by side in a single VS Code window. Each workspace folder now runs its own independent Biome instance, keeping your projects isolated.

:::caution[heads up for pre-release users] If you’ve been using the pre-release version over the past few months, please note that support for the biome.projects setting has been removed in the final release. We now recommend using multiple workspace folders instead to manage multiple projects. :::

Single-file mode

Sometimes you just need to make a quick edit to that one file. The extension now fully supports single-file mode, making it easy to work with files that aren’t part of a full project.

code that-one-file.js

To use this feature, make sure you have Biome installed globally. No worries if you forget, the extension will let you know if it can’t find Biome in your PATH.

Unsaved files & VS Code settings

The extension now supports formatting and linting unsaved (Untitled) files, as well as your VS Code settings. When you open one of these, the extension will spin up a global Biome instance on demand.

As with single-file mode, this feature requires Biome to be installed globally. The extension will notify you if it’s missing from your PATH.

Automatic reload

When the extension detects that Biome has been updated in your project dependencies, it will automatically reload the relevant Biome instances to use the latest version.

Additionally, any changes to the extension’s configuration will trigger a reload of the Biome instance to ensure your new settings take effect immediately.

Improved status indicator

The status bar now more reliably reflects the status of Biome for your active workspace folder. When you switch between workspace folders, the indicator updates accordingly.

Plus, clicking the status indicator opens the logs for the current Biome instance, making it easier to access logs when troubleshooting.

Retiring the downloader

From the start, the downloader was meant to bridge the gap until you installed Biome as a project dependency.

Managing the lifecycle of downloaded binaries—including updates and cross-platform support is complex. We believe package managers handle this better than we could.

Going forward, if the extension needs a global Biome installation but can’t find it, you’ll see a notification with instructions on how to install Biome globally. And don’t worry, you can easily silence this notification if you prefer not to be reminded.

Biome partners with Vercel to improve type inference

Wed, 02 Apr 2025 00:00:00 GMT

Back at the start of 2024, Biome added an ambitious goal to its roadmap: integrate a subset of the TypeScript type system directly into Biome so that type-informed lint rules can work out of the box.

In order to make this feasible, we first needed better infrastructure. The main blocker for this was multi-file analysis, which is coming with Biome 2.0.

Today, we finally have the technical means to implement this goal, but, as a project, we need more than only technical means. Which is why we are grateful to announce Vercel as a partner to help us achieve this goal and push the web forward.

Vercel has contracted me (one of the Biome lead developers) to work on our type inference effort for many months. Vercel’s goal with this partnership is to both help improve their own internal linter DX (as they have recently standardized on Biome) and share those improvements with the rest of the JavaScript ecosystem.

We aim to have a fully functioning(*) versions of the noFloatingPromises rule and a similar noMisusedPromises rule.

Frequently Asked Questions

Because type inference and type checkers are popular topics in our community, I have collected a few common questions on this topic.

Are you reimplementing a type checker in Biome?

No. TypeScript’s tsc is a complex and fully-featured type checker, and we have no intention to rebuild it. For type checking you are expected to continue to use tsc.

This work focuses on type inference which is a small subset of the functionality of a full type checker. The goal is to be able to write lint rules that act on type information, without needing to prove that this type information is correct.

How can you write a type-informed lint rule if you don’t know the type information is correct?

Linters have different aims than type checkers. Where a type checker aims to detect misuse of types, a linter aims to detect common mistakes in general. But the goal of detecting common mistakes doesn’t require 100% correctness when it comes to the types it operates on. In fact, even the TypeScript Design Goals state they are willing to compromise correctness in favor of productivity.

For a linter, what’s most important is that we don’t flag false positives, instances where our lint rules may think there’s an issue when really there’s not. False positives are a source of frustration for developers, because they take time to analyze; time that was wasted when it turns out there really wasn’t an issue to begin with.

On the other hand, false negatives are less problematic. They represent situations where we wish the lint rule would flag an issue, but didn’t. They can also represent lost productivity (by not flagging the issue early in the pipeline), but they are not productivity lost due to the rule itself.

Hypothetically, a lint rule that has no false positives, but has 20% false negatives, still offers 80% of the value of a rule that is always correct. So our goal is simply: Create lint rules that don’t flag false positives, while trying to get the amount of false negatives down as much as we can.

We cannot say upfront which percentage we will actually achieve, but since Vercel is sponsoring this work, we’ll use their repositories as a benchmark and try to optimise towards their use cases.

How does Microsoft’s announcement of a Go port for `tsc` influence your work?

It’s too early to tell. The Go port is not available to users yet, and the APIs that should allow it to be used by other tooling aren’t expected until the end of the year. Additionally, even though the Go port is supposedly much faster than the Node.js version, it will likely still be significantly slower than an implementation built into Biome’s core due to inter-process communication and the need to do duplicate work such as parsing files in separate processes.

For now, that gives us an opportunity to pursue our own type inference implementation and see how it goes. When the Go version is available for integration into other tools, we can always reevaluate our approach.

Can we follow your progress?

Yes! There’s a public project overview that people can inspect: https://github.com/orgs/biomejs/projects/4/views/2

Note that issues may be continuously added to the project as false negatives keep popping up.

Biome v2.0 beta

Mon, 24 Mar 2025 00:00:00 GMT

After hard work from our team, Biome’s long-awaited 2.0 release is nearing completion. It will be packed with many large features, so we would like your help testing it with a public beta!

If you would like to try it out, you can update Biome and migrate your configuration using the following commands:

npm install --save-dev --save-exact @biomejs/biome@beta
npx @biomejs/biome@beta migrate --write

Also, make sure you use the prereleases of our IDE extensions. The stable versions of our extensions are not yet prepared for Biome 2.0!

Documentation for the upcoming release can be found at https://next.biomejs.dev/.

New features

While the final 2.0 release may still have small changes in its final feature set, here’s what you can expect in the beta:

Plugins: You can write custom lint rules using GritQL.
Domains: Domains help to group lint rules by technology, framework, or well, domain. Thanks to domains, your default set of recommended lint rules will only include those that are relevant to your project.
Multi-file analysis: Lint rules can now apply analysis based on information from other files, enabling rules such as noImportCycles.
noFloatingPromises: Still a proof-of-concept, but our first type-aware lint rule is making an appearance.
Our Import Organizer has seen a major revamp.
Assists: Biome Assist can provide actions without diagnostics, such as sorting object keys.
Improved suppressions: Suppress a rule in an entire file using // biome-ignore-all, or suppress a range using // biome-ignore-start and // biome-ignore-end.
HTML formatter: Still in preview, this is the first time we ship an HTML formatter.
Many, many, fixes, new lint rules, and other improvements.

Plugins

Biome 2.0 comes with our first iteration of Linter Plugins.

These plugins are still limited in scope: They allow for matching code snippets and reporting diagnostics on them.

Here is an example of a plugin that reports on all usages of Object.assign():

`$fn($args)` where {
    $fn <: `Object.assign`,
    register_diagnostic(
        span = $fn,
        message = "Prefer object spread instead of `Object.assign()`"
    )
}

It’s a first step, but we have plenty of ideas for making them more powerful, and we’ll eagerly hear from our users on what they would like to see prioritised.

Domains

We’ve introduced a new linter feature: Domains.

Domains are a new way to organise lint rules by technology, framework, or well, domain. Right now, we have identified four domains:

next: Rules related to Next.js.
react: Rules related to React.
solid: Rules related to Solid.js.
test: Rules related to testing, regardless of framework or library.

You can enable and disable rules that belong to a domain together:

biome.jsonc

{
  "linter": {
    "domains": {
      "test": "all", // all rules that belong to this domain are enabled
      "react": "recommended", // only the recommended rules from this domain are enabled
      "solid": "none" // rules related to Solid are disabled
    }
  }
}

But it gets better: Biome will automatically inspect your package.json and determine which domains should be enabled by default. For instance, if you have react defined as one of your dependencies, the default setting for the react domain automatically becomes recommended.

This way, Biome’s total set of recommended rules should be most relevant to your specific project needs.

And finally, domains can add global variables to the javascript.globals setting. This should make Biome even easier to setup.

Multi-file analysis

Before version 2.0, Biome lint rules could only operate on one file at a time. This brought us far, but many of the more interesting rules require information from other files too.

To accomplish this, we have added a file scanner to Biome that scans all the files in your project and indexes them, similar to what an LSP service might do in your IDE. We’re not going to beat around the bush: Scanning projects means that Biome has become slower for many projects. But we do believe the ability to do multi-file analysis is worth it. And without a scanner, multi-file analysis would become even slower, as rules would need to perform ad-hoc file system access individually.

That said, this is a beta, and there are certainly more opportunities to improve our scanner and its performance. If you have a repository where you feel our performance became unacceptably slow, please reach out and file an issue.

For now, we have a few interesting rules that can make use of our multi-file analysis:

noImportCycles is able to look at import statements and detect cycles between them.
noPrivateImports is a new rule based on the useImportRestrictions nursery rule from Biome 1.x, and inspired by ESLint’s plugin-import-access. It forbids importing symbols with an @private JSDoc tag from other modules, and forbids importing symbols with an @package tag if the importing file is not in the same folder or one of its subfolders.
useImportExtensions has been improved because it can now determine the actual extension that needs to be used for an import, instead of guessing based on heuristics.

Finally, we’ve also designed the multi-file analysis with monorepos in mind. While full monorepo support may not make it in time for the 2.0 release, we expect to be able to deliver more on this front soon.

`noFloatingPromises`

With Biome’s linter we have always strived to provide a battery-included approach to linting. This means we’re not just aiming to replace ESLint, but also its plugins. One of the hardest plugins to replace is typescript-eslint.

Biome has featured some rules from typescript-eslint for a while now, but we could never replace all rules, because they relied on type information for their analysis. And in order to get type information, typescript-eslint relies on tsc itself, which is rather slow and also complicates setup.

This is about to change. With Biome 2.0, we’re introducing a first version of the noFloatingPromises rule, one of the most-requested rules that relies on type information. In fairness, we should not consider it more than a proof-of-concept right now, because there are some notable limitations to its capabilities:

It doesn’t understand complex types yet.
It cannot do type inference yet.
It can currently only analyse types that occur in the same file.

Still, its capabilities are sufficient to catch some of the low-hanging fruit. Consider this small snippet:

example.js

async function returnsPromise() { /* ... */ }

returnsPromise().then(() => {});

It will trigger the following diagnostic:

example.js:3:1 lint/nursery/noFloatingPromises ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ A “floating” Promise was found, meaning it is not properly handled and could lead to ignored errors or unexpected behavior.

    1 │ async function returnsPromise() { /* ... */ }
    2 │
  > 3 │ returnsPromise().then(() => {});
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    5 │

  ℹ This happens when a Promise is not awaited, lacks a .catch or .then rejection handler, or is not explicitly ignored using the void operator.

As you can guess, we intend to expand this rule’s capabilities over time. And with our new multi-file analysis in place, we expect to be able to make serious strides with this. Stay tuned for more announcements on this front!

Import Organizer Revamp

In Biome 1.x, our Import Organizer had several limitations:

Groups of imports or exports would be considered separate chunks, meaning they would be sorted independently. This meant the following didn’t work as expected:
example.js
```
import { lib2 } from "library2";

import { util } from "./utils.js";
import { lib1 } from "library1";
```
It would correctly sort "library1" to be placed above "./utils.js", but it wouldn’t be able to carry it over the newline to the top. What we got was this:
organizer_v1.js
```
import { lib2 } from "library2";

import { lib1 } from "library1";
import { util } from "./utils.js";
```
But instead, what we really wanted was this:
organizer_v2.js
```
import { lib1 } from "library1";
import { lib2 } from "library2";

import { util } from "./utils.js";
```
Separate imports from the same module wouldn’t be merged. Consider the following example:
example.js
```
import { util1 } from "./utils.js";
import { util2 } from "./utils.js";
```
Nothing would be done to merge these import statements, whereas what we would have wanted was this:
organizer_v2.js
```
import { util1, util2 } from "./utils.js";
```
No custom ordering could be configured. Maybe you didn’t really like the default approach of ordering by “distance” from the source file that you’re importing from. Maybe you wanted to organise like this:
organizer_v2.js
```
import { open } from "node:fs";

import { internalLib1 } from "@company/library1";
import { internalLib2 } from "@company/library2";

import { lib1 } from "library1";
```

In Biome 2.0, all these limitations are lifted. In fact, if you look at the examples above, all snippets labeled organizer_v2.js can be produced just like that by our new import organizer.

Other improvements include support for organizing export statements, support for “detached” comments for explicitly separating import chunks if necessary, and import attribute sorting.

You can find the documentation on the new import organizer at https://next.biomejs.dev/assist/actions/organize-imports/.

Assists

The Import Organizer was always a bit of a special case in Biome. It was neither part of the linter, nor of the formatter. This was because we didn’t want it to show diagnostics the way the linter does, while its organizing features went beyond what we expect from the formatter.

In Biome 2.0, we have generalised such use cases in the form of Biome Assist. The assist is meant to provide actions, which are similar to the fixes in lint rules, but without the diagnostics.

For more information about assists, see: https://next.biomejs.dev/assist/

Improved suppressions

In addition to the // biome-ignore comments we already supported, we now support // biome-ignore-all for suppressing a lint rule or the formatter in an entire file.

For more information about suppressions, see: https://next.biomejs.dev/linter/#suppress-lint-rules

HTML formatter

After a few months of hard work, we are happy to announce that the HTML formatter is now ready for users to try out and start reporting bugs! This is a huge step towards Biome fully supporting HTML-ish templating languages used in frameworks like Vue and Svelte.

The HTML formatter only touches actual .html files for now, so no formatting of html in .vue or .svelte files yet. It also won’t format embedded languages like JavaScript or CSS yet. HTML’s options like attributePosition, bracketSameLine, and whitespaceSensitivity have been implemented.

The HTML formatter is still pretty experimental, so it will remain disabled by default for the full 2.0 release. At the time of writing, Biome is able to parse the grand majority of Prettier’s HTML tests, and format 46/124 of them correctly. Despite not matching Prettier yet, we’re pretty confident that it should output documents that are formatted adequately without destroying anything. If you find a case where it doesn’t, please let us know!

You can enable the HTML formatter by adding the following to your config file:

{
  "html": {
    "formatter": {
      "enabled": true
    }
  }
}

New rules

Several new rules have added since v1.9:

Miscellaneous

BREAKING: The configuration fields include and ignore have been replaced with a single includes field.
BREAKING: Reworked some recommended rules recommended to be less pedantic and blocking. This is a breaking change if your project relied on those rules to block the CI in case of violations. If you used the migrate command, the behaviour should remain as before.
BREAKING: The style rules aren’t recommended anymore. If you used the migrate command, the behaviour should remain as before.
BREAKING: Removed deprecated rules:
- noConsoleLog
- noInvalidNewBuiltin
- noNewSymbol
- useShorthandArrayType
- useSingleCaseStatement
BREAKING: Many deprecated options, including some that still referenced the old Rome name, have been removed.
Added a new option javascript.parser.jsxEverywhere to control whether Biome should expect JSX syntax in .js/.mjs/.cjs files.
Improved monorepo support: The rule noUndeclaredDependencies now works correctly in monorepos by using the nearest package.json file, instead of only the root one.
We have enabled support for .editorconfig files by default.
Changed default formatting of package.json to align better with formatting by package managers.

And more!

For the full list of changes, please refer to our changelog.

Roadmap 2025 and Biome 2.0

Wed, 22 Jan 2025 00:00:00 GMT

Today we’re happy to share our plans for Biome 2.0 as well as the rest of our roadmap for 2025. But before we dive into what’s coming, let’s do a quick recap of the major developments in 2024.

🎆 Recap: Biome in 2024

2024 was a great year for Biome. Let’s see what happened:

We released 4 new “minor” Biome versions, from 1.6 through 1.9, with plenty of useful features:
- New biome search and biome explain commands, while the biome migrate command was significantly expanded to help users coming from ESLint and Prettier.
- Added support for CSS and GraphQL formatting and linting.
- Partial support for Astro, Svelte and Vue files.
- The ability to let configuration files extend from one another, which is especially useful in monorepo and larger organizational setups.
- Custom reporters for better CI integration and machine-readable output.
- Support for .editorconfig.
- We added countless new lint rules and miscellaneous fixes and improvements, with a special shoutout to useSortedClasses that marks the beginning of dedicated Tailwind support.
Our team of maintainers has grown from 10 members at the start of 2024 to 18 today.
We won the Productivity Booster award of the OS Awards 2024.
We gained several new sponsors.
We improved our IDE support on multiple fronts:
- A new Zed extension has been contributed to the project.
- Our VS Code extension has seen an overhaul that’s currently in Pre-Release.
- And even though this happened after the new year, we shouldn’t neglect to mention that our IDEA plugin has seen a major update too, which is now available in the nightly channel.

💳 Enterprise Support

One more thing that we are happy to announce is that as of January 2025, we are also offering Enterprise Support for Biome. Hopefully this will allow some of our contributors to spend more of their time and effort towards Biome!

⏭️ Biome 2.0

Right now our team is busy preparing for the Biome 2.0 release. Because our project is still run by volunteer contributors, we do not have an ETA for you. But we can share some of the goodies that will be coming:

Plugins. A long-requested feature, we started the development of Biome plugins after an RFC process that started in January 2024. Biome 2.0 will feature the first fruits of this labor: Users will be able to create their own lint rules using GritQL.
Domains. Domains are a configuration feature that makes it easy for users to enable or disable all rules related to a specific domain, such as React, Next.js or testing frameworks. It also allows Biome to automatically enable recommended domain-specific rules based on the dependencies listed in your package.json.
Monorepo Support. While support for monorepos was already improved with our extends feature in biome.json, many weak spots remained. Biome 2.0 has an improved architecture based on an internal ProjectLayout that should resolve most of these.
Suppressions. Biome already allowed suppression of linter diagnostics through the use of // biome-ignore suppression comments. With Biome 2.0 we’re adding support for // biome-ignore-all and // biome-ignore-start/biome-ignore-end comments.
Multi-file analysis. Last but not least, we’re adding true Multi-file support to Biome 2.0. This means that our lint rules will be able to query information from other files, which will enable much more powerful lint rules.

🌌 2025 roadmap

Again, we should preface a disclaimer here: We’re a community-driven project, so we cannot promise to deliver any of the features below. But that doesn’t mean we don’t have a wishlist of things we would like to work on in 2025 😉

This year we will focus on:

HTML support. No toolchain for the web is complete without it, and we’re already working on it!
Embedded languages. CSS or GraphQL snippets inside a template literal in a JavaScript file? JavaScript or CSS inside an HTML file? Biome should be able to handle these as well, and we’ll try to make it happen. This should also lead to better support for Astro, Svelte, and Vue than we have today.
Type inference. This was already a wish for 2024, and we’re busy filling in the prerequisites such as multi-file analysis. There’s even an early proof-of-concept for a noFloatingPromises rule. This year we want to ship a real version of noFloatingPromises, and hopefully dabble further into type inference.
.d.ts generation. While we’re on the subject of types, we would also like to create our first transformation: generating .d.ts files from TypeScript sources. Initially we would only focus on TypeScript using Isolated Modules.
JSDoc support. Can we use JSDoc comments as a source of type information too? If we are able to do type inference, this seems an opportunity we cannot pass on.
Markdown support. Some work has already started for it and it would be a nice addition to round out our language support.
More plugins. While Biome 2.0 will launch with the ability to create lint rules in GritQL, that’s only the tip of the iceberg. We know our users want more, and we certainly have ideas for more types of plugins. We’ll first collect feedback from the 2.0 release, and then we’ll decide which plugin area we’ll focus on next.

❤️ Your Support

We would like to thank our users and sponsors alike for their amazing support in 2024! Without you, this project would not be what it is today.

Hopefully we can also count on your support for the coming year. If you would like to help out, you can:

Become a contributor. Please help us to build those features!
Sponsor us. Ask your company to sponsor us: Biome is so fast that it can reduce your company’s CI times, improve developer productivity, and save money. Sponsorships also create exposure for your company.
Hire us. Is Biome missing anything that prevents your company from adopting it? You can make it happen by hiring us! Any company that hires a contributor to work on Biome for 3 months or more automatically applies for sponsorship benefits.
Improve our documentation. Write guides or recipes, or help to keep our translations up-to-date for non-English speakers.

Biome v1.9 Anniversary Release

Thu, 12 Sep 2024 00:00:00 GMT

Today we’re excited to announce the release of Biome v1.9 and to celebrate the first anniversary of Biome 🎊 Let’s take a look back at the first year of Biome and then explore the new features in Biome 1.9.

One year of Biome

We officially announced Biome on 29 August 2023. From its inception, Biome has been a free open source software driven by its community. We have a governance and a solid base of contributors to ensure the longevity of the project.

In October 2023, one of the creators of Prettier launched the Prettier challenge that rewarded any project written in Rust that passes at least 95% of the Prettier tests for JavaScript. The aim of this challenge was to create a fast competitor to Prettier in order to stimulate improvements in Prettier’s performance. We quickly organized ourselves to get there as soon as possible. By the end of November, we surpassed this goal by passing 97% of the Prettier tests for JavaScript, as well as TypeScript, JSX and TSX! The Biome formatter is really fast: it can format a large code base in less than 1 second. In the process, we identified several formatting issues in Prettier. This has also pushed contributions to Prettier that greatly improved its performance. This challenge was a win for the whole web ecosystem!

By winning the challenge, we brought Biome to light. Many developers were excited to discover a fast alternative to Prettier, but also a fast alternative to ESLint! The approach of bundling both a formatter and a linter in one tool provides a unified and consistent experience with minimal configuration. Biome has been quickly adopted by many projects, including big ones such as Ant Design, Astro, Sentry, daisyUI, Refine, Discord, Pulumi, Label Studio, Spicetify, Apify, Slint, Rspack, FluidFramework, and others. Biome surpassed 2.7 million monthly NPM downloads in August 2024.

We gained sponsorship, notably Shiguredo, l2BEAT, Phoenix Labs, KANAME, Nanabit, Vital, CodeRabbit, and Forge42. These sponsorships have helped move the project forward by rewarding contributors and even paying for maintenance work in recent months. We would like to reward and encourage more contributions, then if you use Biome, please consider sponsoring us!

We also gained many new contributors. Contributors who have made a significant contribution are regularly invited to join the Biome team. We started with a team of 5 core contributors, and we are now a team of 8 core contributors and 10 maintainers.

In June 2024, Biome won the JSNation’s productivity booster Open Source Award.

Biome v1.9

As we celebrate Biome’s first year, we’re pleased to announce the release of Biome 1.9, which brings many new features and bug fixes.

Once you have upgraded to Biome v1.9.0, migrate your Biome configuration to the new version by running the migrate command:

biome migrate --write

Stable CSS formatter and linter

We are thrilled to announce that Biome’s CSS formatter and linter are now considered stable and are enabled by default. Do note that Biome only parses standard CSS syntax so far, and doesn’t yet handle CSS dialects such as SCSS. As this is brand new functionality, you may also still run into some rough edges. Please report any problems you encounter!

The CSS linter provides 15 stable lint rules that were ported from stylelint:

It also provides the following nursery lint rules:

If you don’t want Biome to format and lint your CSS files, you can disable the CSS formatter and linter in the Biome configuration file:

{
  "css": {
    "formatter": {
      "enabled": false
    },
    "linter": {
      "enabled": false
    }
  }
}

or on the command line:

biome format --css-formatter-enabled=false
biome lint --css-linter-enabled=false
biome check --css-formatter-enabled=false --css-linter-enabled=false

Special thanks to Denis Bezrukov @denbezrukov, Jon Egeland @faultyserver and Yoshiaki Togami @togami2864 for coordinating and implementing most of the features related to CSS.

Stable GraphQL formatter and linter

Another brand new feature: Biome now formats and lints GraphQL files by default.

For now, Biome provides only two nursery lint rules:

If you don’t want Biome to format and lint your GraphQL files, you can disable the GraphQL formatter and linter in the Biome configuration file:

{
  "graphql": {
    "formatter": {
      "enabled": false
    },
    "linter": {
      "enabled": false
    }
  }
}

or on the command line:

biome format --graphql-formatter-enabled=false
biome lint --graphql-linter-enabled=false
biome check --graphql-formatter-enabled=false --css-linter-enabled=false

Special thanks to Swan that funded the implementation of the GraphQL formatter and to Võ Hoàng Long @vohoanglong0107 for implementing most of the features related to GraphQL.

Search command

Back in February, one of our Core Contributors published a proposal for plugin support. One of the highlights was the use of GritQL as a foundation for our plugin system.

GritQL is a powerful query language that lets you do structural searches on your codebase. This means that trivia such as whitespace or even the type of string quotes used will be ignored in your search query. It also has many features for querying the structure of your code, making it much more elegant for searching code than regular expressions.

Integrating a query language such as GritQL is no easy feat, and throughout the year we published multiple status updates. Today, we release the first product of this effort: A new biome search command.

While we believe this command may already be useful to users in some situations (especially when it gets integrated in our IDE extensions!), this command is really a stepping stone towards our plugin efforts. By allowing our users to try it out in a first iteration, we hope to gain insight into the type of queries you want to do, as well as the bugs we need to focus on.

For now, the search command is explicitly marked as EXPERIMENTAL, since many limitations are yet to be fixed or explored. Keep this in mind when you try it out, and please let us know what you think! For an overview of specific limitations, please see the dedicated issue.

Even though there are still plenty of limitations, we do believe the integration has progressed far enough that we can shift our focus towards the integration of actual plugins. We cannot yet promise a timeline, but we’ll keep you posted!

PS.: GritQL escapes code snippets using backticks, but most shells interpret backticks as command invocations. To avoid this, it’s best to put single quotes around your Grit queries. For instance, the following command search for all console.log invocations:

biome search '`console.$method($args)` where { $method <: or { `log`, `info` } }' ./

./benchmark/bench.js:38:3 search ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  38 │ 	console.info(`\n⌛ repository: ${name}`);

./packages/@biomejs/js-api/scripts/update-nightly-version.mjs:27:1 search ━━━━━━━━━━━━━━

  27 │  console.log(`version=${version}`);

Searched 67 files in 1034ms. Found 2 matches.

Special thanks to Grit for open-sourcing GritQL, Arend van Beelen @arendjr for integrating the GritQL engine into Biome, and to @BackupMiles for implementing the formatting of search results in the biome search command!

`.editorconfig` support

Biome is now able to take the .editorconfig of your project into account. This is an opt-in feature. You have to turn it on in your Biome configuration file:

biome.json

{
  "formatter": {
    "useEditorconfig": true
  }
}

Note that all options specified in the Biome configuration file override the ones specified in .editorconfig. For now, only the .editorconfig at the root of your project is taken into account.

Special thanks to Carson McManus @dyc3 for implementing this feature!

JavaScript formatter and linter

We updated the JavaScript formatter to match Prettier v3.3. The most significant change is adding parentheses around nullish coalescing in ternaries. This change adds clarity to operator precedence.

// Input
foo ? bar ?? foo : baz;

// Biome 1.8.3 and Prettier 3.3.2
foo ? bar ?? foo : baz;

// Biome 1.9 and Prettier 3.3.3
foo ? (bar ?? foo) : baz;

Regarding the linter, we stabilized the following lint rules:

We added the following new rules:

And we deprecated the following rules:

correctness/noInvalidNewBuiltin. Use correctness/noInvalidBuiltinInstantiation instead.
style/useSingleCaseStatement. Use correctness/noSwitchDeclarations instead.
suspicious/noConsoleLog. Use suspicious/noConsole instead.

Our linter has now more than 250 rules! Most of the ESLint rules and rules from some plugins have been ported. We are close to completing the port of ESLint.

And more!

For the full list of changes, please refer to our changelog.

What’s next

VSCode plugin v3

Nicolas Hedger @nhedger is working on a new version of our first-party VSCode plugin. This new version will improve workspace support and fix some long-standing issues.

Biome 2.0

During this first year, we have discovered a number of issues that cannot be solved without introducing small breaking changes. For example, we rely on a glob library that sometimes doesn’t behave as users expect. We feel it is time to address these long-standing issues. Following our versioning philosophy, these small breaking changes cannot be made without releasing a major release. Therefore, the next release of Biome will be a major release: Biome 2.0. We will use this opportunity to remove deprecated features. We will make the migration smooth by using the biome migrate command.

Biome v1.7

Mon, 15 Apr 2024 00:00:00 GMT

Today we’re excited to announce the release of Biome v1.7!

This new version provides an easy path to migrate from ESLint and Prettier. It also introduces experimental machine-readable reports for the formatter and the linter, new linter rules, and many fixes.

Update Biome using the following commands:

npm install --save-dev --save-exact @biomejs/biome@latest
npx @biomejs/biome migrate

Migrate from ESLint with a single command

This release introduces a new subcommand biome migrate eslint. This command will read your ESLint configuration and attempt to port their settings to Biome.

The subcommand is able to handle both the legacy and the flat configuration files. It supports the extends field of the legacy configuration and loads both shared and plugin configurations! The subcommand also migrates .eslintignore.

Given the following ESLint configuration:

.eslintrc.json

{
  "extends": [
    "plugin:unicorn/recommended"
  ],
  "plugins": [
    "unicorn"
  ],
  "ignore_patterns": [
    "dist/**"
  ],
  "globals": {
    "Global1": "readonly"
  },
  "rules": {
    "eqeqeq": "error"
  },
  "overrides": [
    {
      "files": [
        "tests/**"
      ],
      "rules": {
        "eqeqeq": "off"
      }
    }
  ]
}

And the following Biome configuration:

biome.json

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

Run biome migrate eslint --write to migrate your ESLint configuration to Biome. The command overwrites your initial Biome configuration. For example, it disables recommended. This results in the following Biome configuration:

biome.json

{
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": false,
      "complexity": {
        "noForEach": "error",
        "noStaticOnlyClass": "error",
        "noUselessSwitchCase": "error",
        "useFlatMap": "error"
      },
      "style": {
        "noNegationElse": "off",
        "useForOf": "error",
        "useNodejsImportProtocol": "error",
        "useNumberNamespace": "error"
      },
      "suspicious": {
        "noDoubleEquals": "error",
        "noThenProperty": "error",
        "useIsArray": "error"
      }
    }
  },
  "javascript": {
    "globals": [
      "Global1"
    ]
  },
  "overrides": [
    {
      "include": [
        "tests/**"
      ],
      "linter": {
        "rules": {
          "suspicious": {
            "noDoubleEquals": "off"
          }
        }
      }
    }
  ]
}

The subcommand needs Node.js to load and resolve all the plugins and extends configured in the ESLint configuration file. For now, biome migrate eslint doesn’t support configuration written in YAML.

We have a dedicated page that lists the equivalent Biome rule of a given ESLint rule. We handle some ESLint plugins such as TypeScript ESLint, ESLint JSX A11y, ESLint React, and ESLint Unicorn. Some rules are equivalent to their ESLint counterparts, while others are inspired. By default, Biome doesn’t migrate inspired rules. You can use the CLI flag --include-inspired to migrate them.

Migrate from Prettier with a single command

Biome v1.6 introduced the subcommand biome migrate prettier.

In Biome v1.7, we add support of Prettier’s overrides and attempts to convert .prettierignore glob patterns to globs supported by Biome.

During the migration, Prettier’s overrides is translated to Biome’s overrides. Given the following .prettierrc.json

.prettierrc.json

{
  "useTabs": false,
  "singleQuote": true,
  "overrides": [
    {
      "files": [
        "*.json"
      ],
      "options": {
        "tabWidth": 2
      }
    }
  ]
}

Run biome migrate prettier --write to migrate your Prettier configuration to Biome. This results in the following Biome configuration:

biome.json

{
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineEnding": "lf",
    "lineWidth": 80,
    "attributePosition": "auto"
  },
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "jsxQuoteStyle": "double",
      "quoteProperties": "asNeeded",
      "trailingComma": "all",
      "semicolons": "asNeeded",
      "arrowParentheses": "always",
      "bracketSpacing": true,
      "bracketSameLine": false,
      "quoteStyle": "single",
      "attributePosition": "auto"
    }
  },
  "overrides": [
    {
      "include": [
        "*.json"
      ],
      "formatter": {
        "indentWidth": 2
      }
    }
  ]
}

The subcommand needs Node.js to load JavaScript configurations such as .prettierrc.js. biome migrate prettier doesn’t support configuration written in JSON5, TOML, or YAML.

Emit machine-readable reports

Biome is now able to output JSON reports detailing the diagnostics emitted by a command.

For instance, you can emit a report when you lint a codebase:

biome lint --reporter=json-pretty .

For now, we support two report formats: json and json-pretty.

Note that the report format is **experimental **, and it might change in the future. Please try this feature and let us know if any information needs to be added to the reports.

Check `git` staged files

Biome v1.5 added the --changed to format and lint git tracked files that have been changed.

Today we are introducing a new option --staged which allows you to check only files added to the Git index (staged files). This is useful for checking that the files you want to commit are formatted and linted:

biome check --staged .

This is handy for writing your own pre-commit script. Note that unstaged changes on a staged file are not ignored. Thus, we still recommend using a dedicated pre-commit tool.

Thanks to @castarco for implementing this feature!

Linter

New nursery rules

Since Biome v1.6, we added several new rules. New rules are incubated in the nursery group. Nursery rules are exempt from semantic versioning.

The new rules are:

Promoted rules

Once stable, a nursery rule is promoted to a stable group. The following rules are promoted:

Miscellaneous

By default, Biome searches a configuration file in the working directory and parent directories if it doesn’t exist. Biome provides a CLI option --config-path and an environment variable BIOME_CONFIG_PATH that allows which can be used to override this behavior. Previously, they required a directory containing a Biome configuration file. For example, the following command uses the Biome configuration file in ./config/.
```
biome format --config-path=./config/ ./src
```
This wasn’t very clear for many users who are used to specifying the configuration file path directly. They now accept a file, so the following command is valid:
```
biome format --config-path=./config/biome.json ./src
```
You can now ignore React imports in the rules noUnusedImports and useImportType by setting javascript.jsxRuntime to reactClassic.
Biome applies specific settings to well-known files. It now recognizes more files and distinguishes between JSON files that only allow comments and JSON files that allow both comments and trailing commas.
In the React ecosystem, files ending in .js are allowed to contain JSX syntax. The Biome extension is now able to parse JSX syntax in files that are associated with the JavaScript language identifier.
useExhaustiveDependencies now supports Preact.

See the changelog for more details.

What’s Next?

We have started work on the CSS formatter and linter. Early implementation towards a plugin system is also underway. Some of our contributors have started preliminary work for GraphQL and YAML. Any help is welcome!

If Biome is valuable to you or your company, consider donating monthly to our Open Collective. You can also sponsor us on GitHub. This is important for the sustainability of the project.

Biome v1.6

Fri, 08 Mar 2024 00:00:00 GMT

Update Biome using the following commands:

npm install --save-dev --save-exact @biomejs/biome@latest
npx @biomejs/biome migrate

Partial support for Astro, Svelte and Vue files

In this release, we’re happy to provide partial support for Astro, Svelte and Vue files. What does partial support mean?

While the team is working on a unified data structure for HTML-ish languages, we discovered that we could provide Biome functionalities to those files with just a few changes, albeit with some limitations.

This means that Biome is able to analyze the JavaScript/TypeScript portion of said files, and all features are available: formatting, linting and import sorting! Here’s an example of what you should expect in terms of developer experience:

Make sure to read the documentation about expectations and limitations.

Configuration, lighter and more powerful

Support for `biome.jsonc`

Biome now accepts the biome.jsonc file as configuration! You can insert all the comments you want in there.

`extends` resolves dependencies

From this version, Biome can use the extends property to resolve other configuration files that are inside installed dependencies.

There are few important steps in order to make the configuration discoverable. The file must be exported from a "module" package, and the file should be exported in your package.json like this:

{
  "name": "@shared-configs",
  "type": "module",
  "exports": {
    "./biome": "./biome.json"
  }
}

This set up allows to expose a specifier @shared-configs/biome, which you use inside your biome.json file.

{
  "extends": ["@shared-configs/biome"]
}

The resolution of the dependencies is powered by the library oxc-resolver, one of the many libraries provided by the OXC project. It’s battle-tested and spec compliant!

Reduced memory footprint

We reduced the size our configuration by a factor of 6.5! This change might not have massive effects on the speed of the program, but it greatly reduced the memory used when running the CLI or the LSP.

New formatting options

Other than fixes, the formatter provides two new options that should improve the compatibility with Prettier.

Option `attributePosition`

When formatter.attributePosition has the value multiline, all attributes of HTML-ish languages (JSX/TSX as for time of writing) will be collapsed on multiple lines regardless of their numbers:

With variant `auto` (default)

The attributes are automatically formatted, and they will collapse in multiple lines only when they hit certain criteria.

file.jsx

<Button as="link" style="primary" href="https://example.com">
    Hit me
</Button>

With variant `multiline`

The attributes are always formatted on multiple lines, regardless.

file.jsx

<Button
    as="link"
    style="primary"
    href="https://example.com"
>
    Hit me
</Button>

The contributor @octoshikari implemented this new feature by themselves! Huge thank you for helping the Biome project.

Option `json.formatter.trailingCommas`

Previously, Biome parser introduced an option that would allow to parse JSON and JSONC files that contained a trailing comma. This was required to ease the friction caused by other tools that tolerate trailing commas by default (e.g. VSCode, Prettier, etc.).

Unfortunately, our formatter wasn’t as tolerant. But with this release, we’ve introduced the option json.formatter.trailingCommas. It allows you to apply the same rules as with js.formatter.trailingComma.

With variant `none` (default)

The formatter removes the trailing comma upon formatting.

file.json

{
    "lorem": "ipsum",
    "lorem": "ipsum",
    "lorem": "ipsum",
    "lorem": "ipsum_last"
}

With variant `all`

The formatter adds the trailing comma upon formatting.

file.json

{
    "lorem": "ipsum",
    "lorem": "ipsum",
    "lorem": "ipsum",
    "lorem": "ipsum_last",
}

Easier migration from Prettier

This release introduces a new command called biome migrate prettier. This command will read your Prettier .prettierrc/prettier.json and .prettierignore, and attempt to port its options and globs in Biome.

Given a prettier.json file, Biome will modify the existing configuration file to match Prettier’s options:

prettier.json

{ "useTabs": false, "semi": true, "singleQuote": true }

biome.json

{
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineEnding": "lf",
    "lineWidth": 80,
    "attributePosition": "auto"
  },
  "linter": { "enabled": true },
  "javascript": {
    "formatter": {
      "jsxQuoteStyle": "double",
      "quoteProperties": "asNeeded",
      "trailingCommas": "all",
      "semicolons": "always",
      "arrowParentheses": "always",
      "bracketSpacing": true,
      "bracketSameLine": false,
      "quoteStyle": "single",
      "attributePosition": "auto"
    }
  }
}

Linter

Promoted rules

New rules are incubated in the nursery group. Once stable, we promote them to a stable group. The following rules are promoted:

Additionally, the following rules are now recommended:

Removed rules

Remove nursery/useGroupedTypeImport. The rule style/useImportType covers the behavior of this rule.

New rules

New rules are now available:

Miscellaneous

We drastically reduced the number of protected files, which means you can now format your package.json, tsconfig.json, etc. with Biome. Lock files are still considered protected.
The CLI now does a better job at reporting the total number of files and the files that were really changed.
When a diagnostic shows a file name on the terminal that is integrated with your editor, you can click it and the editor will open the file for you.
The command biome rage now accepts two nice options: --formatter and --linter.
We removed some superfluous error diagnostic when running the biome check command.

Biome v1.5

Mon, 08 Jan 2024 00:00:00 GMT

Along with the Roadmap for 2024, the new logo and homepage, we also published a new version. This version has few features around the CLI and many fixes in our formatter. Our TypeScript, JSX and JavaScript formatting has surpassed the 97% compatibility rate with Prettier. Biome now provides over 190 lint rules.

Update Biome using the following commands:

npm install --save-dev --save-exact @biomejs/biome@latest
npx @biomejs/biome migrate

New features

Process only the files that were changed.
The command biome ci now prints diagnostics in GitHub PRs.
A new command,biome explain.
The command biome migrate updates the $schema.
New lint rules.

Process only the files that were changed

If you enable the integration with VCS, you can tell Biome to process only the files that were changed. As for now, this feature computes the files that were changed by using a VCS, so Biome doesn’t know exactly which lines changed.

This feature practically makes some utilities such as lint-staged obsolete.

To take advantage of this feature, you have to tell Biome what’s the default branch in the configuration file, and then you’ll have to pass the option --changed via CLI:

biome.json

{
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "defaultBranch": "main"
  }
}

Once you modified some files, use the new option to the command you need, for example the format command:

biome format --changed --write

The command `biome ci` now prints diagnostics in GitHub PRs

For quite some time, users were confused by the difference between the commands check and cibecause, until now, their behaviours have been very similar. From this version, the command ci can detect the GitHub CI environment and print annotation in the PRs.

It’s possible that you would need to change your permissions of your workflow files in case you don’t see the annotations:

.github/workflows/action.yml

permissions:
  pull-requests: write

A new command `biome explain`

This command will serve as an “offline” documentation tool. In this release, the command supports the explanation of all the lint rules; for example you can request documentation for noAccumulatingSpread:

biome explain noAccumulatingSpread

Which will print the following Markdown:

# noAccumulatingSpread

No fix available.

This rule is recommended.

# Description

Disallow the use of spread (`...`) syntax on accumulators.

Spread syntax allows an iterable to be expanded into its individual elements.

Spread syntax should be avoided on accumulators (like those in `.reduce`)
because it causes a time complexity of `O(n^2)` instead of `O(n)`.

Source: https://prateeksurana.me/blog/why-using-object-spread-with-reduce-bad-idea/

## Examples

### Invalid

```js,expect_diagnostic
var a = ['a', 'b', 'c'];
a.reduce((acc, val) => [...acc, val], []);
```

```js,expect_diagnostic
var a = ['a', 'b', 'c'];
a.reduce((acc, val) => {return [...acc, val];}, []);
```

```js,expect_diagnostic
var a = ['a', 'b', 'c'];
a.reduce((acc, val) => ({...acc, [val]: val}), {});
```

## Valid

```js
var a = ['a', 'b', 'c'];
a.reduce((acc, val) => {acc.push(val); return acc}, []);
```

We plan to make this output more readable for terminals, as well as provide autocompletion for this command.

The command `biome migrate` updates the `$schema`

The command biome migrate now updates the $schema value inside the configuration file biome.json if you avail of the online schema. Run this command as soon as you update to Biome v1.5.0:

biome.json

{
  "$schema": "https://biomejs.dev/schemas/1.4.1/schema.json"
  "$schema": "https://biomejs.dev/schemas/1.5.0/schema.json"
}

New rules

useExportType

interface I {
}

export {I};

nursery/useExportType.js:2:8 lint/nursery/useExportType  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ All exports are only types and should thus use export type.

    1 │ interface I {}
  > 2 │ export { I };
      │        ^^^^^^
    3 │ 

  ℹ Using export type allows transpilers to safely drop exports of types without looking for their definition.

  ℹ Safe fix: Use a grouped export type.

    2 │ export·type·{·I·};
      │        +++++

useImportType

import {A} from "./mod.js";

type TypeOfA = typeof A;
let a: A;

nursery/useImportType.js:1:1 lint/nursery/useImportType  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ All these imports are only used as types.

  > 1 │ import { A } from "./mod.js";
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    2 │ type TypeOfA = typeof A;
    3 │ let a: A;

  ℹ Importing the types with import type ensures that they are removed by the transpilers and avoids loading unnecessary modules.

  ℹ Safe fix: Use import type.

    1 │ import·type·{·A·}·from·"./mod.js";
      │        +++++

useFilenamingConvention

Enforces naming conventions for JavaScript and TypeScript filenames.

useNodejsImportProtocol

import fs from 'fs';

nursery/useNodejsImportProtocol.js:1:16 lint/nursery/useNodejsImportProtocol  FIXABLE  ━━━━━━━━━━━━━━━━━

  ⚠ Import from Node.js builtin module "fs" should use the "node:" protocol.

  > 1 │ import fs from 'fs';
      │                ^^^^
    2 │ 

  ℹ Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.

  ℹ Unsafe fix: Change to "node:fs".

    1   │ - import·fs·from·'fs';
      1 │ + import·fs·from·"node:fs";
    2 2 │

noNodejsModules

import fs from "fs";
import path from "node:path";

nursery/noNodejsModules.js:1:16 lint/nursery/noNodejsModules ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ⚠ Using Node.js modules are forbidden.

  > 1 │ import fs from "fs";
      │                ^^^^
    2 │ import path from "node:path";
    3 │ 

  ℹ Can be useful for client-side web projects that do not have access to those modules.

  ℹ Remove the import module.

noInvalidUseBeforeDeclaration

function f() {
    console.log(x);
    const x;
}

nursery/noInvalidUseBeforeDeclaration.js:3:11 parse ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Const declarations must have an initialized value.

    1 │ function f() {
    2 │     console.log(x);
  > 3 │     const x;
      │           ^
    4 │ }
    5 │ 

  ℹ This variable needs to be initialized.

noGlobalEval

eval("var a = 0");

nursery/noGlobalEval.js:1:1 lint/nursery/noGlobalEval ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ eval() exposes to security risks and performance issues.

  > 1 │ eval("var a = 0");
      │ ^^^^
    2 │ 

  ℹ See the MDN web docs for more details.

  ℹ Refactor the code so that it doesn't need to call eval().

noGlobalAssign

Object = null;

nursery/noGlobalAssign.js:1:1 lint/nursery/noGlobalAssign ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ A global variable should not be reassigned.

  > 1 │ Object = null;
      │ ^^^^^^^
    2 │ 

  ℹ Assigning to a global variable can override essential functionality.

noMisleadingCharacterClass

/^[Á]$/u;

nursery/noMisleadingCharacterClass.js:1:1 lint/nursery/noMisleadingCharacterClass ━━━━━━━━━━━━━━━━━━

  ⚠ Unexpected combined character in the character class.

  > 1 │ /^[Á]$/u;
      │ ^^^^^^^^
    2 │

noThenProperty

const foo = {
    then() {
    }
};

nursery/noThenProperty.js:2:5 lint/nursery/noThenProperty ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Do not add then to an object.

    1 │ const foo = {
  > 2 │     then() {}
      │     ^^^^
    3 │ };
    4 │

const foo = {
    get then() {
    }
};

noUselessTernary

var a = x ? true : true;

nursery/noUselessTernary.js:1:9 lint/nursery/noUselessTernary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Unnecessary use of boolean literals in conditional expression.

  > 1 │ var a = x ? true : true;
      │         ^^^^^^^^^^^^^^^
    2 │ 

  ℹ Simplify your code by directly assigning the result without using a ternary operator.

  ℹ If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
     Check for more details about NOT operator.

Roadmap 2024

Mon, 08 Jan 2024 00:00:00 GMT

We are thrilled to share what the Core Contributors and Maintainers would like to focus on in 2024.

We want to remind you that Biome is a community-driven project, so we can only promise that some of the ideas outlined below will be shipped.

However, if you’re excited about some aspects of the project, and you want to see some of them developed faster than others, you can help us in many ways:

Be involved in the project and the community. Please help us to build those features.
Sponsor us. Ask your company to sponsor us. Biome is so fast that it can reduce your company’s CI times and save money. Performance is part of our mission. Plus, sponsorship is a good medium of advertisement for your company.
Improve our documentation with ideas, recipes, or guides. Translate our documentation and help us to make Biome available to people who aren’t proficient in English.

Preface

The project is young and can’t compete against giants such as Prettier, ESLint, Webpack, Vite, ESBuild, etc. However, the recent events (sponsors, bounty challenge, Biome being a fork of Rome) showed that the users have interest in the project, and we showed those users that we have the tools to fulfil a need.

Moving small projects from ESLint/Prettier is easy, but moving big code bases is challenging and time-consuming; this is a big friction point in Biome.

Users have different needs, though, so it will only be possible to satisfy some of them. We want to ensure that all features and contributions to our project embrace our philosophy and provide the best experience by default.

Main area of focus

Help users to move to Biome
Expand Biome’s language support so Biome tools can span more of the web ecosystem
Deepen Biome’s existing capabilities to offer more functionalities
Plugins
Transformations
Community and content

Help users to move to Biome

Offer guides on our website to users who want to migrate from Prettier (CLI commands and configuration)
Offer guides on our website to users who want to migrate from ESlint (CLI commands and configuration)
Offer a section on our website that shows a mapping of the ESLint rules to our rules
Offer commands to ease the transition
- A command called biome migrate prettier that will read .prettierrc and .prettierignore will update the biome.json file (or create it) with the configuration from the Prettier files.
- A command called biome migrate eslint will read the JSON configuration of Eslint and the ignore file. There will be expectations and limitations.

Expand Biome’s language support

CSS is our next language of focus, and we are making good progress. HTML and Markdown will follow. Follow our up-to-date page to keep up with the progress of our work.

The CSS language will enable much work and experimentation: CSS formatting and linting, and we will port some of the lint rules from stylelint. A new area of experimentation is cross-linting.

The idea of cross-linting can be explained with an example: compute the CSS styles/classes defined in a project and warn a user when said styles aren’t used inside JSX/HTML files.

Plus, we unlock another area of experimentation, which is embedded formatting.

HTML and Markdown will be our next languages of focus. HTML will enable us to parse other variants of HTML that are popular in the frontend ecosystem: Vue, Svelte and Astro, and this would require some exploration of how to represent super languages of HTML.

Deepen Biome’s existing capabilities to offer more functionalities.

Project analysis and dependency resolution
Type system
CLI

Project analysis and dependency resolution

We will provide lint rules to read the manifest and detect errors such as invalid licenses.

With project resolution, we will be able to provide more lint rules, some of which will be able to detect unused modules.

With dependency resolution, we can - for example - detect dependencies that aren’t used inside a project.

With this infrastructure, our LSP is going to be more powerful and provide more features, for example:

rename variables across a project;
auto-complete for imports;
in-line types

Type system

Building a full-fledged type system such as TypeScript is a massive effort; that’s why we decided to take a different direction and start by building a subset of the type system that requires stricter typing. This approach would allow us to build some important lint rules that users have been asking for.

This will come with a downside: we will have to rely on a stricter code and minimal type inference from the compiler.

Once we have something we can rely on, we can slowly widen the capabilities of our type system.

CLI

More features for the command line tool, such as:

Add the explain command for offline documentation;
Allow the output to be exported in different formats (JSON, etc.)
Auto-completion for other shells such as zsh;
Implement the --modified argument, which allows to format - for example - only the modified lines of a document;
Expose metrics for Biome’s operations and being able to track down possible performance bottlenecks;

Plugins

We will explore plugins and come up with a design that fits Biome. Biome is different from other tools because Biome is a toolchain that has multiple tools in it, so we have to think out of the box and propose a design that might differ from the tools people are used to.

We don’t know yet what a Biome’s plugin will look like, although a plugin should be able to tap all the tools that Biome offers.

Some ideas that we will consider:

DSL
WASM
A Runtime

Transformations

Transformations and code generation will be our first steps towards our compiler.

We will provide the ability to transform TypeScript and JSX files into JavaScript files.

Community and content

Biome has a growing ecosystem, with an official VSCode extension, an official IntelliJ extension, and a Discord bot. We want to grow the features these tools provide and welcome anyone who wants to help us.

Our community is slowly growing, and we want to reward everyone who sticks around and contributes to Biome. At Biome, we value every contribution, so you don’t need to be proficient in Rust to help us. Even participating in discussions and helping us to shape our features or helping other people are considered contributions. If you’d like to continue contributing to our ecosystem, we also encourage you to nominate yourself as a maintainer of the project.

Recently Biome started its own YouTube Channel. We will use this channel to share learning content with the community.

New logo and homepage

With this blog post, we also want to officially announce our new logo, homepage and rebranding of the website.

With this new logo, we want to give a different meaning to the project. Biome isn’t a fork of Rome anymore, but a self-sufficient project ready to bloom.

The triangle of the logo represents the mountains - soil -, and the curly shape on the bottom left represents a wave of the ocean - water. Two elements that are important in creating a self-sufficient ecosystem, so it can thrive and grow.

Biome formatter wins the Prettier challenge

Mon, 27 Nov 2023 00:00:00 GMT

With the release of Biome **v1.4.0 **, we claim the bounty of the Prettier challenge!

With v1.4.0, you’ll get a better formatter experience, more formatting options, new VSCode features, new sponsors and more!

You can upgrade Biome by running the following command:

npm install --save-dev --save-exact @biomejs/biome@1.4.0
pnpm update --save-exact @biomejs/biome@1.4.0
yarn upgrade --exact @biomejs/biome@1.4.0

Better formatter

Biome formatter has now **over 96% in terms of compatibility ** against Prettier! This score is computed for JavaScript, TypeScript, and JSX formatting.

Merit of challenge that was launched by Christopher Chedeau, one of the Prettier’s creators.

The challenge attracted the attention of many people, and some of them decided to contribute to Biome to claim part of the bounty. I did see something amazing: contributors had an amazing coordination, they took ownership of the tasks and delivered the solution in a matter of hours.

I believe the main factors that made this possible are three:

Money. It’s a fact, and it’s completely fine if someone decides to contribute only for earning a small stipend out of it.
Communication. We used GitHub as only medium of coordination. We provided information, instructions and help on how to deliver.
Infrastructure. Biome relies on a solid testing infrastructure, built by previous Rome Tools employees and contributors. It’s able to catch every reformat bug, provide granular diffs and warn the user if the emitted output is the different from the one emitted by Prettier.

Before the challenge, Biome had roughly a compatibility rate of 85%, based on our internal metrics (JavaScript, TypeScript and JSX, on options parity). Even though 85% might seem high, the impact of a low number such as 15% on big code bases is huge, and people might feel intimidated by so many changes, causing early adopters to receive frictions when bring Biome to their team. A member of our community shared some insights:

As a great example of how much even just that last 5% has improved things for large codebases (and specifically with bracketSpacing and now bracketSameLine implemented) i ran it one project in our monorepo […].

Just last week, this number [diagnostics] was more than 6,000. Even with the bracket options ignored, it was still more than 1000, and now there are only 200 left!

Although the challenge is over, we are committed to improve even more the compatibility score with prettier. Any contribution in this regard is very welcome.

The challenge has also uncovered some cases in Prettier’s emitted output that we decided to not follow. We have created a new section in our website that explains them. Our hope is to make this section smaller with the time.

If there’s a divergence that isn’t documented in our website, you should consider that a bug and file an issue.

New formatting options

With this challenge, we added new options to the formatter:

lineEnding

Use this option to match the line endings of your OS. We support lf (line feed - \n), cr (carriage return - \r) and crlf (carriage return line feed - \r\n).

bracketSameLine

example.js

// Existing behavior. Now also the default, meaning `bracketSameLine: false`.
<Foo
  className={somethingReallyLongThatForcesThisToWrap}
  anotherReallyLongAttribute={withAValueThatsSurelyTooLong}
  soThatEverythingWraps
>
  Hello
</Foo>

<Foo
  selfClosingTags={likeThisOne}
  stillPlaceTheBracket={onItsOwnLine}
  toIndicateThat={itClosesItself}
/>

After formatting with "bracketSameLine": true:

example.js

// New behavior, with `bracketSameLine: true`.
<Foo
  className={somethingReallyLongThatForcesThisToWrap}
  anotherReallyLongAttribute={withAValueThatsSurelyTooLong}
  soThatEverythingWraps>
  Hello
</Foo>

<Foo
  selfClosingTags={likeThisOne}
  stillPlaceTheBracket={onItsOwnLine}
/>

bracketSpacing

example.js

import { sort } from "sort.js";
const value = { sort };

After formatting with "bracketSpacing": false:

example.js

import {sort} from "sort.js";
const value = {sort};

VSCode extension goodies

The VSCode has been moved to a new repository.

We removed the bundled binary from the extension, and you’ll be able to download the version that you want. Here’s a small video of how it works:

From today, we release a nightly version of the extension. This is a version meant for early adopters and to test things before they are officially released.

Some CLI goodies

People that rely on Biome LSP will be pleased that they can now pass a custom configuration to the command lsp-proxy, using the option --config-path. The same option is accepted by the command start:

biome --config-path=../path/where/config/is lsp-proxy
biome --config-path=../path/where/config/is start

The CLI now exposes the option --diagnostic-level, that allows to filter the kind of diagnostics printed to terminal.

biome check --diagnostic-level=error ./src

New lint rules, and promoted rule

Biome is a linter too, and it features 177 rules! In this release, some rules are promoted and new ones are available.

New rules

noDefaultExport

export default function f() {}

nursery/noDefaultExport.js:1:8 lint/nursery/noDefaultExport ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ⚠ Avoid default exports.

  > 1 │ export default function f() {};
      │        ^^^^^^^
    2 │ 

  ℹ Default exports cannot be easily discovered inside an editor and don't encourage the use of consistent names through a code base.

  ℹ Use a named export instead.

noAriaHiddenOnFocusable

<div aria-hidden="true" tabIndex="0" />

nursery/noAriaHiddenOnFocusable.js:1:1 lint/nursery/noAriaHiddenOnFocusable  FIXABLE  ━━━━━━━━━━━━━━

  ✖ Disallow aria-hidden="true" from being set on focusable elements.

  > 1 │ <div aria-hidden="true" tabIndex="0" />
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    2 │ 

  ℹ aria-hidden should not be set to true on focusable elements because this can lead to confusing behavior for screen reader users.

  ℹ Unsafe fix: Remove the aria-hidden attribute from the element.

    1 │ <div·aria-hidden="true"·tabIndex="0"·/>
      │      -------------------

noImplicitAnyLet

var a;
a = 2;

nursery/noImplicitAnyLet.js:1:5 lint/nursery/noImplicitAnyLet ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ This variable implicitly has the any type.

  > 1 │ var a;
      │     ^
    2 │ a = 2;
    3 │ 

  ℹ Variable declarations without type annotation and initialization have implicitly the any type. Declare type or initialize the variable with some value.

useAwait

async function fetchData() {
  // Missing `await` for the promise returned by `fetch`
  return fetch("/data");
}

nursery/useAwait.js:1:1 lint/nursery/useAwait ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ This async function lacks an await expression.

  > 1 │ async function fetchData() {
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  > 2 │ // Missing `await` for the promise returned by `fetch`
  > 3 │   return fetch('/data');
  > 4 │ }
      │ ^
    5 │ 

  ℹ Remove this async modifier, or add an await expression in the function.

  > 1 │ async function fetchData() {
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  > 2 │ // Missing `await` for the promise returned by `fetch`
  > 3 │   return fetch('/data');
  > 4 │ }
      │ ^
    5 │ 

  ℹ Async functions without await expressions may not need to be declared async.

useValidAriaRole

<div role="datepicker"></div>

nursery/useValidAriaRole.js:1:1 lint/nursery/useValidAriaRole  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Enforce that elements with ARIA roles must use a valid, non-abstract ARIA role.

  > 1 │ <div role="datepicker"></div>
      │ ^^^^^^^^^^^^^^^^^^^^^^^
    2 │ 

  ℹ Check WAI-ARIA for valid roles or provide options accordingly.

  ℹ Unsafe fix: Remove the invalid role attribute.
     Check the list of all valid role attributes.

    1 │ <div·role="datepicker"></div>
      │      -----------------

useRegexLiterals

new RegExp("abc", "u");

nursery/useRegexLiterals.js:1:1 lint/nursery/useRegexLiterals  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ⚠ Use a regular expression literal instead of the RegExp constructor.

  > 1 │ new RegExp("abc", "u");
      │ ^^^^^^^^^^^^^^^^^^^^^^
    2 │ 

  ℹ Regular expression literals avoid some escaping required in a string literal, and are easier to analyze statically.

  ℹ Safe fix: Use a literal notation instead.

    1   │ - new·RegExp("abc",·"u");
      1 │ + /abc/u;
    2 2 │

Recommended rules

a11y/noAccessKey

<input type="submit" accessKey="s" value="Submit" />

a11y/noAccessKey.js:1:22 lint/a11y/noAccessKey  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Avoid the accessKey attribute to reduce inconsistencies between keyboard shortcuts and screen reader keyboard comments.

  > 1 │ <input type="submit" accessKey="s" value="Submit" />
      │                      ^^^^^^^^^^^^^
    2 │ 

  ℹ Assigning keyboard shortcuts using the accessKey attribute leads to inconsistent keyboard actions across applications.

  ℹ Unsafe fix: Remove the accessKey attribute.

    1 │ <input·type="submit"·accessKey="s"·value="Submit"·/>
      │                      --------------

a11y/useHeadingContent

<h1 />

a11y/useHeadingContent.js:1:1 lint/a11y/useHeadingContent ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Provide screen reader accessible content when using heading  elements.

  > 1 │ <h1 />
      │ ^^^^^^
    2 │ 

  ℹ All headings on a page should have content that is accessible to screen readers.

complexity/useSimpleNumberKeys

({ 0x1: 1 });

complexity/useSimpleNumberKeys.js:1:4 lint/complexity/useSimpleNumberKeys  FIXABLE  ━━━━━━━━━━━━━━━━

  ✖ Hexadecimal number literal is not allowed here.

  > 1 │ ({ 0x1: 1 });
      │    ^^^
    2 │ 

  ℹ Safe fix: Replace 0x1 with 1

1   │ - ({·0x1:·1·});
  1 │ + ({·1:·1·});
2 2 │

Promoted rules

Deprecated rules

correctness/noNewSymbol

The rule is replaced by correctness/noInvalidNewBuiltin

Homage to our maintainers

Since Biome was forked, new people joined the project. They have been helping with in so many ways that you can’t even imagine: new features, side projects, engaging with the community, support, documentation, and more. OSS is not just about coding.

Thank you to:

And a big welcome to our new joined maintainer:

New sponsors

Last but not least, we are proud to announce that we have two new sponsors:

Gold: Shiguredō (https://shiguredo.jp/)
Bronze: KANAME (https://www.kanamekey.com/)

If you want to economically contribute to the project and help it to ship more features, you can do so from the GitHub Sponsorship page or the Open Collective page.

What’s next

The project is thriving, with more people curious about the project and contributors that want to be involved.

In the next months we will focus on:

Publishing a Roadmap. Keep an eye on it, it will involve a lot of interesting work.
Rebranding the website with a new logo.
Translate the website in Japanese.

Translations

中文翻译: Biome赢得了Prettier挑战

Announcing Biome

Tue, 29 Aug 2023 00:00:00 GMT

We are happy to announce Biome, toolchain of the web.

Biome is the official fork of Rome and it will continue to be Rome’s legacy.

Biome is led and maintained by the same people that maintained Rome so far.

Follow us:

Background

I want to give you some background and context, which could help you to get why the core team created a new project with a new name. If you’re not interested, feel free to jump to the next section

How it started

Before explaining the reasons for the fork, I’d like to give you some background and context; this would help you understand the reasons that led to this decision.

When I joined the Rome project, the project was still young and written in TypeScript. A long time passed, and the project underwent many transitions.

Rome was initially released and licensed under the Meta OSS umbrella. Meta is an excellent incubator for OSS projects, but some people didn’t like it. At least, my impression was that they didn’t.

The npm package rome belonged to another person, so when ownership changed, there were already a lot of version numbers used. The team always struggled with versioning. It shouldn’t be hard to version a software!

After a few months, the project got out of Meta’s OSS umbrella. In six months, the creator Sebastian McKenzie created the company Rome Tools Inc., to keep working on the Rome project so to eventually became sustainable.

I was excited about the news because I believed in Rome’s mission, so I decided to quit my job and join the adventure. In a few weeks, I joined Rome Tools Inc. as a full-time employee to work on developer tools as my daily job. For me, it was like a dream coming true!

How it ended (or did it?)

Not all startups manage to succeed, and Rome Tools Inc. wasn’t one of the lucky ones. Eventually, all the employees were laid off.

My adventure with Rome Tools Inc. sadly ended, but fortunately, my career working with developer tools continued! A few months later, I joined the Astro Technology Company working full-time. It’s a great place to work, and I get to do what I love every day with fantastic people. I love it!

Part of me was still charmed by Rome’s mission though. However, it wasn’t just that. I like working on parsers/compilers in my free time. I love the Rust language, and Rome is the perfect OSS project where I can use it.

So, in my free time, I continued with my contributions to Rome as much as possible; luckily, I still had some rights that allowed me to publish new versions of the project. Despite the unsuccessful adventure with Rome Tools Inc., I wanted to keep the project alive.

A few new OSS contributors joined the cause and helped in contributing to the project. I wasn’t alone, and that’s the great thing about OSS. You eventually find people who like the project and want to contribute too.

In June, I gave a talk about Rome at JsNation 2023.

So, the project is still alive, but maintaining it has become challenging:

I don’t have admin rights on Discord, so I can’t delegate moderation rights to other people;
I don’t have access to the hosting platform of the website;
I don’t have access to any registry (npm, VSCode, etc.);
the project is still under the MIT license of Rome Tools Inc., which makes attributions and contributions seem foggy from a legal point of view (where’s the company? I don’t know).

Many attempts to reach out to the current owner were all void. There was only one thing I could do. We could do.

Enters: Biome

We created Biome. After weeks of discussions among the members of the core team and conversations with some friends, we thought that a clean slate was the best course of action.

We pondered the idea of keeping the “rome” name in the new fork, but that was proven difficult:

Sebastian has registered tons of stuff with the “rome” name (GitHub organizations, website domains, open collectives, npm organizations). Finding the right combination wasn’t easy;
without the proper rights in the Discord server, we couldn’t delegate the moderation rights. Discord is a very important asset for community building;
keeping the name would have caused some attribution to Rome Tools Inc., making things still foggy when it comes to the legal aspects of the source code;
we don’t know if the “rome” name is registered; if it turns out it is, we could have incurred some legal troubles;
“Rome” has a lot of historical baggage, as explained before (Meta and, fail as a startup);

Given all these difficulties, the core team settled for a new project.

”New is always better.”

Biome will embrace the same philosophy of the old Rome and the same mission. Although, the roadmap will likely change, and the core team could decide to focus on making the current features more stable instead of releasing new ones.

Still, the primary mission is alive, and Biome wants to be a 360° toolchain; we recently started working on transformations, which will eventually set up the foundations of the compiler.

Why Biome

The team wanted to create a second “Rome”, a second version of it. So we fused the words “Bis” and “Rome”. **Biome"".

I still use the `rome` package. What should I do?

The rome package won’t be maintained anymore by the core team, so you won’t get any more releases.

You should use the @biomejs/biome package. Note that Biome also comes with a lot of new features and fixes. We’ve just prepared a blog post for that.
```
{
  "rome": "12.1.3"
  "@biomejs/biome": "1.0.0"
}
```

And change the CLI name in your scripts:

{
  "scripts": {
    "format": "rome format --write ./src",
    "format": "biome format --write ./src"
  }
}

In your rome.json file, update the URL of the $schema field:

{
  "$schema": "https://docs.rome.tools/schemas/12.1.3/schema.json",
  "$schema": "https://biomejs.dev/schemas/1.0.0/schema.json"
}

Then install the new official VSCode or open VSX extension. That’s an important step if you use these extensions.

After the installation of the extension, open the settings.json. If you have some Rome related settings there, you’ll have to update them:

{
  "[javascript]": {
    "editor.defaultFormatter": "rome.rome"
    "editor.defaultFormatter": "biomejs.biome"
  },
  "editor.codeActionsOnSave": {
    "quickfix.rome": true,
    "source.organizeImports.rome": true
    "quickfix.biome": true,
    "source.organizeImports.biome": true
  }
}

Biome still accepts the rome.json file as a configuration, so you don’t need to do anything yet. Biome also takes biome.json as a configuration file.

We will eventually sunset the rome.json configuration file for biome.json, but Biome will do that for you in the subsequent releases. So, don’t worry about updating everything unless you want to.

The core team

Emanuele Stoppa: me, the lead of the project 🤓
Denis Bezrukov: Denis has contributed to the project for a long time He made contributions to many tools like formatter and parser;
Victorien Elvinger: Victorien is very passionate, and he’s made tons of contributions to the Biome linter by creating new rules and optimising the ones that were already there when he joined;
Daiki Nishikawa: Daiki worked on linter and parser, by adding new rules, fixing the existing ones, improving the internal semantic model, and adding new grammar to the JavaScript/TypeScript parser;
unvalley: unvalley added a lot of value to the linter and parser. They tackled some complex rules, for example, especially the ones around regex;

Special thanks

Strager: his inputs and constructive criticisms to the project are what helped Biome to arrive to this point;
Boshen: one of the greatest admirers of the project since the Rust rewrite; he joined the Biome community to learn from us and contribute as much as possible. He now leads a similar project to Biome, oxc. Check it out.
Micha: ex-employee of Rome Tools Inc., he is now a full-time developer of the project Ruff, he gave a lot of good pieces of advice, and he was a good listener when I was struggling to make the right decisions.

Translations

中文翻译: 宣布 Biome

Biome v1

Tue, 29 Aug 2023 00:00:00 GMT

In Biome v1, the formatter has options for JSX quotes and parentheses in the arrow functions; the CLI adds a new command biome lint, .jsonc files are supported, and it’s possible to extend the configuration file.

You can upgrade Biome by running the following command:

npm install --save-dev --save-exact @biomejs/biome@1.0.0
pnpm update --save-exact @biomejs/biome@1.0.0
yarn upgrade --exact @biomejs/biome@1.0.0

Or install the VS Code extension to integrate Biome into your editor.

New formatter options

Biome now supports two new, long-awaited options:

support for formatting the preferred quote kind in JSX;
support for formatting parenthesis in arrow functions only when they are needed;

JSX quotes style

You can use this option via CLI or via biome.json file:

biome.json

{
  "javascript": {
    "formatter": {
      "jsxQuoteStyle": "single"
    }
  }
}

biome format --jsx-quote-style=single --write ./src

And Biome will apply single quotes when defining attributes in JSX code:

import Item from "./item.jsx";

const Header = () => {
  return <Item title="Docs" />;
};

Arrow function parenthesis

You can decide not to print parenthesis in arrow functions. You can customize the option via CLI or via biome.json:

biome.json

{
  "javascript": {
    "formatter": {
      "arrowParentheses": "asNeeded"
    }
  }
}

biome format --arrow-parentheses=as-needed --write ./src

And Biome will print parenthesis only for those arrow functions that require them:

// no need for parentheses
const filter = (term) => {};
// needs parentheses
const filterBy = (term, fn) => {};

CLI improvements

The CLI was heavily reworked to guarantee consistent behaviour when handling files, diagnostics emitted and commands.

Among those changes, there are some breaking changes in its behaviour.

The CLI exits with an error code if the configuration file contains errors; while Biome can parse the configuration successfully - even with errors - this was a hazard for our users. A typo in the configuration file would have resulted in Biome applying its defaults, and executing Biome with a different behaviour compared to the one set by the user.
The command biome check will now emit error diagnostics for code not formatted and exits with an error code. This behaviour aligns with the semantics meant for this command.

New `biome lint` command

The command biome check is meant to run multiple tools, which sometimes can overwhelm the users. With biome lint, Biome will only run lint rules against files.

As for now, the command accepts almost all the CLI arguments of the biome check. In the future, this command will specialize and tweak its behaviour around linting.

More control over errors

By default, when Biome sees a file that can’t handle, it fires a diagnostic and will exit with an error code.

With --files-ignore-unknown option, the CLI won’t emit diagnostics and will continue processing files.

You can define this behaviour in the biome.json too:

biome.json

{
  "files": {
    "ignoreUnknown": true
  }
}

When Biome doesn’t process files during a command, it exits with an error code and emits an error diagnostic.

Now, with --no-errors-on-unmatched, Biome will exist with a successful code and doesn’t emit any diagnostics.

This new option allows users to use Biome with tools like lint-staged.

Exit on warnings

In Biome, you can change the configuration of rules and allow them to emit diagnostics. This behaviour was limited, and now with --error-on-warnings option, you can tell Biome to exit with an error code if a warning is emitted.

Here’s an example, let’s change the diagnostic level of a rule via biome.json:

biome.json

{
  "linter": {
    "recommended": true,
    "rules": {
      "a11y": {
        "useAltText": "warn"
      }
    }
  }
}

Here’s a sample code that will trigger the rule:

const Image = () => {
  return <img src="https://example.com/image.png" />;
};

And now, run the CLI using the new option:

biome lint --error-on-warnings ./src

JSONC support and comments

Biome’s JSON parser now supports comments, so we enabled these exciting new features.

`.jsonc` file support

Biome can now format and lint .jsonc files.

Allow comments in JSON files

Biome can parse comments inside JSON files. You can opt-in to this feature via the configuration file:

biome.json

{
  "json": {
    "parser": {
      "allowComments": true
    }
  }
}

Plus, Biome now recognizes some known files as “JSON files that can have comments”. For example, now Biome can format your tsconfig.json file with comments without emitting errors!

`extends` property

You can now break down your configuration file into different files and join them using the new extends property.

biome.json

{
  "extends": ["./formatter.json", "./linter.json"]
}

Check the documentation to understand how it works.

Linter

We deleted two rules:

useCamelCase, which is replaced by useNamingConvention;
noExtraSemicolon, not needed; the formatter takes care of it;

New Rules

noDuplicateJsonKeys

This rule disallows duplicate keys in a JSON object.
noExcessiveComplexity

This rule computes a complexity score and reports code with a score above a configurable threshold.
noFallthroughSwitchClause

This rule disallows switch cases that fall through to the next case.
noGlobalIsFinite

This rule recommends using Number.isFinite instead of the global and unsafe isFinite that attempts a type of coercion.
noGlobalIsNan

This rule recommends using Number.isNaN instead of the global and unsafe isNaN that attempts a type of coercion.
noNonoctalDecimalEscape

This rule disallows \8 and \9 escape sequences in string literals.
noUnsafeDeclarationMerging

This rule disallows declaration merging between an interface and a class.
noUselessEmptyExport

This rule disallows useless export {}.
noUselessThisAlias

This rule disallows useless aliasing of this in arrow functions.
noVoid

This rule disallows the use of void.
useArrowFunction

This rule proposes turning function expressions into arrow functions. Function expressions that use this are ignored.
useGetterReturn

This rule enforces get methods to always return a value.
useImportRestrictions

Enables restrictions on how local imports should be imported.
useIsArray

This rule proposes using Array.isArray() instead of instanceof Array.
useNamingConvention

The rule enforces wide-spread naming conventions of Javascript and TypeScript across a codebase.

Promoted rules

New rules are promoted, please check #4750 for more details:

The following rules are now recommended:

Support for function class parameter decorators

In the last release, Biome introduced support for Stage 3 decorators. Although, this final proposal doesn’t support the function class parameter decorators:

class Controller {
    get(@Param("id") id: string) {}
    // ^^^^^^^^^^^^ syntax not covered by the official and final decorators spec
}

Some users were dissatisfied because they couldn’t use Biome inside their Angular/NestJS project. Now you can do it via configuration:

biome.json

{
  "javascript": {
    "parser": {
      "unsafeParameterDecoratorsEnabled": true
    }
  }
}

Acknowledgements

Big thank you to the following contributors:

denbezrukov, they implemented the new decorator parameter, the new option jsxQuoteStyle in the formatter, and started the works for our new CSS parser;
Conaclos, they continued creating new rules, making the existing ones smarter and adding tons of value to Biome;
SuperchupuDev, they implemented the new option arrowParentheses in the formatter;
nissy-dev, they fixed a bunch of issues around the linter;
unvalley, they fixed a bunch of issues around the linter and implemented new rules;
arendjr, they implemented new rules in the linter and implemented the new import sorting strategy;
ddanielsantos, for their first contribution to the project;
nikeee, for their first contribution to the project;

Translations

中文翻译: Biome v1版本

Biome | Blog

Biome v2.4—Embedded Snippets, HTML Accessibility, and Better Framework Support

Highlights

Embedded snippets in JavaScript

Editor inline configuration

Major improvements to HTML-ish languages

HTML accessibility rules

Rule profiler

Configuration file discovery

Linter and Assist

New Assist Actions

Remove Duplicate CSS Classes

Sort Interface Members

Enhanced Lint Rules

useSortedKeys with groupByNesting Option

useHookAtTopLevel with ignore Option

useIterableCallbackReturn with checkForEach Option

Improved useHookAtTopLevel Detection

useImportExtensions with Custom Mappings

useUnifiedTypeSignatures Enhancements

Ignore Options for CSS Rules

Improved Svelte Variables Detection

New Linter Domain: types

Promoted Rules

Correctness Rules

Suspicious Rules

Complexity Rules

Style Rules

Formatter

Embedded Snippets Formatting

Trailing Newline Option

Top-Level Suppression Comments

Formatting Applied with Code Fixes

CSS Parser Improvements

CSS @function At-Rule Support

CSS Modules Auto-Detection

CSS Properties Ordering Update

CSS Module Syntax in Vue/Svelte/Astro

CLI

Enhanced --skip and --only Flags

Multiple Reporters and Reporter Output to Files

Combine Multiple Reporters in CI

Save Reporter Output to a File

New SARIF Reporter

File Watcher Control

Enhanced Logging Options

Stacktrace for Fatal Errors

Additional Features

GritQL JSON Support

LSP and Editor Features

LSP Progress Reporting

Configuration and Editor Support

Cursor Files Support

Other Improvements

Vue SFC CSS Syntax Support

e18e ESLint Plugin Support

More Improvements

I like where this is going, how can I help?

Translations

Chat with us

Code contributions

Financial help

Roadmap 2026

2025 achievements

Past mistakes

Monorepo out of the box

Difficult to debug

Poor communication

2026 roadmap

Markdown

Can I help move Biome’s roadmap forward?

Chat with us

Financial help

GritQL accepted by the Biome organisation

So, does that mean Biome is now responsible for the development of GritQL?

What does this mean for Biome’s plugin infrastructure, concretely?

Where does this leave JavaScript/TypeScript plugins?

Can I help move Biome’s plugin efforts forward?

Chat with us

Financial help

`useSortedKeys` with `groupByNesting` Option

`useHookAtTopLevel` with `ignore` Option

`useIterableCallbackReturn` with `checkForEach` Option

Improved `useHookAtTopLevel` Detection

`useImportExtensions` with Custom Mappings

`useUnifiedTypeSignatures` Enhancements

New Linter Domain: `types`

CSS `@function` At-Rule Support

Enhanced `--skip` and `--only` Flags

Updated the `react` domain

Improved `--skip` and `--only` flags

Enhanced `init` command

`lineEnding` format option