Зміст
Коротко
У 2026 році команди масово дивляться на Biome та Oxlint як заміну зв'язці ESLint + Prettier. Обидва інструменти написані на Rust і проходять код у десятки разів швидше. Але «швидше» — не єдиний критерій: у Biome єдина конфігурація форматування й лінтингу, а в Oxlint — сумісність із наявними ESLint-плагінами. Вибір визначає, чи зможете ви зберегти власні правила та повну перевірку типів TypeScript.
Що сталося
Екосистема JavaScript вперлася в стелю продуктивності класичного стеку. ESLint із правилами, прив'язаними до типів, на монорепозиторії в 50 тисяч рядків може працювати 30–60 секунд; Prettier додає ще 5–10. У монорепо з десятками пакетів затримки множаться, і лінтинг стає вузьким місцем перед коммітом і в CI.
Biome (спадкоємець ідеї Rome Tools) об'єднує форматування та лінтинг в одному бінарнику. Понад 200 вбудованих правил покривають коректність, стиль і продуктивність; багато правил із eslint-plugin-react і eslint-plugin-import переносяться без переписування. Критичне обмеження: власні плагіни не підтримуються — якщо у вас внутрішні правила для API, безпеки чи фреймворку, шлях до Biome закритий.
Oxlint — частина проєкту Oxc — робить ставку на швидкість при максимальній сумісності з ESLint. Конфігурація з .eslintrc.json, плагіни @typescript-eslint, react-hooks, import підключаються з мінімальними правками. Форматування лишається на Prettier або аналозі. Парсер Oxc будує синтаксичне дерево один раз, а правила проходять батчами — звідси перевірка стотисячної кодової бази за кілька секунд проти хвилин у ESLint.
Автор порівняння на Dev.to виділяє чотири типові сценарії: команди з внутрішніми плагінами → Oxlint; потрібна повна перевірка з урахуванням типів → Oxlint з увімкненим TypeScript; хочуть один конфіг замість двох → Biome; обережна поетапна міграція → спочатку Oxlint.
Чому це важливо
Коли лінтинг займає секунди, а не хвилини, змінюється щоденна робота: перевірка на кожне збереження в редакторі перестає гальмувати середовище розробки, хуки перед коммітом перестають обходити через --no-verify, CI може паралелити пакети монорепо без очікування серійного ESLint.
Для TypeScript різниця глибша. Biome використовує «швидкий шлях»: ловить типові помилки без повного аналізу, але пропускає складні узагальнені й умовні типи. Oxlint вміє повноцінну перевірку типів через компілятор TypeScript — повільніше «голого» Oxlint у 10–20 разів, але все одно в рази швидше класичного ESLint.
| Критерій | Biome | Oxlint | ESLint (класика) |
|---|---|---|---|
| Швидкість | Дуже висока | Максимальна | Низька на великих кодових базах |
| Форматування | Вбудовано | Окремий інструмент | Prettier окремо |
| Власні плагіни | Ні | Так (сумісність) | Так |
| Перевірка типів | Наближено | Повно (опційно) | Повно |
| Міграція | Переписати конфіг | Мінімальні правки | — |
На практиці
- Інвентаризація — випишіть правила з
.eslintrcі позначте власні плагіни. Якщо їх більше нуля, Biome відкладається. - Пілот на одному пакеті — для Oxlint замініть
eslint .наoxlintуpackage.json; для Biome згенеруйтеbiome.jsonі видаліть дубльовані Prettier/ESLint-залежності після перевірки. - CI — Biome дає одну команду
biome ci(формат + лінт); з Oxlint потрібні окремі крокиoxlintіprettier --check. - Проєкти з активним TypeScript — якщо узагальнені типи й складні об'єднання критичні, тестуйте Oxlint з перевіркою типів; якщо TS переважно для підказок у редакторі, Biome може вистачити.
- Новий репозиторій — без унаследованих плагінів автор рекомендує починати з Biome.
Підсумок
Rust-переписування інструментарію JavaScript — відповідь на архітектурну межу середовища Node.js як парсера синтаксичного дерева. Biome і Oxlint не конкурують напряму: перший спрощує стек, другий прискорює звичний ESLint-світ. Перед міграцією відповідайте на два питання — чи є власні правила і чи потрібна повна перевірка типів.