Comments 10
Это антисовет, т.к. [hash:base64:5] даёт худшие результаты с gzip + затрудняет дебаг прода.
Это обсуждалось в issue к gastby. У них жестко зашиты длинные классы.
{
loader: 'css-loader',
options: {
modules: true,
localIdentName: isDev
? '[path][name][local]'
: '[hash:base64:5]'
}
}
Это обсуждалось в issue к gastby. У них жестко зашиты длинные классы.
+2
Не поделитесь ссылкой на issue?
Про дебаг прода согласен, не самый лучший пример.
Про дебаг прода согласен, не самый лучший пример.
0
Не так запомнил. У gatsby в коде была ссылка на этот issue, а сам он прямо у css-loader
github.com/webpack-contrib/css-loader/issues/406
github.com/webpack-contrib/css-loader/issues/406
0
какое-то время использовал HardSource на CI. время сборки конечно уменьшало, но слишком часто стали появляться глюки, которые решались очисткой кешей. выключили
0
И почему этого всего нет в коробке? Столько всего надо делать самому, чтобы просто работало быстро.
0
Спасибо за статью! Явно очень большая работа проделана и много граблей истоптано в процессе. Как человек, много работающий с вебпаком, не могу не оценить.
Я хочу вставить пять копеек насчёт подхода с externals. У меня под рукой есть один проект, где применён такой приём, там сделано таким образом:
1. Файл с конфигом, что-то вроде такого —
2. В самом webpack.config.js до собственно конфига довольно тривиальный код, который из этой структуры
— делает собственно объект для поля externals
— готовит список файлов для HTML/Webpack DefinePlugin (используется свой загрузчик ассетов, с фолбэком и излишествами)
— копирует каждый целевой файл для текущего окружения в output.
— ну и ещё пара трюков, которые проверяют, нет ли уже такого файла в месте назначения чтобы не делать лишней работы и быстрая грубая проверка через lstat совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».
Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…
Я хочу вставить пять копеек насчёт подхода с 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 совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».
Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…
+2
Наверно, есть веские причины использовать такой замороченный подход?
0
На самом деле вы вводите людей в заблуждение по поводу parallel & cache в terser.
Они включены по умолчанию, пруф.
А то что в доке написано иначе — к сожалению так часто бывает, что readme ни кто не меняет.
Они включены по умолчанию, пруф.
А то что в доке написано иначе — к сожалению так часто бывает, что readme ни кто не меняет.
0
Это верно, если не оверрайдить optimizer — в этом случае вебпак подключает terser неявно с теми настройками, на которые вы привели ссылку. Если же передавать в конфиг вебпака собственноручно созданный экземпляр плагина с кастомным набором опций, то там дефолты уже другие.
+2
Sign up to leave a comment.
Ускоряем сборку веб-приложения с webpack