I think it depends on how overboard you go on the ESLint + plugins config than anything.
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
…sessions. Migrating was just switch the dependencies and keep adding rules you do/don't care about to biome.json until you can live with it, but we didn't go that mad with the ESLint config prior to that.
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.
I say don't believe the hype, unless you just need the basics.
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.
We have the editor plugin configured so we can see lints in-editor. But the rules are not yet sufficiently configurable for us to use it in CI. It seems they have their own rule-config schema, and it doesn’t expose everything you might need.
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.
insin|9 months ago
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…
…sessions. Migrating was just switch the dependencies and keep adding rules you do/don't care about to biome.json until you can live with it, but we didn't go that mad with the ESLint config prior to that.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.
sureIy|9 months ago
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.
draw_down|9 months ago
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.