biome VS typescript-eslint

{ "$schema": "https://biomejs.dev/schemas/1.7.0/schema.json", "organizeImports": { "enabled": true }, "files": { "ignore": ["package.json", "package-lock.json"] }, "linter": { "enabled": true, "rules": { "recommended": true, "style": { "noUnusedTemplateLiteral": "off" } } }, "formatter": { "indentStyle": "space", "indentWidth": 4, "lineWidth": 320 }, "javascript": { "formatter": { "semicolons": "asNeeded" } } }

It is great to see that so many users are enthusiastic about Biome. It is really gratifying to work on a project that is appreciated and useful to the community.

[0] https://biomejs.dev/

Once you build a simple Vite backend integration, try not to complicate Vite's configuration unless you absolutely must. Vite has become one of the most popular bundlers in the frontend space, but it wasn't the first and it certainly won't be the last. In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.

> My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)

Ruff is based on the same foundations that Biome (https://biomejs.dev/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.

I am also confused by this goal, I've started a discussion in the repo to get some clarity on intent and direction there: https://github.com/biomejs/biome/discussions/1642

Biome [0], a fast Prettier-compatible formatter, is currently working on adding class sorting [1]. We expect to ship the feature with the next release (on February). We are discussing which options to provide for the feature (mainly on the Discord of Biome).

[0] https://biomejs.dev/

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):