Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Недавно стал общедоступен новый линтер Oxlint, основанный на языке программирования Rust, и многие эксперты высоко оценили его. Какие преимущества Oxlint предоставляет по сравнению со своим предшественником ESLint?

Компилятор Oxc

Компилятор JavaScript Oxidation (Oxc) — это набор высокопроизводительных инструментов для языка JavaScript, написанных на Rust. Акцент сделан на создании основных инструментов компилятора для JavaScript: парсера, линтера, форматтера, транспилятора, минификатора и преобразователя.

Парсер демонстрирует в два раза более высокую скорость по сравнению с парсером swc в рамках тестирования, которое включает анализ файлов .js(x) и .ts(x). Он успешно проходит все тесты парсера Test262 и практически все тесты, используемые в Babel и TypeScript.

Для резолвера все параметры настроены в соответствии с webpack/enhanced-resolve. Эффективность в 28 раз выше, чем у webpack/enhanced-resolve при проведении соответствующего теста.

Node v18.17.1
┌─────────┬────────────────────┬────────────┬─────────┐
│ (index) │        name        │    mean    │ compare │
├─────────┼────────────────────┼────────────┼─────────┤
│    0    │ 'enhanced-resolve' │ '0.3553ms' │ '28.01' │
│    1    │   'oxc-resolver'   │ '0.0127ms' │ '1.00'  │
└─────────┴────────────────────┴────────────┴─────────┘

Сравнение Oxlint и ESLint

Производительность Oxlint стала объектом оживлённых обсуждений в сообществе из-за её впечатляющей эффективности.

Отзывы

Конечно, помимо высокой производительности Oxlint обладает множеством особенностей, которые отличают его от старшего аналога — ESLint. В дальнейшем мы немного сравним его с Oxlint. ESLint (ECMAScript Lint) — это инструмент для статического анализа кода на JavaScript. Его история началась в 2013 году, когда Николас С. Закас (Nicholas C. Zakas) создал проект по созданию гибкого и настраиваемого линтера для JavaScript, который может быть легко интегрирован в различные проекты. В некоторых случаях использование ESLint может повлечь за собой увеличение времени компиляции и замедление работы IDE, особенно при обработке больших проектов. Это связано с интенсивным статическим анализом кода.

Конфигурирование новых кодовых баз на JavaScript/TypeScript становится всё более сложным процессом. Возникает высокий риск несовместимости между используемыми инструментами, что может удлинить настройку проекта. По этой причине был создан Oxlint которому не нужна предварительная настройка; даже использование Node.js не является обязательным условием. Большинство настроек можно выполнить через командную строку. Oxlint по умолчанию обнаруживает ошибочный, избыточный или запутанный код, отдавая приоритет корректности перед избыточными правилами (помеченными как perf, suspicious, pedantic или style), которые по умолчанию отключены.

Производительность Oxlint превышает производительность ESLint в 50-100 раз с возможностью масштабирования в зависимости от количества ядер процессора (тест). Это обусловлено тем, что Oxlint был специально создан с использованием Rust и параллельной обработки в качестве ключевых элементов повышения эффективности.

Oxlint содержит более 200 правил, включая правила из ESLint, TypeScript, eslint-plugin-react и .eslint-plugin-jest, eslint-plugin-unicorn, eslint-plugin-jsx-a11y. Список постоянно растёт. Линтер поддерживает файл .eslintignore и предоставляет функцию отключения правил с использованием комментариев ESLint.

Для тестирования Oxlint в вашем проекте на JavaScript/TypeScript выполните следующую команду в корневой директории вашего репозитория:

$ npx oxlint@latest

Чтение сообщений линтера может оказаться нетривиальной задачей. Oxlint стремится упростить эту задачу, выявляя основные причины и предоставляя полезные сообщения, устраняя необходимость длительного чтения документации по правилам и экономя драгоценное время.

Кроме достоинств у Oxlint также есть свои недостатки.

Недостатки Oxlint

В настоящее время Oxlint не является полноценной заменой ESLint; его роль заключается в улучшении, когда низкая производительность ESLint становится узким местом в вашем рабочем процессе.

На текущий момент Oxlint ещё не имеет системы плагинов, однако в дальнейшем обещают добавить правила из известных плагинов, таких как TypeScript, React, Jest, Unicorn, JSX-a11y и Import.

Вывод

Oxlint представляет собой значительный шаг вперёд в области статического анализа кода на JavaScript/TypeScript. Несмотря на ряд преимуществ, включая высокую производительность и активное внедрение правил из популярных плагинов, стоит учитывать, что у Oxlint также есть свои ограничения и недостатки.

Эффективное использование Oxlint зависит от особенностей проекта и индивидуальных потребностей разработчиков. Я рекомендую внимательно оценить преимущества и недостатки инструмента в контексте конкретного проекта, прежде чем принимать решение о его использовании.

