Biome’s formatter should not support plugins that can modify the code style.
Introducing plugins that can modify the style is analogous to introducing new options, undermining the consistent style.

A quote from the option philosophy

No matter the project, no matter the setup, code formatted by Biome will always look the same.

Does this quote still apply when the code style can be modified with a plugin?

@Liam-Tait, plugins are based on the idea of giving the ability to customize the I/O in almost every library/app that has a plugin system.

I believe that statement will be updated to satisfy the plugin system that has the ability to format the code. Like a disclaimer text 🤔

Sorting tailwind classes https://github.com/tailwindlabs/prettier-plugin-tailwindcss
And formatting HTML files

@FDiskas you probably missed this one: https://biomejs.dev/linter/rules/use-sorted-classes/

@ematipico thank you for your response. I'm glad that there is an solution. Sadly I can't configure it and for me it did not work.
This is probably is not the right place to ask but it could help others to find the solution - I landed here via google
I tried to read the docs - no clear indication how enable this.
My current configuration is

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true,
    "defaultBranch": "develop"
  },
  "organizeImports": {
    "enabled": true
  },
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineEnding": "lf",
    "lineWidth": 120,
    "attributePosition": "auto",
    "bracketSpacing": true
  },
  "linter": {
    "enabled": true
  },
  "javascript": {
    "formatter": {
      "jsxQuoteStyle": "double",
      "quoteProperties": "asNeeded",
      "trailingCommas": "es5",
      "semicolons": "asNeeded",
      "arrowParentheses": "always",
      "bracketSameLine": false,
      "quoteStyle": "single",
      "attributePosition": "auto",
      "bracketSpacing": true
    }
  },
  "overrides": [
    {
      "include": ["*.md"],
      "javascript": {
        "formatter": {
          "trailingCommas": "none",
          "arrowParentheses": "asNeeded"
        }
      },
      "formatter": { "indentStyle": "space", "lineWidth": 80 }
    },
    {
      "include": ["*.{json}"],
      "formatter": { "indentStyle": "space" }
    }
  ]
}

There are missing some documentation on how to enable. Followed a PR for this future, checked comments and finally I found the comment with a configuration example #1362 (comment)

React 19 will support React-Compiler. React-Compiler has new linter rules that go beyond the normal react-eslint Plugin.

The eslint plugin for the React Compiler just invokes the compiler and collects its output. However, the React Compiler is written in TS/JS, so adding it natively to Biome won't happen (see #3 (comment)).

So I think the easiest way for this to happen is JS/TS plugins, which can in turn invoke the React Compiler, just like the ESLint plugin does. This is why I vote for JS/TS interfacing with biome.

We have a few custom rules that we use in a project, we want to enforce certain variable names when you import from our api, so that there is consistency. We also don't want people to call hooks from our api and also grab a property or value on the same line.

i.e. we disallow useApi().data but allow const api = useApi(); console.log(api.data). we find it makes it easier to scan since we are so used to reading this piece of code, and also creates less git diffs. If you are used to seeing const api = useApi(), then const data = useApi().data is not as immediately clear and decreases scan-ability.

We also have a rule that disallows empty objects being passed to our api, instead we enforce undefined. This is because we cast the variables to a string for caching, and if you pass in undefined over here, and an empty object over there, you get different results back.

i.e. we disallow useApi({}) and useApi({}, { someOption: true }). Instead, you must do useApi() and useApi(undefined, { someOption: true }). The signature of this function is like useApi<V, O>(variables: V, options O).

We'd love to move to biome although we'd need to move these custom eslint rules over too.

