Webpack 4 и разделение конфигурационного файла на модули
Привет, Хабр! Сегодня я расскажу вам о Webpack 4 с разделением кода на отдельные модули, а также о интересных решениях, которые помогут вам быстрее собрать сборку на webpack 4. В конце, я предоставлю свою базовую сборку на webpack c самыми необходимыми инструментами, которую вы в последствие сможете расширить. Данная сборка вам поможет понять данный материал, а также возможно поможет быстрее написать свою реализацию и быстрее решить возможные проблемы.
Основная идеология данной сборки — это корректное разделения кода внутри конфигурационного файла для удобства использования, чтения и чистоты webpack.config.js. Необходимые модули и плагины для dev и prod версии (а также для разделения функционала в главном файле) будут находиться в отдельной папке webpack и из неё импортироваться для соединения с главным конфигом.
Зачем нужен такой подход?
С постепенным ростом количества модулей, плагинов и т.д, которыми обрастает ваша сборка на вебпаке, конфигурационный файл растёт как на дрожжах. Со временем данный файл становится трудно читаемым, а изменять его под конкретный проект, если какие-то модули в нём не используется становится труднее, а хочется чего-то универсального. Поэтому требуется чёткая организация кода.
Что нам понадобится?
Мы будем использоваться плагин webpack-merge.
Создаём папку webpack и выносим все отдельные модули в отдельные файлы. Например, webpack/pug.js, webpack/scss.js и экспортируем из них эти функции.
Файл pug.js
module.exports = function() {
return {
module: {
rules: [
{
test: /\.pug$/,
loader: 'pug-loader',
options: {
pretty: true,
},
},
],
},
};
};
Файл webpack.config.js. В данном файле мы их подключаем, и с помощью данного плагина удобно и быстро соединяем.
const merge = require('webpack-merge');
const pug = require('./webpack/pug');
const common = merge([
{
entry: {
'index': PATHS.source + '/pages/index/index.js',
'blog': PATHS.source + '/pages/blog/blog.js',
},
output: {
path: PATHS.build,
filename: './js/[name].js',
},
plugins: […],
optimization: { … },
},
pug(),
]);
Теперь если у нас есть новая задача, под которую нужен новый модуль, плагин, лоадер, то мы выносим его в отельный модуль (файл) и помещаем в папку webpack, а затем подключаем его в главный конфигурационный файл, сохраняя конфиг максимально чистым.
Настройки для production и development
Сейчас мы с помощью банального if закончим наше разделение, к которому мы стремились, и настроим наш вебпак под эти два типа разработки, благодаря чему станет окончательно удобно пользоваться данным инструментом, а так же в будущем сможем гибко и просто настраивать его под любой другой проект, или же расширять в текущем. Для экспорта в ноду (для самой работы вебпака) в webpack 4 мы используем следующую конструкцию:
module.exports = function(env, argv) {
if (argv.mode === 'production') {
return merge([
common,
extractCSS(),
favicon(),
]);
}
if (argv.mode === 'development') {
return merge([
common,
devserver(),
sass(),
css(),
sourceMap(),
]);
}
В объект common мы подключаем то, что используется и на проде и в разработке, а в условиях подключаем только те модули, которые необходимы в этих случаях.
Теперь хотелось бы поговорить об основных особенностях webpack 4 относительно webpack 3
- Для быстрого запуска, webpack 4 не нуждается в webpack.config.js, ему теперь необходима лишь точка входа (index.js)
- В новой версии webpack command line interface вынесен в отдельный пакет и нужно установить webpack-cli.
- Для запуска webpack 4, нужно (иначе будет warning) в скриптах указать mode (режим работы) --mode production или --mode development, в зависимости от ключа меняется работа вебпака. Режим development направлен для ускорения сборки. В production варианте направлено всё на итоговую минификацию кода.
- Для того что бы создать common.js и common.css файлы, более не используется CommonsChunkPlugin, за это теперь отвечают splitChunks и используется следующая конструкция:
optimization: { splitChunks: { cacheGroups: { 'common': { minChunks: 2, chunks: 'all', name: 'common', priority: 10, enforce: true, }, }, }, },
В вебпак 3 — это было бы так в plugins:new webpack.optimize.CommonsChunkPlugin({ name: 'common ', })
Соответственно в чанках в HtmlWebpackPlugin подключаем (тут без изменений).plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', chunks: ['index', 'common'], template: PATHS.source + '/pages/index/index.pug', }), ], - Следующий важный момент, для того чтобы создать sourceMap, теперь мы используем следующий подход — создаём файл sourceMap.js в папке webpack и подключаем в дев версии например (как указано выше):
module.exports = function() { return { devtool: 'eval-sourcemap', }; };
Теперь подход с plugins: [new webpack.optimize.UglifyJsPlugin ({}) ] не работает.
На этом я хотел бы завершить свой рассказ и предоставить свою базовую сборку — ссылка на webpack 4, которая возможно вам поможет в работе и освоение. Спасибо за внимание!
