Biome | 博客

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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.

Section titled “Vercel becomes Biome’s first platinum sponsor”

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

Section titled “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?

Section titled “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?

Section titled “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?

Section titled “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?

Section titled “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:

Terminal window

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

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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 hueristics.

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`

Section titled “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

Section titled “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

Section titled “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.

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: https://next.biomejs.dev/assist/

Improved suppressions

Section titled “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: https://next.biomejs.dev/linter/#suppress-lint-rules

HTML formatter

Section titled “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

Section titled “New rules”

Several new rules have added since v1.9:

Miscellaneous

Section titled “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!

Section titled “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

Section titled “🎆 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

Section titled “💳 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

Section titled “⏭️ 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

Section titled “🌌 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

Section titled “❤️ 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

Section titled “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

Section titled “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:

Terminal window

biome migrate --write

Stable CSS formatter and linter

Section titled “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:

Terminal window

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

Section titled “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:

Terminal window

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

Section titled “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:

Terminal window

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

Section titled “.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

Section titled “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!

Section titled “And more!”

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

What’s next

Section titled “What’s next”

VSCode plugin v3

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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:

Terminal window

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

Section titled “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:

Terminal window

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

Section titled “Linter”

New nursery rules

Section titled “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

Section titled “Promoted rules”

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

Miscellaneous

Section titled “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/.
Terminal window
```
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:
Terminal window
```
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?

Section titled “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:

Terminal window

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

Partial support for Astro, Svelte and Vue files

Section titled “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

Section titled “Configuration, lighter and more powerful”

Support for `biome.jsonc`

Section titled “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

Section titled “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

Section titled “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

Section titled “New formatting options”

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

Option `attributePosition`

Section titled “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`

Section titled “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

Section titled “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

Section titled “Linter”

Promoted rules

Section titled “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

Section titled “Removed rules”

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

New rules

Section titled “New rules”

New rules are now available:

Miscellaneous

Section titled “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:

Terminal window

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

New features

Section titled “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

Section titled “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:

Terminal window

biome format --changed --write

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

Section titled “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`

Section titled “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:

Terminal window

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`

Section titled “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

Section titled “New rules”

useExportType

Section titled “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

Section titled “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

Section titled “useFilenamingConvention”

Enforces naming conventions for JavaScript and TypeScript filenames.

useNodejsImportProtocol

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “noMisleadingCharacterClass”

/^[Á]$/u;

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

  ⚠ Unexpected combined character in the character class.

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

noThenProperty

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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.

Section titled “Deepen Biome’s existing capabilities to offer more functionalities.”

Project analysis and dependency resolution
Type system
CLI

Project analysis and dependency resolution

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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:

Terminal window

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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:

Terminal window

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.

Terminal window

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

New lint rules, and promoted rule

Section titled “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

Section titled “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

Section titled “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

Section titled “Promoted rules”

Deprecated rules

Section titled “Deprecated rules”

correctness/noNewSymbol

The rule is replaced by correctness/noInvalidNewBuiltin

Homage to our maintainers

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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?)

Section titled “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

Section titled “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.”

Section titled “”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

Section titled “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?

Section titled “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

Section titled “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

Section titled “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

Section titled “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:

Terminal window

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

Section titled “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

Section titled “JSX quotes style”

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

biome.json

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

Terminal window

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

Section titled “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"
    }
  }
}

Terminal window

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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:

Terminal window

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

JSONC support and comments

Section titled “JSONC support and comments”

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

`.jsonc` file support

Section titled “.jsonc file support”

Biome can now format and lint .jsonc files.

Allow comments in JSON files

Section titled “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

Section titled “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

Section titled “Linter”

We deleted two rules:

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

New Rules

Section titled “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

Section titled “Promoted rules”

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

The following rules are now recommended:

Support for function class parameter decorators

Section titled “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

Section titled “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

Section titled “Translations”

中文翻译: Biome v1版本

Biome | 博客

VS Code extension V3

Multi-root workspaces

Single-file mode

Unsaved files & VS Code settings

Automatic reload

Improved status indicator

Retiring the downloader

Biome partners with Vercel to improve type inference

Vercel becomes Biome’s first platinum sponsor

Frequently Asked Questions

Are you reimplementing a type checker in Biome?

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

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

Can we follow your progress?

Biome v2.0 beta

New features

Plugins

Domains

Multi-file analysis

noFloatingPromises

Import Organizer Revamp

Assists

Improved suppressions

HTML formatter

New rules

Miscellaneous

And more!

Roadmap 2025 and Biome 2.0

🎆 Recap: Biome in 2024

💳 Enterprise Support

⏭️ Biome 2.0

🌌 2025 roadmap

❤️ Your Support

Biome v1.9 Anniversary Release

One year of Biome

Biome v1.9

Stable CSS formatter and linter

Stable GraphQL formatter and linter

Search command

.editorconfig support

JavaScript formatter and linter

And more!

What’s next

VSCode plugin v3

Biome 2.0

Biome v1.7

Migrate from ESLint with a single command

Migrate from Prettier with a single command

Emit machine-readable reports

Check git staged files

Linter

New nursery rules

Promoted rules

Miscellaneous

What’s Next?

Biome v1.6

Partial support for Astro, Svelte and Vue files

Configuration, lighter and more powerful

Support for biome.jsonc

extends resolves dependencies

Reduced memory footprint

New formatting options

Option attributePosition

With variant auto (default)

With variant multiline

Option json.formatter.trailingCommas

With variant none (default)

With variant all

Easier migration from Prettier

Linter

Promoted rules

Removed rules

New rules

Miscellaneous

Biome v1.5

New features

Process only the files that were changed

The command biome ci now prints diagnostics in GitHub PRs

A new command biome explain

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

`noFloatingPromises`

`.editorconfig` support

Check `git` staged files

Support for `biome.jsonc`

`extends` resolves dependencies

Option `attributePosition`

With variant `auto` (default)

With variant `multiline`

Option `json.formatter.trailingCommas`

With variant `none` (default)

With variant `all`

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

A new command `biome explain`

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

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

New `biome lint` command

`.jsonc` file support

`extends` property