This is also the idea I was checking out the plugin support for, we have a package wrapping around nestjs and want to make sure developers dont use the @nestjs/* counterpart by providing custom linting messages.

We use a microfrontend and use a custom linting rule to check if the package version in the local repo is different from the remote repository. So some async fetching should be allowed perhaps when the linter first starts to decide a warning should be thrown

The second problem with a non-pure AST is that you don't really know if it's printable. Whenever you make up a program out of an AST to be safe you really need to print it and then parse what you printed, because many printers if not most printers will gladly emit illegal syntax when confronted with subtly incorrect object trees. After all, if they handled all those edge cases, they would just be parsers!

Also how would you know what to disallow? Some code may need to be formatted using unicode escapes in identifiers due to limitations in textual encoding scheme, for example. You can't rely on being able to make a hard and fast rule against unicode escapes, which will occur in more normal places like strings too.

transformation will be very helpful for custom usage (say transforming i18n, custom jsx syntax, or special decorators)
AST based manipulation should be enough for transformation if transformation is not driven by trivias.
e.g. changing a variable name can be as easy as an assignment. there is no need to interact with actual spaces here.

if (node.name === 'longlongname') node.name = 'short'

Exposing CST details may make the transformation conflict with the formatter. CST can be stored somewhere in the data structure since biome needs it for later formatting, but exposing it to plugin users seems to be more complicated and slower than not.

@HerringtonDarkholme How are you suggesting that would be implemented? Would node be a plain JS object, or a facade wrapping a Rust CST node? In other words, does node.name = actually update Biome's tree directly, or will we have to rebuild Biome's tree by some diffing process later?

Would node be a plain JS object, or a facade wrapping a Rust CST node

I would argue it should be a facade (probably a JS proxy) wrapping Rust data structure. Serializing/deserializing a whole tree will be very expensive. A facade can avoid the cost and only deserialize sub-tree. Also see similar issue in oxc-project/oxc#1680

will we have to rebuild Biome's tree by some diffing process later?

Yes

@arendjr @webpro @DaniGuardiola Wondering if anything came out of the talk, would love Knip in Biome

I admit I lost track of this one back then, but I think nowadays Biome has most of the functionality built-in to replicate Knip's features, as discussed here: #6379 (comment)

Maybe @webpro can shed some light on things I may be overlooking in that thread?

To list some features beyond regular static import/export analysis, Knip has plugins (for both static analysis and parse resolved config for all sorts of tooling and frameworks), parses package.json#scripts and other shell scripts to find entry files and dependencies), has built-in and supports custom compilers (for .astro, .vue, etc). Also see https://knip.dev/explanations/why-use-knip and https://knip.dev/reference/faq.

Cool, thanks! Yeah, then we definitely have some work to do still if we want to cover it all. Starting to wonder how hard it would be to integrate such Knip plugins in Biome then 🤔

For those interested, I have also opened an RFC for Biome's files.includes configuration to become more like Knip's: #6983

whether codemod should be a separate topic from transformation mainly depends on the transformation API.
if the API allows one to write one-off transformation without touching config, there is few need for shipping codemod.
However, transformation API should also be integrated enough to the CLI so that transformation API users don't need to traverse code files themselves.
Otherwise, a dedicated codemod API is still valuable.

What is the use case for codemods? Grit is explicitly made for codemods, and is very good at it. Why reimplement that in Biome? The only use case I can imagine is linter error autofix, but if that's covered by the linter API, then I think there's no other use for codemods.

Because there aren't many tools for codmods in the web ecosystem.

Grit might be a good tool, but it's "yet another tool".

Codemod in Grit is general IMHO, i.e. the replaced code is not syntax aware. For instance it has redundant comma in this case. (other tool fails similarly)

If biome wants to be a codmods tool for the web, I really wish it to have syntax-aware fix, like https://github.com/unjs/magicast

Codemods are a combination of primitive abilities to query and transform (you might also say "read and write") code. The idea that any one tool might have a monopoly on literacy is not realistic because literacy is too common a need.

We are already working on this:

• https://biomejs.dev/linter/rules/use-sorted-classes/
• ☂️ Tailwind class sorting lint rule #1274

Similarly Vue attribute sorting would be nice

It would also be great to have this supported in "supersets" of HTML, e.g. template engines.
To me (and probably the whole Symfony Ecosystem) it would be especially helpful if Twig templates will be supported.

Also see #1274 (comment)
There I also linked an example twig-html file: https://github.com/symfony/demo/blob/7169fb500af3be8fdcfb7badb38ac6ed88020882/templates/base.html.twig

We may still support WASM plugins at some point, which could then be written in Rust. But it’s not a focus right now.

Btw, the GritQL plugins we are currently working towards should be very high-performance because it essentially relies on a pattern matching engine that is fully written in Rust. They’ll be less powerful than JS/TS plugins, but when we introduce those the goal is to leverage the same GritQL engine so the plugins themselves only need to implement the logic that cannot be expressed in patterns. The expectation is that this will be plenty fast for the vast majority of use cases.

I don't think your take is that controversial at all, I'm quite aligned with it! :)

The way I see it is that plugins are very much an additional feature for Biome rather than a replacement for the batteries-included approach that we have today. As you point out, native, built-in rules are a core strength of Biome and I think we should keep that approach even when we have plugins. But we also have to remain realistic and know that we cannot fulfill all user requests with a batteries-included approach, so that’s the gap which plugins are supposed to fix IMO.

While I agree with the sentiment here, and the "batteries-included" approach is nice. To keep in the analogy, many users with power powerful uses for a tool will throw away the batteries that were included to use the "better batteries" they need in that same tool.

I don't think the existance of support for customizing Biome will defeat the purpose of idiology of it supporting an opinionated set of included rules/etc. I think the importance of having support for plugins is emphasized by looking around out all the issues and discussions where "x rule" is missing and the number of commentors saying "this is sadly a deal breaker" or a "road block" and forcing them back to their existing eslint tooling, despite the massive performance improvements provided by biome.

In my personal two cents experience, I moved all of our tooling for a major product to Biome to save a ton of time being spent on CI/CD, git hooks, and IDE delay; however, the missing rules/plugins are causing some headaches in enforcing assorted style guidelines. So I am strongly in support of plugin support, nothing says you need to use them, so long as the tooling remains "batteries-included" without them.

I would not like it for Biome to repeat the same story

ESLint's story isn't that bad. It's indeed some pain about the config system, the fragmentation of the plugin ecosystem, etc. But I won't say it's because of the "introduce of plugins", but rather, the historical reason of JavaScript, the language and best practices have evolved so much in the past years since ESLint was created. And actually, the whole point of ESLint to exist is to have an extensible linter interface. IMO, the fact that ESLint supports plugins makes the community able to try so many different approaches/integrations, that have the JS ecosystem we have today, and also the foundation of Biome's builtin rules, as many of those best practices has been battle-tested with ESLint's community rules.

Let's take another example that better shows my point - Vite. From my perspective, without plugins, Vite won't be anything as it today. Vite is rather battery-included, it handles HTML, CSS, TS, Workers, HMR, etc. Out-of-box. While having the plugins allows so many meta-frameworks to build amazing things on top of the great foundations. In that case "I wish Biome to have a similar story" - by having a great plugin ecosystem with a strong community around it that innovates and moves forward together.

I fully support the batteries-included approach of Biome. However, I see two major use cases for plugins:

• Experimenting with some rules in an easily hackable language (e.g. TypeScript) before implementing them in Rust.
  • Enable (orders of magnitudes) faster iteration, especially on low-end hardware on which Rust compilation is unusably slow.
  • Trying out multiple possible versions of a rule, to see which version is the most usable in real projects. It's easier to swap 2 versions of a TS plugin and compare, than to compile 2 versions of Biome to compare (as it would be in the case of a half-baked beta plugin written in Rust).
• Enable development of breaking changes in frameworks. E.g. the Svelte team released Svelte 5 beta several months before it was released as stable version. It introduced new syntax in the markup. A plugin could be made in similar cases to support the upcoming version of the framework, while the batteries-included rules support the stable version. Framework authors often introduce breaking changes, often between two preview versions, so it would introduce additional burden on Biome maintainers to support new features before stabilization, and rewrite them each time upstream is changed.

Comparing JS with Go isn't fair... even if we simplify JS with JS/TS, there is still often a mix of languages within the same file with JSX/Vue/astro..

The JS ecosystem is very dynamic with upcoming frameworks, so I don't expect biome to keep up or catch up with them.

Given that it's not possible (?) to apply a series of formatters in chain, the easier would be to allow for plugins, because easy and quick only fits smaller projects.

I get what you’re saying, and yeah, JavaScript’s ecosystem is a completely different animal compared to Go. The constant mix of "pseudo languages" and paradigms makes it a lot harder to establish any kind of uniformity.

But honestly, that huge mix is also part of the chaos that prevents order from ever prevailing. It’s the trade-off for JS being as dynamic and adaptable as it is—great for innovation, but a nightmare for maintaining consistency.

That said, my concern isn’t so much about expecting Biome to simplify all of JS/TS into Go-like standards. It’s more about the risk of Biome eventually following the path of ESLint—where the simplicity gets chipped away over time, and you end up needing a dozen plugins just to get things working the way you want, and you actually kinda have to semi-constantly think about it.

Go has the advantage of being built with strict, enforced standards from the start—tools like gofmt aren’t even optional; they’re just the norm. In JavaScript, though, there’s no real authority (Node, ECMA, whoever) pushing for that kind of standardization, and frankly, with the way the ecosystem moves, it’s hard to imagine one ever sticking.

I get that JS thrives on its flexibility, and I know it’s unrealistic to expect that same level of order here, but I’d still love to see at least one no-frills, truly streamlined tool that doesn’t spiral into endless configuration and dependencies over time. Maybe it’s wishful thinking, but hey, a little dreaming never hurt!

Knowing that pleasing everyone is impossible, I think the only realistic solution is to create a strong frontend/backend divide, like the web has. The idea is that the backend is language-agnostic and style-agnostic and supports the necessary features for linting like structural queries, parser extension, and language embedding. This allows you to have part of the project (the backend) which you can actually "finish" in the development sense since trends and frameworks and dialects can come and go without the backend needing to be constantly updated and reworked to keep pace.

In terms of this discussion it would also heal the ecosystem fractures that have developed by allowing different backends to work with different frontends. It would not, however, create a consistent "no config necessary" code style.

The strong-frontend-backend proposal was not so much rejected as it was simply not what happened. The current Biome plugin API design is meant to be a thin half-featured layer on top of a thick, full-featured, style-aware core. My understanding is that the JS plugin API under development is intended to be joined later by a second Rust-based plugin API that will be necessary for advanced use cases.

I feel pretty strongly about the frontend/backend thing (I'm a frontend eng by trade) so I have been working by myself on developing an API surface that could serve as a strong, flexible boundary layer, and I still stand ready to serve the Biome project if they should change their mind about the direction they wish to go.