Comments 18
А давайте на Rust перепишем вообще ВСЁ!
Штука интересная. Подскажите, а он конфигурацию для литна понимает и тянет с package.json?
Согласен, что интересная технология и стоит присмотреться в ближайшем будущем. В данный момент есть поддержка .eslintignore, отключение комментариев ESLint и существует официальное расширение VSCode. Можете добавить команды scripts в package.json для запуска Oxlint. За более подробной информацией рекомендую Вам обратиться к официальной документации.
Документация там конечно хуже некуда ( В общем, конфиг не подхватило, добавление опции --timing приводит к панике, пришлось забить и вернуться к eslint-у
Согласен с плохой документацией, зато есть большой Issues в нём есть много полезной информации и ответы на вопросы которая не покрывает документация 😁
Сейчас лучше просто ознакомиться и ждать скорого развития технологии 🙃
Поставил расширение oxc на VSCode - очень быстро нашёл очень мало. Видимо пока рано использовать.
Вот имхо, плохая идея в хоть сколько-нибудь отдаленной перспективе для всех:
Rust-программистам быстро станет скучно разбираться в очередных тонкостях ES202x и обновлениях TS
JS/TS - программистам писать новые и редактировать существующие правила станет сложно. Чтобы это сделать нужно неплохо изучить сильно другой язык программирования (и Rust это не поганая джава, там думать надо по-другому)
когда оно начнет крашится по причине некачественного плагина, или опции
--timingкак в комментарии выше, то будь оно написано на JS/TS еще есть шанс подебажить самому, тулинг-то в основном тот же. Найти человека, который на постоянной основе знает JS/TS и очень большой молодец в Rust.. ну не знаю, а зачем он на JS/TS тогда пишет?
В общем имхо, писать основной тулинг (а линтер в 2023 году, как ни крути - основной тулинг) на языке, отличном от языка, для которого этот линтер пишется - со всех сторон странная затея. Тут конечно надо не на Rust/Go/С++ (спаси и сохрани) все переписывать, а искать варианты того, что нужно протолкнуть в node, чтобы хотя бы свой тулинг работал пошустрее.
Есть у меня подозрение, что если реализовать все возможности и правила плагинов ESLint - разница в производительности станет не такой драматической. Отказ от системы плагинов скорее всего является одним из ключевых факторов, который дал такой прирост к производительности, но у такого решения нет будущего: одному человеку сложно поддерживать правила для всех возможных фреймворков/библиотек
Сейчас же это выглядит как сравнение кода новомодных фреймворков на примере одного компонента чекбокса, мол «смотрите насколько меньше кода по сравнению с реактом». А при масштабировании оказывается React/Vue куда лучше себя показывают
Biomejs уже давно все это-же умеет и также быстро и тоже на раст. Интересно чем автору biomejs не зашел?
Из статьи так и не понял, есть ли поддержка typescript, jsx/tsx, vue.
На текущий момент Oxlint ещё не имеет системы плагинов, однако в дальнейшем обещают добавить правила из известных плагинов, таких как TypeScript
Oxlint содержит более 200 правил, включая правила из ESLint, TypeScript
Парсер демонстрирует в два раза более высокую скорость по сравнению с парсером swc в рамках тестирования, которое включает анализ файлов .js(x) и .ts(x).
Так поддержка typescript есть сейчас или её потом добавят? Я могу просто и без бубнов настроить правило, что бы оно было единообразно для plain-js и для
Такой же как и RSLint. Очередной проект, который преждевременно закроется из-за отсутствия мотивации у разработчикв.
Oxlint — более быстрая альтернатива ESLint