Comments 5
Полезная информация, однако напрягает обилие конструкций типа "умеет в ...".
Мы тоже в свое время ускоряли сборку большого проекта. У нас была сборка по 13-15 минут, и это даже без сорс мапов. Сейчас у нас сборка с сорс мапами холодная — 25 минут, горячая — 2 минуты.
Единственное, что есть в статье и мы не применили это Dll. Но пока и не надо. Остальное все — реально очень полезно и работает!
Дополню нашим опытом:
- HappyPack нам значительно помог, поэтому не стоит сбрасывать его со счетов. Хотя он неудобный в настройке. Мне не нравятся плагины, генерирующие под себя лоадеры
- Parallel-webpack наоборот, откатил в скорости. На самом деле webpack и сам умеет собирать массив конфигов. Для нашего случая webpack справляется лучше, чем parallel-webpack. Возможно дело в том, что parallel-webpack для каждого конфига запускает свой процесс, а сам webpack нет, и это позволяет шарить in-memory кеши (результаты обработки модулей) между сборками разных конфигов. Это всего лишь гипотеза, но anyway у нас у конфигов много общего кода и сам webpack оказался быстрее чем parallel-webpack
- Как-то обошли стороной замечательный cache-loader, который также очень сильно нам помогает. Если протухают кеши HardSourcePlugin, нас спасает cache-loader. Его кеши протухают значительно реже. Сборка вместо 25 минут идет 12-13 минут
- HardSourcePlugin нужно использовать осторожно, на свой страх и риск. Не со всеми лоадерами\плагинами он может быть совместим и хорошо работать. Мы его чутка форкнули под наши нужды. Из больного — был случай, когда HardSourcePlugin думал что можно отдать данные из кеша, а на самом деле надо было пересобрать. Было, честно говоря, фатально
Также в дополнение, можно указывать не просто % ускорения, а также абсолютные величины. А то выходит что кеши babel-loader ускоряют всего на 8%. Выглядит не очень круто. На моей практике кеши бабеля самые стабильные, простые и одни из самых эффективных.
HardSourcePlugin я в итоге оставил только для дев-сборки, т.к. страшно тащить в продакшен деплой. В деве то себя иногда ведет весьма странно.
Про абсолютные величины ускорения: я писал изменение (до/после) в секундах, этого показалось не достаточно?
Спасибо за дополнение про cache-loader, действительно, не знал про него. Как он ведет себя при деплое на продакшен? Не вешает билд?
У него очень простая логика: для каждого реквеста, которые выглядят следующим образомstyle-loader!css-loader!sass-loader!resource-path.scss, сохраняется ответ.
Последующие обращения по этому реквесту будут считываться с файловой системы, вместо выполнения реальными лоадерами. Происходит это во время pitch фазы загрузки модуля.
Алгоритм почти такой же как в babel-loader, но можно прикрутить к любому ресурсу. В ключ кеша входят — request, cacheKay из опций и modifyDate запрашиваемого файла. Мы для CI сделали форк, который использует hash контента запрашиваемого файла вместо modifyDate.
У нас с cache-loader полет нормальный, единственный кто не подводит никогда (в особенности наш форк, проверяющий hash контента)
HardSourcePlugin я в итоге оставил только для дев-сборки, т.к. страшно тащить в продакшен деплой. В деве то себя иногда ведет весьма странно.
Мы в дев сборку наоборот не тащим, в watch режиме по памяти слишком часто начинает падать webpack с HardSourcePlugin. А про время сборки продакшн билдов без него я уже упоминал — 25 минут. На текущий момент, HardSourcePlugin нужен нам как воздух, что плохо, но нас устраивает.
Про абсолютные величины ускорения: я писал изменение (до/после) в секундах, этого показалось не достаточно?
Чисто мое субъективное мнение. Обратил внимание на 8% и подумал что-то не очень помогло, а ведь должно было, и действительно, в цифрах — минута
Ускорение сборки JavaScript-кода с использованием webpack 2–3