Надоело жонглировать конфигами ESLint и Prettier? Пора познакомиться с Biome — инструментом на Rust, который делает работу обоих за раз и при этом быстрее в разы. Мы разберёмся, как мигрировать проект без боли и почему это вообще имеет смысл в 2026.

Если ты когда-нибудь настраивал ESLint и Prettier вместе, то знаешь эту боль: два парсера, два AST-дерева, два конфига, две игнор-папки. Биоме всё это убирает одним выстрелом.

Почему Biome, а не привычная парочка?

Давайте честно: ESLint и Prettier — хорошие инструменты, но они работают отдельно. Когда ты запускаешь оба, происходит вот что: ESLint парсит файл, создаёт AST, гоняет правила, выдаёт ошибки. Потом Prettier парсит тот же файл снова, создаёт свой AST и переформатирует код. Это неэффективно.

Biome работает по-другому: один парсер, один движок на Rust, одна конфигурация. Результат? Скорость выше, конфигов меньше, багов меньше. Плюс, всё это встроено в один npm-пакет — не нужно отдельно ставить eslint, @typescript-eslint/parser, eslint-plugin-react и ещё сотню зависимостей.

Есть и практический плюс: единый файл конфигурации вместо .eslintrc.json, .eslintignore, .prettierrc и .prettierignore. До миграции можно иметь 40 строк в конфиге; после — 29. Это не просто цифра, это реальное упрощение проекта.

Миграция: пошагово без святогерманий

Биоме не просто заявляет о замене — он реально помогает перейти. В CLI встроена команда biome migrate eslint, которая считывает твой .eslintrc и автоматически конвертирует правила в эквиваленты Biome. Это работает с новыми и старыми форматами конфигов.

Процесс примерно такой: запускаешь миграцию, Biome переносит настройки, потом ты проверяешь результат и при нужде подредактируешь. Команда biome migrate prettier делает то же самое для форматера.

Важный момент: Biome может не 100% повторить поведение ESLint, потому что разработчики сознательно не реализовали некоторые опции или слегка отклонились от оригинала. Но на практике это почти никогда не вызывает проблем — разница появляется в очень специфичных случаях.

Пошаговый план миграции:

1. Оцени текущий сетап: какие плагины ESLint ты используешь (react, import, etc.), есть ли кастомные правила, какие переопределения в Prettier.
2. Установи Biome: npm install --save-dev @biomejs/biome.
3. Запусти автоматическую миграцию: npx biome migrate eslint --write и npx biome migrate prettier --write.
4. Проверь сгенерированный biome.json — может понадобиться убрать дублирующиеся правила или добавить специфичные для твоего проекта.
5. Запусти проверку: npx biome check . и сравни результаты со старым линтером.
6. Если всё окей, удали старые зависимости и конфиги: npm uninstall eslint prettier @typescript-eslint/parser и так далее.
7. Обнови pre-commit хуки, если они есть, чтобы использовали Biome вместо отдельных инструментов.

Что внутри: архитектура Biome

Biome состоит из трёх основных частей, которые работают вместе как одна система. Linter ловит баги, проблемы с качеством кода, нарушения best practices. Formatter приводит код в порядок — отступы, скобки, точки с запятой, всё как надо. Organizer сортирует импорты и убирает мусор.

Всё это написано на Rust, что объясняет скорость. Biome обрабатывает файлы параллельно, кэширует результаты и вообще делает то, что Node.js-версия ESLint+Prettier никогда не сможет делать так эффективно. Плюс, v2 добавила HTML-форматер — теперь ты можешь линтить и форматить не только JS/TS, но и разметку.

К 2026 году Biome уже поддерживает:

• JavaScript и TypeScript (с полной поддержкой синтаксиса).
• JSON, JSONC, TOML (включая package.json).
• HTML и JSX/TSX.
• CSS и CSS-in-JS конструкции (встроено в v2).
• Организацию импортов по правилам.

Конфигурация при этом минималистична. Вот базовый пример для типичного проекта:

{
  "vcs": { "enabled": true, "clientKind": "git" },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "lineWidth": 120
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "semicolons": "always",
      "quoteStyle": "single"
    }
  }
}

Вот и всё. Никаких extends, никаких плагинов — всё, что нужно, уже включено.

Node.js 24 и экосистема: как это вписывается

Biome стал частью большего тренда: в 2026 году экосистема JavaScript/TypeScript активно переходит на Rust-инструменты. Bun уже готовится заменить Node.js (хотя это долгая история), и Biome идёт в том же направлении — переписывает классические Node.js-tools более эффективно.

Для Node.js 24 это хорошая новость: ты получаешь инструмент, который не утяжеляет твой проект тоннами зависимостей, работает быстро, и при этом не требует специальной настройки для работы с современными фичами (async/await, top-level await, приватные поля в классах и так далее).

Migration path в экосистеме тоже облегчен: если ты уже используешь Bun, Biome интегрируется без проблем. Если ты на Node.js, то Biome работает через обычный npm и совместим со всеми стандартными workflow’ами.

Совместимость Biome с популярными инструментами:

• VS Code: расширение работает оттуб, интеграция в редактор как с ESLint и Prettier.
• Git hooks: можно использовать в pre-commit (через husky или аналоги).
• CI/CD: встраивается в любой pipeline — GitHub Actions, GitLab CI, Jenkins.
• IDE: PhpStorm, WebStorm и другие JetBrains поддерживают LSP, что даёт интеграцию с Biome.

Ловушки при миграции и как их избежать

Хотя Biome старается быть полностью совместим, есть несколько моментов, о которых стоит знать до того, как ты начнёшь. Во-первых, YAML-конфиги не поддерживаются — если твой .eslintrc написан в YAML, придётся переделать в JSON. JavaScript-конфиги тоже требуют Node.js для загрузки, так что убедись, что у тебя он установлен.

Во-вторых, при миграции Biome по умолчанию не трогает правила, которые вдохновлены ESLint, но не идентичны. Если ты хочешь включить их все, нужна флаг --include-inspired. Звучит странно, но на практике это означает, что ты получишь точное совпадение поведения только для основных правил, остальное придётся проверить вручную.

Третий момент — Next.js. Иногда миграция падает с ошибкой про то, что Node.js не смог разрешить модуль. Это происходит, потому что Next.js может переопределять пути импортов. Решение: не полагайся полностью на автоматическую миграцию, проверь конфиг вручную.

Чек-лист перед удалением старых инструментов:

• Запусти npx biome check . на весь проект и убедись, что все файлы обрабатываются без ошибок.
• Сравни вывод Biome с результатами старого ESLint по нескольким файлам.
• Обнови скрипты в package.json: замени eslint . и prettier . на biome check . или biome format ..
• Если есть игнор-файлы, проверь, что VCS-интеграция в biome.json включена (опция vcs.enabled: true).
• Тестируй в отдельной ветке перед тем, как мерджить в main.

Итоги: стоит ли оно того

В 2026 году Biome уже не экспериментальный проект — это зрелый инструмент, который используют серьёзные компании. Если тебе надоел мусор из конфигов и хочется ускорить локальную разработку и CI/CD, миграция — это разумный выбор. Потеря совместимости с 100% поведением ESLint — это совсем небольшая цена за экономию конфигурации, скорость и удобство.

Сложность миграции переоценена: в большинстве случаев можно просто запустить автоматические команды и дальше работать. Если у тебя нестандартный сетап или кастомные правила, потребуется больше внимания, но это всё равно быстрее, чем лезть в дебри ESLint-плагинов. И помни: Biome всё ещё активно развивается, так что возможности будут только расширяться.