Ускоряем сборку веб-приложения с webpack

[alexesDev]

Это антисовет, т.к. [hash:base64:5] даёт худшие результаты с gzip + затрудняет дебаг прода.

{
  loader: 'css-loader',
  options: {
    modules: true,
    localIdentName: isDev
      ? '[path][name][local]'
      : '[hash:base64:5]'
  }
}

Это обсуждалось в issue к gastby. У них жестко зашиты длинные классы.

[disappearedstar]

Не поделитесь ссылкой на issue?
Про дебаг прода согласен, не самый лучший пример.

[alexesDev]

Не так запомнил. У gatsby в коде была ссылка на этот issue, а сам он прямо у css-loader
github.com/webpack-contrib/css-loader/issues/406

[Dreyk]

какое-то время использовал HardSource на CI. время сборки конечно уменьшало, но слишком часто стали появляться глюки, которые решались очисткой кешей. выключили

[kidar2]

И почему этого всего нет в коробке? Столько всего надо делать самому, чтобы просто работало быстро.

[lexey111]

Спасибо за статью! Явно очень большая работа проделана и много граблей истоптано в процессе. Как человек, много работающий с вебпаком, не могу не оценить.

Я хочу вставить пять копеек насчёт подхода с externals. У меня под рукой есть один проект, где применён такой приём, там сделано таким образом:

1. Файл с конфигом, что-то вроде такого —

export const Externals = [
   {
       alias: 'React', 
       dev: 'node_modules/react/dist/react.js', 
       prod: 'node_modules/react/dist/react.min.js'
   },
   ...
]

2. В самом webpack.config.js до собственно конфига довольно тривиальный код, который из этой структуры

— делает собственно объект для поля externals
— готовит список файлов для HTML/Webpack DefinePlugin (используется свой загрузчик ассетов, с фолбэком и излишествами)
— копирует каждый целевой файл для текущего окружения в output.
— ну и ещё пара трюков, которые проверяют, нет ли уже такого файла в месте назначения чтобы не делать лишней работы и быстрая грубая проверка через lstat совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».

Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…

[disappearedstar]

Наверно, есть веские причины использовать такой замороченный подход?

[lexey111]

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

[jquery_dlya_slabih]

На самом деле вы вводите людей в заблуждение по поводу parallel & cache в terser.
Они включены по умолчанию, пруф.

А то что в доке написано иначе — к сожалению так часто бывает, что readme ни кто не меняет.

[disappearedstar]

Это верно, если не оверрайдить optimizer — в этом случае вебпак подключает terser неявно с теми настройками, на которые вы привели ссылку. Если же передавать в конфиг вебпака собственноручно созданный экземпляр плагина с кастомным набором опций, то там дефолты уже другие.