Oxlint: миграция с ESLint для 10x ускорения линтинга

[hannadev]

Введение

ESLint годами был стандартом для линтинга JavaScript, но на больших проектах его скорость становится просто болью. Oxlint — это переписанный на Rust линтер, который обещает ускорение в 50-100 раз. Звучит как сказка, но цифры реальны: проекты с миллионами строк кода видят 16x спидап в боевых условиях.

Сейчас, в марте 2026, Oxlint вышел из экспериментальной стадии и готов к серьёзным проектам. Если твоя сборка падает из-за линтинга в CI/CD, если Node.js проект растёт и лицо зависает на npm run lint, — это точно твоя история.

Почему Oxlint быстрее: архитектура имеет значение

Всё просто: ESLint работает на JavaScript, Oxlint — на Rust. Разница в том, что Rust компилируется в машинный код и не требует runtime интерпретации. Это означает, что линтер может параллельно обрабатывать файлы, использовать многопоточность и вообще держать себя в руках.

Но есть ещё один киллер-момент: Rust/JS граница. Когда Oxlint обменивается данными между Rust и JavaScript плагинами, команда разработчиков изобрела механизм под названием “raw transfer”. Это позволяет передавать огромные объёмы AST-данных без накладных расходов. Плагины, которые работают с токенами (например, ESLint Stylistic), теперь работают до 5 раз быстрее, чем в экспериментальной версии.

Кроме того, Oxlint работает как единый бинарник. Не нужно Node.js, не нужно npm — просто распаковал и запустил. В CI/CD это экономит минуты просто на инициализацию.

Реальные цифры:

• На репо с 4800 файлами: 0.7 секунд вместо 30-50 секунд
• Проект с 2 млн строк кода: 16x спидап с heavy плагинами
• Без плагинов: 50-100x в сравнении
• ESLint-плагины на токенах: 5x быстрее после оптимизации

Что Oxlint предлагает прямо сейчас

Оxlint не просто быстрый пустой линтер — в нём 695+ встроенных правил. Это охватывает ESLint core, TypeScript (включая type-aware rules), React, Jest, Vitest, импорты, Unicorn и jsx-a11y. Другими словами, большинство инструментов, которые ты используешь в своём стеке, уже поддерживаются.

Zero-config по умолчанию — Oxlint включает 99 правил из коробки. Не нужно писать конфиги на 100 строк; просто запустил и получил базовую проверку. Если тебе нужны свои правила, можно писать плагины на JavaScript или Rust.

VS Code, IntelliJ, Zed — все популярные редакторы поддерживают Oxlint. IDE-интеграция включает диагностику и quick-fixes прямо в коде, как в ESLint.

Основные возможности:

• 695+ правил против 200+ core-правил ESLint
• Native TypeScript без @typescript-eslint (хотя type-aware всё ещё в preview)
• JavaScript плагины — совместимость с ESLint v9+ API
• Auto-fix работает из коробки
• Многопоточность — параллельная обработка файлов
• Multi-file анализ — импортные циклы и связанные ошибки видны сразу

Как мигрировать: от теории к практике

Миграция Oxlint спроектирована, чтобы не ломать систему. Есть несколько стратегий в зависимости от того, насколько komplicated твой текущий setup.

Самый простой случай: ты на ESLint v9 с flat config. Команда одна:

npx @oxlint/migrate --js-plugins

Инструмент проанализирует твой eslint.config.js, переведёт все правила в .oxlintrc.json и скажет, какие плагины нужны. На 80% проектов это работает без доделок.

Если у тебя старый ESLint v8 или используются file-based конфиги, сначала обнови конфиг ESLint:

npx @eslint/migrate-config

Потом уже гонишь через @oxlint/migrate.

Если боишься ломать CI, есть гибридный подход: запускаешь Oxlint рядом с ESLint, отключаешь перекрывающиеся правила через eslint-plugin-oxlint. CI будет быстрым, а ты параллельно разбираешься, все ли правила корректно переехали.