Благодарю вас за внимание и интерес к статье! Надеюсь, что она была для вас полезной и информативной. Если у вас есть какие-либо вопросы или комментарии, не стесняйтесь поделиться ими. Ваше внимание и время ценны для меня. Спасибо за прочтение!

Комментарии (15)


  1. evgeniyrru
    27.12.2023 08:12
    +7

    А давайте на Rust перепишем вообще ВСЁ!



    1. Akuma
      27.12.2023 08:12
      +2

      Просто на Ноду уже переписали. Теперь из-за того, что переписанное второй раз слишком медленно проверяет переписанное в первый, требуется переписать все на Раст/Го.

      И, должен заметить, все действительно становится быстрее :) Хаос в веб-разработке в том числе.


  1. aleks_raiden
    27.12.2023 08:12
    +1

    Штука интересная. Подскажите, а он конфигурацию для литна понимает и тянет с package.json?


    1. Igoryas Автор
      27.12.2023 08:12

      Согласен, что интересная технология и стоит присмотреться в ближайшем будущем. В данный момент есть поддержка .eslintignore, отключение комментариев ESLint и существует официальное расширение VSCode. Можете добавить команды scripts в package.json для запуска Oxlint. За более подробной информацией рекомендую Вам обратиться к официальной документации.


      1. aleks_raiden
        27.12.2023 08:12
        +2

        Документация там конечно хуже некуда ( В общем, конфиг не подхватило, добавление опции --timing приводит к панике, пришлось забить и вернуться к eslint-у


        1. Igoryas Автор
          27.12.2023 08:12

          Согласен с плохой документацией, зато есть большой Issues в нём есть много полезной информации и ответы на вопросы которая не покрывает документация ????

          Сейчас лучше просто ознакомиться и ждать скорого развития технологии ????


  1. faxenoff
    27.12.2023 08:12
    +2

    Поставил расширение oxc на VSCode - очень быстро нашёл очень мало. Видимо пока рано использовать.


    1. Igoryas Автор
      27.12.2023 08:12

      Согласен, что рано. В данный момент Oxlint не является полной заменой ESLint, рекомендуется использовать Oxlint в качестве дополнения. Я верю в светлое будущее данной технологии!


  1. wert_lex
    27.12.2023 08:12
    +5

    Вот имхо, плохая идея в хоть сколько-нибудь отдаленной перспективе для всех:

    • Rust-программистам быстро станет скучно разбираться в очередных тонкостях ES202x и обновлениях TS

    • JS/TS - программистам писать новые и редактировать существующие правила станет сложно. Чтобы это сделать нужно неплохо изучить сильно другой язык программирования (и Rust это не поганая джава, там думать надо по-другому)

    • когда оно начнет крашится по причине некачественного плагина, или опции --timing как в комментарии выше, то будь оно написано на JS/TS еще есть шанс подебажить самому, тулинг-то в основном тот же. Найти человека, который на постоянной основе знает JS/TS и очень большой молодец в Rust.. ну не знаю, а зачем он на JS/TS тогда пишет?

    В общем имхо, писать основной тулинг (а линтер в 2023 году, как ни крути - основной тулинг) на языке, отличном от языка, для которого этот линтер пишется - со всех сторон странная затея. Тут конечно надо не на Rust/Go/С++ (спаси и сохрани) все переписывать, а искать варианты того, что нужно протолкнуть в node, чтобы хотя бы свой тулинг работал пошустрее.


  1. ijustwanttobeacool
    27.12.2023 08:12
    +9

    Есть у меня подозрение, что если реализовать все возможности и правила плагинов ESLint - разница в производительности станет не такой драматической. Отказ от системы плагинов скорее всего является одним из ключевых факторов, который дал такой прирост к производительности, но у такого решения нет будущего: одному человеку сложно поддерживать правила для всех возможных фреймворков/библиотек

    Сейчас же это выглядит как сравнение кода новомодных фреймворков на примере одного компонента чекбокса, мол «смотрите насколько меньше кода по сравнению с реактом». А при масштабировании оказывается React/Vue куда лучше себя показывают


    1. ShADAMoV
      27.12.2023 08:12

      Подписываюсь под каждым словом!


  1. qgod
    27.12.2023 08:12

    Biomejs уже давно все это-же умеет и также быстро и тоже на раст. Интересно чем автору biomejs не зашел?


    1. Igoryas Автор
      27.12.2023 08:12

      Biomejs выходит за рамки этой статьи. С чего вы взяли, что он не зашел? Я об этом не упоминал. ????


      1. qgod
        27.12.2023 08:12

        Хочется сравнения какого-то - интересно что не хватило в biome