Как улучшить производительность webpack/Babel, не используя функцию часов?

Я работаю над веб-проектом SBT/ Scala, и я хотел использовать возможности ES6 и новый синтаксис модуля для интерфейса JavaScript-интерфейса. SBT имеет собственную систему сборки, и мне удалось настроить существующий плагин sbt для запуска webpack для создания моих JS файлов с помощью babel. Нынешнее решение немного беспорядочно, но оно работает и живет в системе сборки sbt.

Проблема в том, что она медленная. Для каждого изменения создается новый экземпляр webpack и полностью скомпилируется с нуля.

Я знаю, что я мог бы выпрыгнуть из системы сборки sbt, и только для фазы разработки используйте webpack отдельно, чтобы смотреть и перестраивать мои файлы. Но прежде чем я это сделаю, мне было интересно, есть ли способы ускорить процесс сборки webpack.

Я проверил документацию, и мне кажется, что любое доступное кэширование обрабатывается только в памяти, и это неприменимо для моего случая. Или есть какой-то файловый кеш, который выжил бы между отдельными запусками сборки webpack? Например, все мои зависимости npm не будут меняться большую часть времени, поэтому они могут быть скомпилированы один раз, кэшированы, а затем просто включены...

Ответ 1

Некоторая конфигурация для рассмотрения:

module.loaders include - Вы должны установить include, чтобы указать на ваш источник. По умолчанию он будет пересекать все (node_modules в частности медленнее). Убедитесь, что у вас установлен
resolve.unsafeCache
module.noParse
Включить кеширование babel-loader - loader: 'babel?cacheDirectory'.
уже построенные, миниатюрные библиотеки.
future - cache - это может работать в один прекрасный день. К сожалению, нет никакого приятного способа сериализации данных кэша.

Ответ 2

Проблема в том, что она медленная. Для каждого изменения создается новый экземпляр webpack и полностью скомпилируется с нуля.

Мы столкнулись с этой же проблемой, когда наша модульная база стала большой (3.5k +), где webpack заработал до 80 секунд на обычном MacBook 13 для выполнения начальной сборки.

Подход, который мы предприняли, заключался в том, чтобы распараллелить фазу трансформации (в основном, загрузчики веб-пакетов), что дало прирост до 500% с точки зрения времени сборки на некоторых машинах. Проверьте https://github.com/amireh/happypack для плагина и посмотрите, может ли он работать для вас.

Он еще не поддерживает все загрузчики, но поддерживается babel-loader, в котором я считаю, что вам нужно.

Ответ 3

В Webpack есть функция, которая позволит вам создавать библиотеки DLL (ака. "Библиотечные пакеты" ), которые вы можете компилировать один раз отдельно от основного кода приложения.

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

Я написал сообщение о том, как это сделать здесь: https://robertknight.github.io/posts/webpack-dll-plugins/

Из приведенных выше предложений @bebraw я хотел бы указать, в частности, на 1) сглаживание существующих мини-библиотек вместо их включения в комплект, который обеспечивает те же преимущества, что и создание библиотечных пакетов, и 2) Если вы используете транспилер, важно, чтобы транспилер работал только на вашем собственном коде с помощью опций module.loaders.(include|exclude), а не всего кода библиотеки в node_modules/