Hi Habr! Today I will tell you about Webpack 4 with the division of code into separate modules, as well as interesting solutions that will help you to quickly assemble the assembly on the webpack 4. In the end, I will provide my basic assembly on the webpack with the most necessary tools that you can later to expand. This assembly will help you understand this material, and also possibly help you write your implementation faster and solve possible problems faster.
 
 
The main ideology of this assembly is the correct separation of code inside the configuration file for ease of use, reading and cleanliness of webpack.config.js. The required modules and plugins for the dev and prod versions (as well as for sharing functionality in the main file) will be located in a separate webpack folder and imported from it to connect to the main config.
 
 
3r314. Why do you need such an approach?
 
With the gradual increase in the number of modules, plug-ins, etc., that your build on the web pack grows over, the configuration file grows like yeast. Over time, this file becomes difficult to read, and to change it for a specific project, if some modules in it are not used, it becomes more difficult, but you want something universal. Therefore, a clear code organization is required.
 
 

What do we need?

 
We will use the plugin webpack-merge .
 
Create a webpack folder and put all the individual modules into separate files. For example, webpack /pug.js, webpack /scss.js and export these functions from them.
 
 
File pug.js
 
3r3191. 3r3192. module.exports = function () {
return {
module: {
rules:[
{
test: /.pug$/,
loader: 'pug-loader',
options: {
pretty: true,
},
},
],
},
};
};
3r3198. 3r-33199.
 
The webpack.config.js file is . In this file we connect them, and with the help of this plugin we connect them quickly and easily.
 
3r3191. 3r3192. 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: {},
3r-3218.},
pug (),
))
3r3198. 3r-33199.
 
Now, if we have a new task, which requires a new module, a plug-in, a loader, then we take it to the hotel module (file) and put it in the webpack folder, and then connect it to the main configuration file, keeping the config as clean as possible.
 
 

Settings for production and development

 
Now, with the help of the banal if, we’ll finish our division, which we aspire to, and set up our webpack for these two types of development, thanks to which it will become completely convenient to use this tool, as well as in the future we will be able to flexibly and simply customize it for any other project, or expand in the current. To export to the node (for the webpack itself) in webpack 4 we use the following construction:
 
3r3191. 3r3192. 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(),
]);
}
3r3198. 3r-33199.
 
In the common object, we connect what is used both in the prode and in the development, and in the conditions we connect only those modules that are necessary in these cases.
 
 

Now I would like to talk about the main features of webpack 4 regarding webpack 3

 
 
3r3188. For a quick start, webpack 4 does not need webpack.config.js, it now only needs an entry point (index.js) 3r-3200.  
3r3188. In the new version of the webpack command line interface is placed in a separate package and you need to install webpack-cli.
 
3r3188. To start webpack ? it is necessary (otherwise it will be warning) in the scripts to specify mode (mode of operation) --mode production or --mode development, depending on the key, the operation of the webpack changes. Development mode aims to speed up the build. In the production version, everything is directed to the final minification of the code.
 
3r3188. In order to create common.js and common.css files, the CommonsChunkPlugin is no longer used, splitChunks are now responsible for this and the following construction is used:
 
3r3191. 3r3192. optimization: {
splitChunks: {
cacheGroups: {
'common': {
minChunks: ?
chunks: 'all',
name: 'common',
priority: 1?
enforce: true,
},
},
},
},
3r3198. 3r-33199.
 
In webpack 3 - this would be true in plugins:
 
3r3191. 3r3192. new webpack.optimize.CommonsChunkPlugin ({name: 'common',}) 3r-33199.
 
Accordingly, in the chunks in HtmlWebpackPlugin we connect (here without changes).
 
3r3191. 3r3192.
plugins:[
new HtmlWebpackPlugin({
filename: 'index.html',
chunks:['index', 'common'],
template: PATHS.source + '/pages/index/index.pug',
}),
]
3r3198. 3r-33199.
 
 
3r3188. The next important point, in order to create a sourceMap, now we use the following approach - we create the sourceMap.js file in the webpack folder and connect it in the version version (for example, as above): 3r3203.  
3r3191. 3r3192. module.exports = function () {
return {
devtool: 'eval-sourcemap',
};
};
3r3198. 3r-33199.
 
3r3202.
 
Now approach with plugins:[new webpack.optimize.UglifyJsPlugin({}) ] does not work.
 
 
With this, I would like to complete my story and provide my basic build - 3r-3211. Reference
on webpack ? which may help you in work and development. Thanks for attention!