Хабрахабр

Webpack 4 и разделение конфигурационного файла на модули

Привет Хабр! Сегодня я расскажу вам о Webpack 4 с разделением кода на отдельные модули, а также о интересных решениях, которые помогут вам быстрее собрать сборку на webpack 4. В конце, я предоставлю свою базовую сборку на webpack c самыми необходимыми инструментами, которую вы в последствие сможете расширить. Данная сборка вам поможет понять данный материал, а также возможно поможет быстрее написать свою реализацию и быстрее решить возможные проблемы.

Необходимые модули и плагины для dev и prod версии(а также для разделения функционала в главном файле) будут находиться в отдельной папке webpack и из неё импортироваться для соединения с главным конфигом. Основная идеология данной сборки — это корректное разделения кода внутри конфигурационного файла для удобства использования, чтения и чистоты webpack.config.js.

Зачем нужен такой подход?

С постепенным ростом количества модулей, плагинов и т.д, которыми обрастает ваша сборка на вебпаке, конфигурационный файл растёт как на дрожжах. Со временем данный файл становится трудно читаемым, а изменять его под конкретный проект, если какие-то модули в нём не используется становится труднее, а хочется чего-то универсального. Поэтому требуется чёткая организация кода.

Что нам понадобится?

Мы будем использоваться плагин webpack-merge.
Создаём папку webpack и выносим все отдельные модули в отдельные файлы. Например, webpack/pug.js, webpack/scss.js и экспортируем из них эти функции.

Файл pug.js

module.exports = function() , }, ], }, };
};

Файл 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, которая возможно вам поможет в работе и освоение.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть