Oxc

Альфа JS-плагинов Oxlint


JavaScript-плагины для Oxlint вышли в альфу — мы ожидаем, что около 80% пользователей ESLint смогут перейти на Oxlint без сюрпризов.

В Oxlint уже более 650 популярных правил на Rust с нативной скоростью. JS-плагины закрывают пробелы: ESLint-совместимый API, запуск существующих плагинов ESLint и свои правила — всё внутри Oxlint. Для большинства правил — нативная производительность, для остального — полная гибкость.

С первого технического превью в прошлом году мы почти полностью закрыли API плагинов ESLint, добавили поддержку TypeScript-плагинов, автоисправления, интеграцию с IDE и крупный прирост производительности.

Значит многие команды могут заменить ESLint на Oxlint без переписывания правил.

Эта альфа — точка, где мы считаем JS-плагины готовыми к внедрению в реальных проектах.

Большинство проектов смогут использовать Oxlint как прямую замену ESLint с простой миграцией и сильным сокращением времени линтинга.

Возможности ​

  • Запуск большинства существующих плагинов ESLint без изменений.
  • Свои правила на JavaScript или TypeScript.
  • Автоисправления и предложения из правил JS-плагинов.
  • Диагностики JS-плагинов в IDE через language server.

Насколько это надёжно? ​

Поддержка JS-плагинов Oxlint проверяется полным набором тестов самого ESLint и широким набором плагинов:

PluginTestsPass rate
ESLint built-in rules33,006100%
React hooks (including React Compiler rules)5,007100%
ESLint Stylistic18,31099.99%
Testing Library17,016100%
SonarJS3,95199.6%*
e18e474100%*

* кроме типозависимых правил

Если плагина нет в списке, он с высокой вероятностью всё равно работает — просто его ещё нет в нашем conformance suite.

Собственные тесты ESLint покрывают весь API; 100% pass даёт уверенность в краевых случаях и happy path. Попробуйте и расскажите!

Oxlint уже в продакшене у многих компаний и проектов, включая Midjourney, Preact, Posthog, Outline и Actual.

Чего пока нет ​

  • Ограниченная поддержка кастомных форматов фронтенд-фреймворков (Svelte, Vue, Angular) — позже в этом году.
  • Нет своих типозависимых правил в JS-плагинах (правила TypeScript-ESLint уже встроены в Oxlint через типозависимый линтинг).
  • На Windows опыт может быть хуже. OOM — известная проблема, в работе. Пока рекомендуем WSL при возможности.

Прогресс — в tracking issue.

Начало работы ​

Установите oxlint как dev-зависимость:

sh
pnpm add -D oxlint

Добавьте скрипт в package.json:

package.json
json
{
  "scripts": {
    "lint": "oxlint"
  }
}

Создайте конфиг (или воспользуйтесь инструментом миграции):

.oxlintrc.json
json
{
  "jsPlugins": ["eslint-plugin-testing-library"],
  "rules": {
    "testing-library/no-render-in-lifecycle": "error"
  }
}

Запуск линтинга:

sh
pnpm run lint

Миграция с ESLint ​

Для большинства проектов миграция проста.

Самый короткий путь — @oxlint/migrate:

sh
npx @oxlint/migrate eslint.config.js

Или попросите агента использовать скилл migrate-oxlint.

Подробнее — руководство по миграции.

Правила ESLint ​

Oxlint уже нативно реализует большую часть встроенных правил ESLint на Rust, но не все.

Чтобы закрыть этот разрыв, есть oxlint-plugin-eslint — все встроенные правила ESLint как JS-плагин Oxlint.

Так доступны правила вроде no-restricted-syntax, ещё не перенесённые нативно:

.oxlintrc.json
jsonc
{
  "jsPlugins": ["oxlint-plugin-eslint"],
  "rules": {
    // Note: "eslint-js" not "eslint"
    "eslint-js/no-restricted-syntax": [
      "error",
      {
        "selector": "ThrowStatement > CallExpression[callee.name=/Error$/]",
        "message": "Use `new` keyword when throwing an `Error`.",
      },
    ],
  },
}

Oxlint также нативно реализует подмножество правил плагинов вроде eslint-plugin-jsdoc. Для остальных можно подключать сам eslint-plugin-jsdoc. Рекомендуемый паттерн:

