Biome vs ESLint+Prettier: linter mana di 2026

TL;DR

• Biome: Recommended untuk new project. 10-20x lebih cepat dari ESLint+Prettier, single tool, single config.
• ESLint+Prettier: tetap valid untuk legacy project atau project dengan plugin ESLint custom yang Biome belum support.
• Oxc (newer): Watch — masih early, tapi promising untuk replace Biome.

Konteks migration

Saya migrate 4 project saya dari ESLint+Prettier ke Biome di 2025:

1. SaaS klinik dental (Astro + React): migrate sukses, no issue
2. SaaS billing fotograf (Bun + Hono): migrate sukses, save 60-90 detik per CI run
3. Internal tool kontraktor (legacy React + ESLint custom plugin): tetap ESLint karena custom rule
4. Landing page SMB klien: new project, langsung Biome

Performance

Benchmark: lint + format 25K LOC TypeScript codebase.

Tool	Time
ESLint (cold)	12.3s
ESLint (warm cache)	4.8s
Prettier	6.1s
ESLint + Prettier combo	18.4s (cold), 10.9s (warm)
Biome	0.9s (cold), 0.4s (warm)

Biome 10-25x lebih cepat. Untuk CI pipeline yang lint+format sebelum test, ini save signifikan waktu.

Untuk pre-commit hook (husky + lint-staged), Biome lebih instant — developer experience much smoother.

Setup comparison

ESLint + Prettier setup

// package.json
{
  "devDependencies": {
    "eslint": "^9.0.0",
    "@typescript-eslint/parser": "^8.0.0",
    "@typescript-eslint/eslint-plugin": "^8.0.0",
    "eslint-plugin-react": "^7.0.0",
    "eslint-plugin-react-hooks": "^4.0.0",
    "eslint-config-prettier": "^9.0.0",
    "prettier": "^3.0.0"
  }
}

Plus 2 config files (.eslintrc.js, .prettierrc), plus integration config (eslint-config-prettier untuk avoid conflict).

Biome setup

// package.json
{
  "devDependencies": {
    "@biomejs/biome": "^1.9.0"
  }
}

Plus 1 config file (biome.json).

Less dependency. Less config complexity. Less surface area for things to break.

Feature parity

Apa yang Biome cover

• TypeScript / JavaScript parsing + linting
• React / JSX support (rule untuk React-specific patterns)
• Formatting (Prettier-equivalent)
• Import sorting
• Code action (autofix)
• VS Code / Zed integration

Apa yang Biome tidak cover (Mei 2026)

• ESLint plugin custom (e.g., eslint-plugin-jest, eslint-plugin-testing-library)
• Vue.js parsing (in development)
• Svelte parsing (in development)
• Astro file parsing (in development — tapi Astro file mostly TS/JSX, sebagian work)
• Some advanced TypeScript rules (e.g., type-aware linting yang butuh full TS compiler)

Untuk most React/TS project, parity sudah cukup.

Migration steps (untuk project existing)

1. Install Biome: bun add -d @biomejs/biome
2. Init config: bunx biome init → generates biome.json
3. Migrate from ESLint config: bunx biome migrate eslint --write (auto-converts)
4. Migrate from Prettier config: bunx biome migrate prettier --write
5. Test: bunx biome check .
6. Fix issues: bunx biome check --apply .
7. Update package.json scripts:

{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --apply .",
    "format": "biome format --write ."
  }
}

8. Remove ESLint + Prettier: bun remove eslint prettier @typescript-eslint/parser ... (all eslint-related)
9. Update CI: replace eslint + prettier step dengan single biome check step
10. Update VS Code settings (kalau team Anda pakai VS Code):

// .vscode/settings.json
{
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

Total migration time untuk 25K LOC project: 1.5-2.5 jam, including team training.

Rule comparison

Biome punya subset of ESLint rules. Tidak semua ESLint rule available di Biome.

Yang covered dengan baik di Biome:

• no-unused-vars, no-undef, no-console (recommended config)
• React Hooks rules (react-hooks/rules-of-hooks, react-hooks/exhaustive-deps)
• TypeScript-specific rules (no-explicit-any, no-non-null-assertion)
• Accessibility (a11y) — Biome punya subset of eslint-plugin-jsx-a11y

Yang tidak ada di Biome (Mei 2026):

• Complex TypeScript rules yang butuh type information (e.g., strict-boolean-expressions)
• Custom plugin specific (e.g., eslint-plugin-storybook, eslint-plugin-jest)

Untuk most project, Biome ruleset sudah cukup. Kalau Anda heavily depend on specific ESLint plugin, evaluate hati-hati.

Konteks SMB Indonesia

Saya rekomendasi Biome untuk team SMB Indonesia karena:

1. Less DevOps overhead: 1 tool = less config drift, less “kenapa CI fail” debug
2. Faster CI: untuk team Indonesia yang pakai shared GitHub Actions (limited minute), saving 60s per run × 50 PR/bulan = 3000s = 50 menit hemat
3. Easier onboarding: junior dev baru, less config to learn

Yang surprising

Setelah migrate, saya notice bahwa Biome’s recommended config lebih strict dari default ESLint. Saya temukan beberapa bug latent di codebase yang ESLint default tidak catch tapi Biome catch (e.g., unused destructured property).

Pelajaran: migration tools cetak finding awal. Worth alokasi 4-6 jam untuk fix Biome warnings (vs typical “migrate config, semua green” expectation).

Oxc (alternative emerging)

Oxc (https://oxc.rs) adalah JavaScript toolchain di Rust, similar approach dengan Biome.

Mei 2026 status:

• Parser + resolver: production-ready
• Linter (Oxlint): production-ready, faster than Biome
• Formatter (Prettier-compatible): in development
• TypeScript checker: in development

Untuk replace Biome: not yet. Tunggu sampai formatter mature.

Untuk replace ESLint specifically: oxlint sudah viable. Saya test di 1 project, save further 50-70% dari Biome time.

Watch space — Oxc bisa jadi replacement for Biome di 2027.

Verdict

Recommended Biome untuk:

• New project (greenfield)
• Existing project dengan ESLint+Prettier biasa (tanpa custom plugin esoteric)
• Project yang prioritize CI speed
• Team kecil yang prefer single-tool simplicity

Stay with ESLint+Prettier kalau:

• Heavy dependency on specific ESLint plugin (jest, testing-library, storybook)
• Custom ESLint rule unique untuk project Anda
• Team senior yang already adopt full ESLint config + happy with it

Watch Oxc untuk near-future replace.