Skip to content

Biome Core Team

2 posts by Biome Core Team

Announcing Biome

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:

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

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!

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.

Emanuele Stoppa on the stage of JsNation

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.

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.

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.

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.

  1. 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"
    }
  2. And change the CLI name in your scripts:

    {
    "scripts": {
    "format": "rome format --write ./src",
    "format": "biome format --write ./src"
    }
    }
  3. 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"
    }
  4. Then install the new official VSCode or open VSX extension. That’s an important step if you use these extensions.

  5. 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.

  • 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;
  • 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.

Biome v1

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.

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;

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" />;
};

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) => {};

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.

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.

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.

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

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

Biome can now format and lint .jsonc 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!

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.

We deleted two rules:

  • useCamelCase, which is replaced by useNamingConvention;
  • noExtraSemicolon, not needed; the formatter takes care of it;
  • 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.

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
}
}
}

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;