.oxlintrc.json
jsonc
{
  "jsPlugins": [
    // Set up an alias for the plugin "jsdoc-js"
    { "name": "jsdoc-js", "specifier": "eslint-plugin-jsdoc" },
  ],
  "rules": {
    // Use the alias to refer to rules from the plugin
    "jsdoc-js/check-examples": "error",
    "jsdoc-js/require-description": "error",
    // Use plain "jsdoc" for rules which Oxlint implements natively
    "jsdoc/require-property-name": "error",
    "jsdoc/require-property-description": "error",
  },
}

Performance ​

С первого превью мы «оставили на Rust» большие части кода JS-плагинов — заметный прирост скорости. В частности плагины на token API (например ESLint Stylistic) до ~5 раз быстрее.

В качестве бенчмарка мы мигрировали репозиторий Node.js с ESLint на Oxlint. Node.js — большой проект со множеством своих правил и тяжёлых плагинов ESLint (98 JS-правил всего).

LinterВремяSpeed-up
ESLint1 minute, 43 seconds
Oxlint21 seconds4.8x
Details

INFO

  • Benchmark repo

  • 6298 файлов

  • 104 встроенных правила Oxlint (Rust)

  • 75 правил из JS-плагинов (JS)

  • 23 кастомных правила (JS)

  • Mac Mini M4, 48 ГБ RAM, Node.js 24.14.0

  • ESLint:

sh
git checkout bench-eslint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run eslint"
  • Oxlint:
sh
git checkout bench-oxlint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run oxlint"

Проекты на TypeScript-ESLint или eslint-plugin-import часто получат намного больший выигрыш. Участник Discord сообщил об ускорении ~16× на кодовой базе компании ~2 млн строк при переходе с ESLint на Oxlint с активным использованием JS-плагинов. При редком использовании JS-плагинов сообщали до ~100×.

Дальнейшие улучшения производительности ​

Это только начало!

Oxlint с JS-плагинами уже существенно быстрее ESLint, но впереди ещё много оптимизаций.

Ключ — новый низкоуровневый механизм связи Rust и JS, который мы называем «raw transfer».

Граница Rust/JS всегда была главной проблемой нативных инструментов с JS-плагинами. Нативный код быстр, но передача данных туда-обратно может съесть выигрыш.

Raw transfer почти убирает стоимость передачи данных и позволяет совместить нативный код и JS-плагины.

Первая итерация raw transfer уже работает под капотом, но возможности использованы лишь частично. Дальше ожидаем новый скачок производительности и приближение JS-плагинов к скорости Rust.

Подробнее — доклад участника core @overlookmotel на ViteConf 2025.

Кратко: Oxlint уже самый быстрый JS/TS-линтер. Станет ещё быстрее.

Совет по производительности 1: используйте форматтер ​

Настоятельно рекомендуем перенести форматирование кода с линтера на Oxfmt (или другой форматтер).

Oxfmt примерно в 30 раз быстрее Prettier и сильно сокращает время линтинга по сравнению с плагинами вроде ESLint Stylistic.

Oxlint и Oxfmt отлично дополняют друг друга!

Совет по производительности 2: выбирайте плагины осознанно ​

Вполне возможно писать очень быстрый JavaScript. Oxlint быстр не только из‑за Rust — он спроектирован с упором на производительность.

Код JS-плагинов мы не контролируем. Хорошая общая скорость Oxlint требует и производительных плагинов.

Неэффективные алгоритмы или частые операции ФС будут медленными и в ESLint, и в Oxlint. Oxlint даёт быстрый парсер и эффективные API — но медленный JS сам по себе не ускорить.

В будущем дадим утилиту, чтобы находить узкие места среди плагинов/правил.

Создание своих плагинов ​

Если нужны особые правила — создать JS-плагин для Oxlint просто.

См. руководство по JS-плагинам.

FAQ ​

Oxlint запускает плагины ESLint? Да. Большинство работает без изменений.

Oxlint быстрее ESLint? Да. Бенчмарки обычно показывают ускорение порядка 4×–100×.

Можно ли мигрировать постепенно? Да. Oxlint можно запускать параллельно с ESLint.

Благодарности ​

Эту веху создавало много людей. Особенно:

  • @Sysix за интеграцию language server.
  • @lilnasy за развитие API.

Сообщество ​

Нам интересен ваш опыт с JS-плагинами Oxlint.

Контакты:

© 2026 VoidZero Inc. and Oxc contributors.