Шаг 4. HtmlWebpackPlugin и его настройка
Ранее мы уже работали с указанным плагином, собирая двухстраничное приложение. Можете освежить память и посмотреть эту демонстрацию.
В первую очередь нам нужно понять, куда выносить блоки кода, плагины и другую логику, связанную с ведением разработки и билда проекта, к коим относится вышеуказанный плагин.
Приступим.
С одной стороны, HtmlWebpackPlugin нам нужен для разработки. С другой, он создаёт HTML после билда. Куда в таком случае его разместить?
Логичнее всего разместить всё, что связанно с настройкой плагина, в файл webpack.base.js, где хранится общая логика работы конфига. Так нам будет проще найти этот плагин, и мы не нарушим принцип DRY — избежим дублирования кода в разных файлах.
Для начала создадим переменную, в которой в формате массива со строками будем хранить имена файлов. А после, отталкиваясь от неё, будем настраивать плагин.
Как это выглядит:
// файл webpack.base.js
const fileName = ['index']
// остальной код...
module.exports = {
context: path.resolve(__dirname, '../src'),
entry: fileName.reduce((config = {}, file) => {
config[file] = `./${file}.js`
return config
}),
// output можно не трогать
plugins: [].concat((file) => {
new HtmlWebpackPlugin({
template: `./${file}.html`
filename: `./${file}.html`
chunks: [file]
})
// остальные плагины подключаются здесь
}).filter(Boolean)
// дальше идут обработчики...
}
Что здесь происходит «под капотом»:
- В качестве входной точки у нас массив имён файлов. Проходясь по нему, webpack понимает, какие ему нужно брать (напоминание о том, что контекст в сборщике устанавливается для сокращения путей, в нашем случае к директории с исходным кодом).
- После этого, в отведённом для плагинов поле, мы инициализируем их пустым массивом и объединяем. Делаем это, чтобы не дублировать HtmlWebpackPlugin для подключения HTML-файлов. При этом они должны находиться в директории src.
Запись .filter(Boolean) означает, что все falsy значения (при их наличии) будут проигнорированы и удалены (отфильтрованы).