Пошаговый путь миграции:

1. Убедись, что на ESLint v9 с flat config (или обнови)
2. Запусти npx @oxlint/migrate --js-plugins в корень проекта
3. Проверь сгенерированный .oxlintrc.json — там должны быть все твои правила
4. Запусти Oxlint локально: oxlint . (если установлен глобально) или через npx
5. Убедись, что нет новых ошибок или false-positives
6. Добавь Oxlint в CI вместо ESLint
7. Если всё OK, удали ESLint из зависимостей

Когда стоит и не стоит мигрировать

Oxlint кажется панацеей, но есть сценарии, где ESLint остаётся оправданнее. Выбор зависит от состояния проекта и требований.

Мигрировать на Oxlint стоит, если:

• CI падает из-за линтинга на больших монорепозиториях
• Проект использует базовый стек (React, Node.js, TypeScript) без экзотики
• Type-aware rules не критичны (или ты готов использовать preview)
• Хочешь урезать время сборки в half или меньше
• Не привязан к специфичным ESLint плагинам

Оставить ESLint лучше, если:

• Используются Next.js, Nuxt или другие фреймворки с собственными плагинами
• На проекте jsx-a11y для A11y-checks
• Кастомные ESLint правила в …/eslint-plugin-something и их переносить лень
• Type-aware rules — критична безопасность кода
• Монорепо с разными фреймворками в разных папках (нужна гибкость конфигов)

Есть также компромисс: запусти Oxlint как pre-pass в CI. Он отловит базовые ошибки за секунды, а потом ESLint проверит type-aware правила. Это даёт ускорение без полной миграции.

Экосистема плагинов: что поддерживается

Оxlint в марте 2026 вышел с alpha поддержкой JavaScript плагинов. Это значит, что почти все ESLint плагины работают из коробки — благодаря совместимости API с ESLint v9+.

Отсутствующая поддержка:

• Плагины, которые полагаются на custom парсеры (не совместимые с ESLint v9)
• Плагины со своими Node.js runtime зависимостями
• Плагины, импортирующие другие плагины из локальных путей (на этапе migration)

Но даже при таких ограничениях большинство проектов мигрируют без переписывания кастомных правил.

Популярные плагины, которые работают:

• @typescript-eslint (type-aware в preview)
• eslint-plugin-react и react-hooks
• eslint-plugin-jest, eslint-plugin-vitest
• eslint-plugin-import
• eslint-plugin-unicorn
• eslint-plugin-jsx-a11y
• Custom JS плагины (при условии совместимости)

Производительность в контексте 2026

В 2026 году сообщество JavaScript движется в сторону Rust-based инструментов. TypeScript переписывается на Go, форматер Oxfmt набирает скорость. Oxlint встраивается в этот тренд.

Анализируя текущее состояние, ясно: если ты не на экзотическом стеке, мигрировать стоит. Спидап не только экономит CI минуты, но и улучшает developer experience — локальный линтинг не зависает редактор.

Для больших проектов выигрыш очевиден: 16x спидап на 2 млн строк кода — это не шутка. Даже маленькие проекты видят 5-10x ускорение, потому что Oxlint просто лучше распределяет работу.

Что дальше в roadmap: Oxlint обещает ещё больше оптимизаций в Rust/JS boundary. Type-aware rules должны выйти из preview. Может быть, появится поддержка более экзотических плагинов.

Что остаётся за кадром

Oxlint — отличный инструмент, но это не серебряная пуля. Миграция требует проверки на твоём специфичном проекте, особенно если там кастомные правила или нестандартный стек. Type-aware линтинг всё ещё в experimental стадии, поэтому для safety-critical приложений может потребоваться ESLint на параллели.

Но если ты хочешь ускорить сборку и не боишься небольших доделок, Oxlint уже готов к боевому использованию. Огромное количество real-world проектов (включая Node.js сам по себе) уже мигрировали без драмы. (пробуй) его на side-проекте или feature-ветке — и сам увидишь, стоит ли переезжать полностью.