Комментарии 9
Сборщики работали бы быстрее, если бы они работали с уже собранными пакетами. Если в пакету будет index.js и index.d.ts то сборка будет идти гораздо быстрее. Но во много пакетах, помимо кучи транзитивных зависимостей или и бардак с самим кодом. Там зачастую, просто хранят исходники, а бывает и юнит тесты. Про esbuild все и так знают. Но что насчёт пакетов? Почему никто не бьёт в колокол по этому поводу?
Я так понимаю, вы могли бы избавиться только от Stylus и может еще пару легаси штук, и уже бы были счастливы с текущим сборщиком
Подскажите, как именно вы поняли, что работа со Stylus отнимает так много времени сборщика?
Хороший результат. У нас в проекте не так всё печально: на современном ноутбуке сборка занимает 40 секунд, а вот на CI несколько минут. Если бы получилось хотя бы в 5 раз ускориться, было бы круто. Но тоже большие конфиги webpack. Нахрапом не взять, думаю. Больше всего пугает неизвестное время на исследование.
Второй шаг — отказ от ненужного и устаревшего.
Можно уже не хейтить тех, кто пишет на ES6+ вместо TS или ещё рано?
На моём опыте самое медленное звено — Typescript + EsLint. И заменить их нечем. "Аналоги" на rust/go работают молниеносно, но тому есть причина — они не делают 99% работы, т.е. type-checking-а и linting-а. А это именно то, что мне экономит больше всего времени и сил. Если в теории кто-то возьмётся и за это, то боюсь, что встанет другой вопрос — расхождения реального TS Language Server-а и rust/go решения.
Похоже, что пока что самое рабочее решение — это отделять сборку и type-checking. Т.е. условно сборка за 2.5сек, а потом вдогонку к ней прилетает секунд через 30 проверка типов и eslint.
Отдельная беда — дублирование. Тот же TS Language Server на машине разработчика запущен дважды/трижды: в сборке (1-2 раза) и в vsCode/IDE. Т.к. оный на больших проектах легко отъедает и 5 и 10 GiB… это печально.
На Хабре обсуждалось не раз предложение "сделать единое AST для TS, ESLint, Webpack и других сборщиков, переиспользовать в IDE", вроде вы тоже участвовали в обсуждениях. Но каждый раз приходим к тому, что есть разные лицензии, корпоративные политики (TS), ограничения операционных систем, разность механик работы разных инструментов. Я тоже хотел бы видеть "универсальный процесс, генерирующий универсальное дерево с адаптером ко всем языкам программирования", это был бы, наверное, лучший вклад в экосистему разработки за десятилетия, но остается только мечтать...
А вы смотрели на Rspack и Parcel? Parcel достаточно зрелый инструмент, а у Rspack хорошая совместимость с Webpack.
считает Эван Уоллес, сооснователь Figma
Уоллесу не помешало бы заняться работоспособностью своего собственного продукта, Figma работает, мягко говоря, не быстро, а уж если называть вещи своими именами, то работает она как полное говно.
Спасибо за наводку на esbuild-loader, интересно посмотреть что это такое. Что касается остальной статьи, выглядит, мягко говоря, довольно странно:
Конкретно Евгений использовал ещё один нестандартный механизм – require.context...
...CSS модулей и Stylus, которые были в нашем проекте
Вы бы ещё больше всякого мусора на проект накинули и удивлялись бы что он долго собирается. Можно было б ещё пару лоадеров, сверху, чисто по фану накидать, почему нет?
Все эти претензии к скорости вебпака растут из одного места - сначала накидывают в проект как можно больше костылей, которые "вау такая крутая фича", а потом героически борются со всем этим.
Все эти претензии к скорости вебпака растут из одного места - сначала накидывают в проект как можно больше костылей, которые "вау такая крутая фича", а потом героически борются со всем этим
Да если бы было всё так просто...
Я так года 3 назад на проекте небольшого сервера на ноде с TypeScript с самым простейшим конфигом вебпака задолбался ждать по 10-15 секунд сборку/пересборку, узнал про esbuild и решил его попробовать и знаете что, 50msec сборка. Мысль об дальнейшем использовании вебпака в любых других проектах была выброшена из головы сразу же.
Webpack: заменить нельзя оставить