Что произошло

Экосистема 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 разница глубже. ESLint с @typescript-eslint/recommended грузит весь граф типов — дорого, но надёжно. Biome использует «быстрый путь»: ловит типичные ошибки без полного анализа и работает на полной скорости, но пропускает сложные обобщённые и условные типы. Oxlint умеет полноценную проверку типов через компилятор TypeScript — медленнее «голого» Oxlint в 10–20 раз, но всё равно в разы быстрее классического ESLint.

На практике

1. Инвентаризация — выпишите правила из .eslintrc и отметьте кастомные плагины. Если их больше нуля, Biome откладывается.
2. Пилот на одном пакете — для Oxlint замените eslint . на oxlint в package.json; для Biome сгенерируйте biome.json и удалите дублирующие Prettier/ESLint-зависимости после проверки.
3. CI — Biome даёт одну команду biome ci (формат + линт); с Oxlint нужны отдельные шаги oxlint и prettier --check, которые теоретически могут расходиться.
4. Проекты с активным TypeScript — если обобщённые типы, шаблонные строки и сложные объединения критичны, тестируйте Oxlint с проверкой типов; если TS в основном для подсказок в редакторе, Biome может хватить.
5. Новый код — свежие репозитории без унаследованных плагинов автор рекомендует начинать с Biome, чтобы не плодить два конфига.

Пример минимального biome.json для старта миграции:

{
  "$schema": "https://biomejs.dev/schemas/1.8.0/schema.json",
  "formatter": { "enabled": true, "indentWidth": 2, "lineWidth": 100 },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": { "noUnusedVariables": "error" }
    }
  }
}

Итог

Rust-переписывание инструментария JavaScript — не хайп, а ответ на архитектурный предел среды Node.js в роли парсера синтаксического дерева. Biome и Oxlint не конкурируют напрямую: первый упрощает стек, второй ускоряет привычный ESLint-мир. Перед миграцией ответьте на два вопроса — есть ли кастомные правила и нужна ли полная проверка типов; ответ сузит выбор до одного инструмента.