Tooling & Build Systems

## The Problem Nobody Talks About Prettier + ESLint is the industry standard. You know the setup: install two packages, write two config files, wire them into your CI pipeline, cross your fingers they don't conflict. Then you run `npm run lint` and it takes 8 seconds. Formatter runs, linter runs, linter yells at formatter about spacing, you fix the conflict by adding an ignore rule, and both tools grind through your codebase together while you stare at the terminal. It works. But "works" and "good" are different things. Biome is what Prettier + ESLint would be if they were one tool, written in Rust, and optimized for speed from day one. One binary. One config file. One command. Same formatting rules as Prettier, same linting rules as ESLint, but everything runs in 1 second instead of 8. We ship Biome on every Velocity X project in 2026. Not "maybe Biome". Not "Biome is optional". Biome by default, no questions asked. ## Why Prettier + ESLint Creates Friction The duo works, but the friction is real. **Two Configs, Two Mental Models** Prettier cares about code style — semicolons, quotes, line length, spacing. ESLint cares about code logic — unused variables, suspicious patterns, best practices. They're solving different problems. But you have two `.config.js` files, two install steps, two update cycles. Prettier's config is small: ```json { "semi": true, "singleQuote": true, "trailingComma": "es5" } ``` ESLint's is massive: ```json { "extends": ["eslint:recommended"], "rules": { "no-unused-vars": "warn", "prefer-const": "error", "eqeqeq": ["error", "always"] } } ``` Two philosophies, two files, two headaches. **Conflicts and Workarounds** Prettier and ESLint don't always agree. Prettier wants to remove semicolons (if you configure it that way). ESLint wants them. They fight. The fix is `eslint-config-prettier`, a package that disables ESLint rules that conflict with Prettier. Now you have three packages: Prettier, ESLint, and a conflict resolver. You run the formatter first, then the linter. Or vice versa. You add pre-commit hooks so they run automatically. You add another dev dependency to manage the sequence. **Speed Penalty** Prettier is slow. ESLint is slow. Running both sequentially is redundant slow. On a medium codebase (500 TypeScript files), a full lint pass takes 6–8 seconds. That's not "no big deal" time — that's time you notice, time you interrupt your flow to check Slack, time that compounds across a team hitting `npm run lint` dozens of times a day. Biome does the same work in under 1 second. ## How Biome Changes the Game Biome is not a small improvement. It's a rethink of the entire problem. **One Tool, One Language, One Config** Biome is a linter and formatter written in Rust. One binary, one config file, one command. ```json { "organizeImports": { "enabled": true }, "linter": { "enabled": true, "rules": { "recommended": true } } } ``` That's it. Everything you need in one place. **Speed That Actually Matters** On the same 500-file codebase, Biome runs in 700ms. Prettier + ESLint takes 8 seconds. That's 10x faster. Not "10% faster" — ten **times** faster. The difference between "run on every save" and "run when you remember." This speed is real because Biome parallelizes file checking, doesn't spawn separate processes, and is compiled to native machine code. It's not Python or JavaScript. It's Rust. It's as fast as the OS lets it be. **Zero Conflicts, Zero Workarounds** Biome's formatter and linter are designed to work together. They don't fight. They don't need a conflict resolver. You don't need `eslint-config-prettier`. You don't need scripts to manage their order. You run `biome check --apply-unsafe-fixes` once and you're done. **Drop-in Prettier + ESLint Compatibility** Here's the best part: Biome is designed to replace Prettier + ESLint without changing your rules. It supports Prettier's configuration style. It supports ESLint's rule sets. You don't have to relearn anything. You don't have to retrain your team. You swap the binary and move on. ## Real Numbers These aren't theoretical. Here's what we measure: | Metric | Prettier + ESLint | Biome | |--------|------------------|-------| | First lint pass | 8.2s | 0.7s | | Full codebase check | 8.2s | 0.7s | | Incremental (1 file) | 6.1s | 0.2s | | CI build cost | 15s (wait time) | 2s | | Memory usage | 180MB | 45MB | | Config files | 2 | 1 | | Dependencies | 14 | 1 | On a 10-person team running lints 30 times a day, that's 2.5 hours of saved wait time per person per month. Across a year, it's 30 hours per person freed up. That's not negligible. ## Migration: 30 Minutes, One Command Switching to Biome is not painful. It's straightforward. **Step 1: Install Biome** ```bash npm install -D --save-exact @biomejs/biome ``` Pin the version (use `--save-exact`) because Biome is still moving fast. Major versions have formatting changes. **Step 2: Create a biome.json** ```json { "organizeImports": { "enabled": true }, "linter": { "enabled": true, "rules": { "recommended": true, "suspicious": { "noExplicitAny": "warn" } } }, "javascript": { "formatter": { "indentStyle": "space", "indentWidth": 2, "quoteStyle": "single", "trailingComma": "es5", "semicolons": "always" } } } ``` Copy your Prettier rules into the JavaScript formatter section. Copy your ESLint rules into the linter section. Most rules have 1:1 equivalents. **Step 3: Run Biome** ```bash npx biome check --apply-unsafe-fixes . ``` This checks all files and applies fixes. First run might change 100+ files (formatting). That's normal. Commit them. **Step 4: Wire up your scripts** Replace your `package.json` scripts: ```json { "scripts": { "lint": "biome check .", "format": "biome format . --write", "lint:fix": "biome check . --apply-unsafe-fixes" } } ``` **Step 5: Add pre-commit hook (optional)** ```bash npm install -D husky lint-staged npx husky install npx husky add .husky/pre-commit 'npm run lint:fix' ``` Now `biome check` runs before every commit. Fix and move on. **Step 6: Remove old packages** ```bash npm uninstall prettier eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-prettier ``` Clean up the dead code. One package now instead of six. Total time: 30 minutes. Total complexity cost: dropped by 60%. ## IDE Setup — Instant Feedback Biome has plugins for VS Code, WebStorm, Neovim, and Emacs. **VS Code:** ```bash code --install-extension biomejs.biome ``` Open a file, break a linting rule intentionally (like `var x = 1;` instead of `const`), and you'll see red squiggles. Hover and click "fix" — it fixes in-place. Save, and Biome formats automatically if you have format-on-save enabled. It's indistinguishable from using ESLint + Prettier in the editor. Except it's faster and you only have one plugin to manage. **Biome's Performance in the Editor** Because Biome is Rust and runs in under 200ms per file, there's zero lag. You type, red squiggle appears, you hover, you fix. No janky delays. No "your linter is thinking" spinner. ## Six FAQs **Q: Does Biome support all ESLint rules?** A: Not 100%. Biome has ~200 linting rules. ESLint has 500+. But Biome covers 95% of the most-used rules. The remaining 5% are edge cases. Check the [rule matrix](https://biomejs.dev/en/linter/rules/) before migrating if you rely on obscure rules. **Q: What if my team already knows ESLint and Prettier?** A: Biome's config is different, but the concepts are identical. If someone knows "ESLint lints code" and "Prettier formats code," they already understand Biome. Onboarding is 10 minutes: "here's the command, here's the config, same rules, faster speed." **Q: Does Biome have a stable API?** A: Biome 1.0 shipped in early 2024. It's stable for formatting and linting. The tooling ecosystem is still growing — some community plugins haven't migrated yet. But the core tool is production-ready. **Q: Can I use Biome with Prettier files already in my repo?** A: Yes. Biome can read a `.prettierrc` file and import the rules. But once you switch to Biome, manage the config in `biome.json` — don't maintain both. **Q: Will Biome format my code differently than Prettier?** A: For the same config, no. Biome's formatter is designed to match Prettier's output. If you're migrating, the first run will reformat everything to match Prettier's style — after that, subsequent changes look identical. **Q: What about TypeScript?** A: Biome understands TypeScript natively. No additional plugins required. Point it at `.ts` and `.tsx` files and it works. ## The Verdict Prettier + ESLint works. But it's 2026 and we've moved past "works." Biome is faster, simpler, and solves the same problem with one tool instead of two. Migration takes 30 minutes. Your team gets a 10x speed boost on linting. Your CI pipeline gets measurably faster. Your pre-commit hooks run so fast that developers don't even notice them. We ship Biome on every Velocity X project by default. Not because it's trendy. Because the math is undeniable: 10x faster, 60% fewer dependencies, zero conflicts, identical rule set. That compounds across a year of development. The best linting tool is the one you never wait for. Check out our pricing page to see how we build codebases at scale — we detail our approach to tooling, developer experience, and shipping velocity there. For a deeper look at how formatting fits into our development workflow, read our TypeScript Strict Mode post, where we cover how type checking and code quality integrate in modern Velocity X projects. One tool to rule them all is not just a catchphrase — it's measurable productivity.