Migrating a JavaScript Project from Prettier and ESLint to BiomeJS
blog.appsignal.com
blog.appsignal.com
And did we ever need this tool? Prettier and eslint are different beasts, both pretty good, and integrate well together. But again, it's not the tools themselves that are interesting, it's the way Rome was talked about so much without existing. When prettier appeared it was just released: "here is a new tool to format things, it's much faster than what we had before." It then took a long time to permeate and become essential, and it improved along the way, became multi language etc. Prettier is a thing, a tool, it has no mission other than what it does. Rome was an idea without a tool, and it never came to fruition.
You could make some kind of conclusion about this, that oss projects based on grand ideas are doomed, you need code to be released first, to build on and grow. But I don't think that conclusion in itself is that interesting, certainly not novel. What's interesting is why did Rome happen, why did the people behind it drive it in that way? Why did so many get excited by it? It's so very similar to companies that hype themselves stratospherically and often fail. Except at least there is a point to their hype: get investment money and try and use that money to make the hype reality. I don't understand the purpose behind the same thing with Rome. It really itches at me to know more, to understand. To understand why it appealed so much to my peers, it's just linting and formatting, we have that already, and any new tool will start with rough edges. Sometimes you see similar a sort thing with projects and think it's based on aggrandizement of the dev behind it, but those projects peter out quickly. Rome kept it going for years.
Now whenever I read of "upcoming tools" I couldn't care less. Show me the tool and then we can talk. I'm still waiting for the features that Webpack 4 promised a decade ago.
Broadly, you're not wrong. But I see this sort of exceptionalism quite a lot: "<ecosystem> tooling is terrible". Terrible relative to what? I work with tooling across a wide range of languages - some do it better than others but I wouldn't say JS is exceptionally bad relative to others.
E.g. Python tooling has been some of the worst for a long time. Recently Astral have been making positive changes to this (& I note the cross-pollination of Astral & BiomeJS devs) but across the ecosystem things are broadly still terrible on average, especially in fragmentation terms. C/C++ has less of a fragmentation issue & more of a non-adoption-of-anything-standard-at-all issue (Make doesn't count when every Makefile is custom). Java tooling isn't too fragmented as long as you're an IDE user - but it's so locked into UIs & the cli tooling is horrific.
There's problems all over. JS is honestly one of the least worst I've seen.
Replacing prettier and eslint in my projects will typically remove about 5 dependencies. Sometimes up to 10 if you have a lot of specific plugins.
Another amazing benefit is that because Biome is a compiled binary, it can run _without npm install_ which means you can use it in your CI for linting before running any expensive build steps.
Those things save me time.
Looking at the pace of frontend development tooling I cannot help but loose trust and confidence with every step and every new release. Major ecosystem player decides to break all previous compatibility with the vast infrastructure accumulated over the years [1]; the main officially recommended linter released under a major brand goes silently abandoned [2]; etc, etc. I didn't even knew Rome died.
A wise queen once said, "it takes all the running you can do, to keep in the same place" [3]. She meant frontend web development.
[1] https://eslint.org/blog/2023/10/flat-config-rollout-plans/
In other words, instead of creating Jekyll, I created a library that makes it trivial to make your own Jekyll however it makes sense to do so that year.
Common standards are ok, but as soon as you want some small modifications, you will come back to prettier. Performance is not a real problem.
Even as someone who will never write a semicolon myself in Javascript (and still won't), I had to admit that nothing is so important that it's worth straying from zero config.
I recall that migrating an entire company style guide from ESLint to Biome was nearly impossible because it relied on many rules from other ESLint plugins. Writing these rules / plugins ourselves was too much effort. Perhaps someone else has experience with this and can share their insights?
I agree that performance is valuable, especially in token-based development where you push directly to the main branch. Having hooks and builds run on your local machine and experiencing a 30-second speed improvement is nice. However, in the case of migrating an entire company style guide, it might be more cost-effective to simply buy new laptops that can run everything faster.
Nevertheless, I have had very positive experiences with plain TypeScript projects. In such cases, I would do it again. Especially when you have to update from ESLint Version 8 to 9, taking a look at Biome might be a good investment of time.
`useHookAtTopLevel` is especially confusing since other React hook rules are on, and `eslint-plugin-react-hooks` defaults its analogue to "error".
But yeah, no linting in the editor was kinda bonkers.
It's not so much "migrating a javascript project" as it is "marketing material style compare/contrast".
Not touched at all is the actual migration process for any real project. Costs, upsides, problems, headaches, etc.
And ultimately, the sales pitch basically boiled down "it's faster because rust/threads". Which... is fine I guess, but just not all that compelling.
Prettier and ESLint are plenty fast in the sense that they process the file I just saved faster than I can react. Anything else I'm going to push off to CI anyways, where the difference between 10 seconds and 1 second is pretty meaningless.
So speed is great and all, it's just WAY down the list of things I actually care about. Show me the reduced config files after migrating a real project, or the reduced time copying boilerplate for configs. But... it doesn't look that exists based on this article, since it's basically just "ESLint and Prettier configs combined".
Why even show me the discrete lint/format steps if the whole pitch is that the tool combined them? Just show me the check command.
---
As a tool, this looks fine - would love to see a real successor to Rome, including the bundling step.
Otherwise this is a pretty bland & boring marketing pitch.
But what I wanted to comment on actually was eslint and how it nudged me down the path of ESM support. I had to fight and fight to get it to work with my Typescript project. The resolution proposed by the tool was strongly biased towards re-structuring my project away from commonjs modules towards the newer ESM. But when I started down that rabbit hole I found it frustratingly hostile to TypeScript based projects. I was playing whack-a-mole between my package.json, tsconfig, my vite config, my eslint config. Most of it had to do with ts-node and the esm module loader (or something). Eventually it wanted me to rename all of my imports with .js extensions?
In the end I just gave up and went back to commonjs and added strategic "ignores". The modern JS ecosystem has mostly been turn-key, but this was a remembrance of the old days where it felt necessary to wave dead chickens over things to get them to work. I would seriously consider BiomeJS in the (near) future if it's Typescript story was better than what I've experienced with eslint.
And as for ESM, right now it is leaving a really bad taste in my mouth. I will have to dedicate some time soon to figure out how to setup a very basic TypeScript project using ESM and incorporating the basic tools that I require.
The trick is to start fresh and to know the basics:
- use type=module
- import with extensions
- use a sensible shared tsconfig (this is the hard part)
- don't use junk tools like webpack and jest
I used to have that opinion, but now, going through a months long project modernizing our codebase's build tooling, I'm not so sure. Vite isn't so amazing either if you stray away from the happy path (html entry points). I guess no build tool is amazing. At the end of the day, the only thing I can say is all build tools suck. Write less build code if you can get away with it.
Eventually I had to settle on rspack (the spiritual successor to webpack) because vite wouldn't do what I wanted it to do. You could say it was the wrong tool for the job, but it took me a while to figure that out, given how scary it is to not use the frontend build tool. I still wish we could've used it because then we'd be using an industry standard tool.
Getting back to criticizing Vite (sorry have to vent haha) in my experience, vite's API is also built on weird foundations. It exposes rollup and postcss options in it's config, which sometimes do similar things as it's own config options. It generates tons of small chunks with no obvious way to control it without giving up on nice things.
Eventually I did get stuff to work, but in the process I became an expert in a bunch of tools that I never wanted to be an expert in. I just wanted to write my business logic :') It makes me long for Java tooling.
To top it all off, I don't think could've done a better job than the people responsible for this complexity.
> What did we learn from all this?
> I don't know.
> Well I don't know either.
> I guess to not do it again...fuck if I know what we did in the first place
I guess eventually all tools will converge to a de-facto mixed module/commonjs module resolution standard which roughly matches what tsx (the ts-node replacement, not the file extension) does.
Seems like they started with the hard ones and are getting around to the easy ones? Or is linting HTML difficult because of cruft?
Formatting SSCS should be trivial compared to even formatting HTML, which is trivial compared to formatting TS. They took on the principal task first, and did not allow doing the trivial tasks early to inform any implementation decisions, which should be optimized for the hardest and most important task.
Also the core philosophy of prettier is to basically ignore people’s aesthetic preferences about code. Which causes lots of flame wars in the issues.
They really do fix crashes if you submit PRs though. Do you not like contributing to open source but still feel empowered to complain about it? Opening a ticket with a good reproduction case is also contributing but sometimes it’s necessary to put a bit more effort into tools.
const foo = graphql` <some query> `
wont get formatted. In a big graphql codebase (where half the code IS graphql) its totally essential. Very much looking forward to this feature.
Otherwise, Biome has simplified our codebase config dramatically. So dreadful thinking of ESLint, and particularly ESLint 9.
No doubt also thanks to only having a tiny fraction of the feature set.
https://voidzero.dev/ is also working on https://oxc.rs/ sounding nice since I already enjoy vite and it seems to have some funding but I fear it'll end up likewise..
A coworker from another team said they just started fresh and reformatted their project, but I hate the idea.
IMHO moving from one linter/formatter to another without like 90% ease of keeping your config/style is just a bad idea. Then I'll continue living with prettier and eslint...
Now have prettier, eslint and biomejs
Bun is trying, rsbuild is trying and voidzero (i.e. vite and friends) is halfway[0] there. I don't know when any if them will reach there. But at the moment, i don't think biome will reach it before bun, let alone vite.
[0] I know voidzero is much closer, I am referring to this quote: "In a 100 step journey, 90th step is the halfway mark"
It even supports languages like `<script type="module" src="src/Main.elm">` out of the box which is pretty cool.
IIRC it downloads necessarily plugins on the fly.
ESLint introduced a new configuration format a while ago which rendered almost all existing guides online obsolete, and I don't see the benefit for the end users. I assume the devs had a good reason. But god, it's painful.
For example the banned import rule- you can list specific imports to ban, but you can’t configure a pattern. The actual lint rule supports patterns already but biome’s config doesn’t accept a `pattern` property.
For a project I worked on, the main benefit was not having to manage (the 1,000 line haircut to package-lock.json was appreciated) and wire together the ESLint dependencies, and the ones to make it work with TypeScript, and the ones for plugins during our (ok, only my) regular…
npx --yes npm-check-updates --interactive --format group
I've had more issues with the VS Code extension than anything, not picking up config files when you think it should, needing restarted sometimes due to things like the import sorting on save (which to be fair is marked as experimental) completely breaking and producing malformed code near the imports you changed, and just being a bit… complainy if you had projects with and without a biome.json in your workspace.
For me Biome replaced Prettier but its linting capabilities are nowhere near the amount of rules available for eslint. They mention having rules from ts-eslint and unicorn; then you check and it's a handful out of hundreds of rules among the two plugins.
So it's fine if you're using a basic eslint config, but you miss out on a lot of powerful linting otherwise.