Дегустируем Rspack

В последнее время язык программирования Rust находится на самом гребне волны хайпа. То тут, то там пестрят такие заголовки: «делаем на раст some_gnu_cli_utility», «Rust‑реализация привычной программы», «давайте перепишем на Rust ВООБЩЕ ВСЁ». Мне и самому очень нравится этот язык, и рост его популярности считаю вполне заслуженным. Несмотря на крутую кривую обучения и весьма высокий порог входа, в Rust правильно сделано если не всё, то почти всё. Многие языки годами и десятилетиями шли к тому, что «крабоводам» предлагалось «из коробки» на заре истории Rust.

Эпоха, когда во фронтенд‑экосистеме раз в неделю появлялся новый JS‑фреймворк, канула в Лету. На дворе 2024-й, теперь раз в неделю появляется новый бандлер, причём зачастую написанный именно на Rust (например, Turbopack, Rolldown, Farm и Mako от китайских товарищей). В этой статье я хочу опробовать в действии наиболее многообещающий из них — Rspack. Он позиционируется как быстрый сборщик, имеющий полную обратную совместимость с Webpack. Разработчики Rspack несколько месяцев назад выпустили стабильную мажорную версию (1.0) и продолжают активно развивать проект.

Что ж, давайте его попробуем. В качестве подопытного кролика возьмём не очередной Hello World, специально заточенный под бенчмарки, а реальный сложный проект, в котором есть:

• четыре режима сборки Webpack;

• сложная предметная область и, соответственно, сложная логика;

• 550+ React‑компонентов.

Кстати, вот моя статья, где описывается, как содержать в чистоте конфигурационные файлы на подобного рода «атомоходах».

Что не так с Webpack?

Он медленный, особенно в больших проектах. Чтобы не быть голословным, приведу результаты измерения времени его работы (измерял на рабочем Macbook Pro M1, на машинах послабее будет отрабатывать ещё дольше).

• Длительность запуска dev‑сервера: около 25 секунд.

• Длительность сборки изменений во время разработки с HMR: около 10 секунд.

• Длительность сборки production‑артефактов: примерно 30 секунд.

Согласитесь, ждать почти 10 секунд после каждого сохранения быстро начинает раздражать. Иногда эти секунды кажутся вечностью. Душу разработчика терзает желание хоть как‑то ускорить горячую замену модулей и улучшить developer experience. Как раз недавно я наткнулся на серию статей про Rspack и очень захотел его опробовать в деле.

Приготовление Rspack

Устанавливаем с официального сайта:

$ npm add @rspack/core @rspack/cli -D

Затем, как они рекомендуют, просто заменяем в package.json:

{   "scripts": { -   "serve": "webpack serve", -   "build": "webpack build", +   "serve": "rspack serve", +   "build": "rspack build",   } }

Но нетут‑то было. Обещанная полная обратная совместимость с Webapck не такая уж и полная. «Мелким шрифтом» на официальном сайте всё же написано, что некоторые плагины и загрузчики требуют своей собственной конфигурации. Я почти полностью переписал конфигурационные файлы. Заодно был подчистил накопившийся техдолг, так как он блокировал миграцию на Rspack. Мне пришлось:

• Обновить версию node.js (с 16.13 на 22.11).

• Переделать файлы сборки с commonjs на es6 modules.

• Избавиться от babel-loader и ts-loader в пользу swc-loader.

• Выкинуть неиспользуемые в проекте части конфигурационных файлов.

Этот рефакторинг конфигов занял у меня три вечера и стоил пять кружек мятного чая.

Дегустация Rspack

Результаты работы сборщика Rspack приятно порадовали. Длительность работы (как сборка production‑артефактов, так и запуск dev‑сервера и HMR) по сравнению с Webpack значительно уменьшилась.

В таблице приведено сравнение результатов работы для разных режимов сборки проекта (стандартное статическое React‑приложение и web‑компонент).

Однако

Как человек, который родился в конце августа, я просто не мог принять на веру тезисы из лэндинга Rspack и хайп вокруг этой технологии. Поэтому для сравнения я решил довольно тщательно измерить длительность работы Webpack и Rspack. В моём арсенале были такие инструменты измерения производительности как:

• Hyperfine

• Rsdoctor

• Speed Measure Webpack Plugin (SMP)

Неожиданно SMP указал на наличие проблемы в существующей конфигурации Webpack, которая не только значительно увеличила длительность запуска, но и снизила скорость компиляции во время HMR. Как оказалось, 12 секунд во время запуска dev‑сервера отъедал бесполезный для нас плагин case‑sensetive‑webpack‑plugin. В то же время незаменимый Webpack Bundle Analyzer отрабатывал при каждом изменении в коде, и именно он и вызывал настолько долгий и раздражающий HMR. Выкинув совсем из конфигурации Webpack case‑sensetive‑webpack‑plugin и оставив Webpack Bundle Analyzer только для production‑сборок, я смог почти в два раза сократить длительность запуска dev‑сервера и более чем в 25 раз сократить продолжительность компиляции при HMR. Pull request на удаление этих плагинов из конфигурации моего проекта отправил в ту же минуту.

Будет справедливо привести результаты измерения производительности Webpack и Rspack как с тормозящими процесс сборки плагинами, так и без них.

Послевкусие

Да, Rspack действительно шустрее, чем Webpack. Но разница, в сравнении с оптимизированной конфигурацией Webpack, совсем не значительная. Даже в большом и сложном проекте. Да, 150 миллисекунд на HMR (у Rspack) — это в целых два раза меньше, чем 300 миллисекунд у Webpack, но конечный разработчик совсем не почувствует этого ускорения. Экономия десяти секунд в длительности работы всего CI/CD-конвейера тоже не играет особой роли. А вот значительное изменение конфигурационных файлов может занять немало времени. Также не исключено, что таким изменением можно внести в проект пару‑тройку багов, которые дадут о себе знать в самый неподходящий момент.

В итоге я не советую переезжать на Rspack только потому, что там под капотом есть владение/заимствование и обработка ошибок при помощи монад. Лучше проверить производительность своей конфигурации Webpack тем же SMP, что‑нибудь неожиданное и интересное наверняка найдётся.

Спасибо за внимание, удачных вам настроек конфигурации, минимума багов и быстрых конвейеров.