Webpack4 under the microscope: path manipulation

The simplest and most complex operation for the packaging tool is the path arrangement. The resources that were originally in the SRC directory are packaged to the dist directory, but the packaged file path is not satisfactory. You want to put files in a bunch, but you end up with a hodgepodge of JS, HTML, CSS, and even images. It’s fine to pack it up and run it, but it’s killing people with OCD.

So this article is to explain how to explicitly arrange the path of each resource, regardless of WebPack performance, regardless of all kinds of operations, just the basic path operation.

Traditional websites tend to divide folders into three categories: styles,scripts, and images. Seeing these folders makes you feel like an old friend. If CSS files were in scripts at this point, or the images folder was in scripts, it would be a joke to write the front end of this website. But if this happens after the Webpack is packed, it’s no surprise. Packing is a surprise every time, and if configured incorrectly, the resulting files can play hide and seek with you. To this end, I have sorted out the possible path problems in Webpack packaging, as shown in the outline below, and if any of you have encountered such problems, you can query them as needed.

Outline:

• Js path problem
• CSS Path Problems
• HTML path problem
• Image path problem(important)
  • Js image reference path
  • Image reference path in the CSS
  • HTML image reference path

Webpack packaging process

In simple terms, the webpack packaging process is to turn all resources into JS chunk modules, and then operate the chunk modules, and finally output them according to the configuration.

In order to get a better idea of where our packages go, I built a perverted file directory.

JS generation path

JS is the best control in this process, according to the configuration of the entry and output can easily control the context. These two configurations are explained in considerable detail in the official documentation.

One HTML, one scene, one entry, and the corresponding file is generated according to the entry name during output.

entry:{
    "index":path.resolve(__dirname,"src/scripts/index/index.js"),
    "list":path.resolve(__dirname,"src/scripts/list/list.js"),
},
output:{
    path:path.resolve(__dirname,"dist"),
    filename:"[name].js"
},
Copy the code

Note here:

• Output. path is the path of the project, which is the relative path of the CSS, images, etc.
• Output.filename can not only be named, it can be configured here if you want js to be placed in a specific directory, like thisfilename:"scripts/[name].js"This will generate a directory for scripts in the dist directory, where JS will be generated when packaged.

CSS Generation Path

CSS references are more complex than CSS. Instead of direct HTML references, they import “.. /.. /styles/index/index.css” import, or require, into JS like this so that Webpack packs CSS into the new directory. However, the native CSS, JS is not known, so this time need loader to help us compile CSS to import JS.

The loader of CSS

Css-loader is an obvious syntax for compiling CSS into JS.

The main thing style-loader does is to insert the CSS code compiled in JS into the DOM to make it work.

Mini-css-extract-plugin, the main purpose of this plug-in is to separate the CSS code from each JS (chunk) and package it into its own named CSS file. (Note: ExtractTextPlugin is only applicable to Webpack3 and below.) , the CSS file generation path problem, we mainly use this plug-in to achieve, and this plug-in not only in the loader to participate in the compilation of CSS, but also need to play a role in packaging, packaging CSS into the corresponding folder.

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports={
    ...
    //loader
    module: {
        rules: [
            {
                test: /\.css$/,
                use: [
                    {
                    loader: MiniCssExtractPlugin.loader,
                    options: {
                        publicPath: '.. / '}},"css-loader"[// CSS package new MiniCssExtractPlugin({filename:"styles/[name].css"}})]Copy the code

The code above shows the use of the MiniCssExtractPlugin plugin. Its main generated configuration is in filename:”styles/[name].css”. This feels like a similar configuration to webpack’s output.filename, which packs CSS under the styles folder.

HTML generation path

HTML packaging compilation is special. Html-webpack-plugin is generally used to configure and generate HTML files by writing templates. This plug-in is very powerful, but only the configuration of the build path is mentioned here.

const HtmlWebpackPlugin = require('html-webpack-plugin');
Copy the code

Here’s how I configure the HTML, import the template, and generate the file. I give filename an absolute path so I don’t have to worry about where the file will be generated. It is also possible to give a filename directly to filename: ‘index.html’, which will follow the path specified by output in webpack, i.e. the project directory is the relative path of the object. The chunks here are [“index”] to make them separate from what is contained in the HTML, otherwise it will sneak all the resources into the current HTML.

new HtmlWebpackPlugin({
    filename: path.join(__dirname,'/dist/index.html'),
    template: path.join(__dirname,'/src/templates/index.html'),
    chunks: ["index"]})Copy the code

Image generation path

This is probably the most relatively complex piece, but it’s not too responsible to analyze it individually.

images in JS

This part is the easiest, because getting resources from JS is the most straightforward, without compiling multiple processes.

File-loader is the loader used to import files. The generated address of the configuration file in outputPath. So here we have images/, dist/images. The useRelativePath option may seem innocuous, but you need to be careful when configuring it otherwise you will end up with dist/images/images calling the Loader multiple times.

{
    test: /\.(png|jpg|gif)$/,
    use: [
      {
        loader: 'file-loader',
        options: {
            useRelativePath:false,
            outputPath: 'images/',
            name: '[name].[ext]'}}},Copy the code

If you want to import an image, you can simply import or require the image address, which is the same as CSS calls.

images in CSS

In CSS, we often use images, such as background, so how do we pack images and change the address of images in CSS? Since our CSS is imported into JS, file-loader will help us deal with the image problems in the same way as JS. However, the reference address of CSS images is a problem.

{
    loader: MiniCssExtractPlugin.loader,
    options: {
        publicPath: '.. / '}}Copy the code

You can use the publicPath attribute in the Loader, which does not compile and only replaces the path at the end of the package. Here the path of the image in the CSS is image/xxx.jpg, if we add this.. /, then it becomes… / image/XXX. JPG. Through this to control the CSS image problem, if you want to change the CDN address can also be.

images in HTML

This section is the most annoying part of file-loader does not handle the IMG tag in HTML. Here we will use the HTMl-loader to handle the image problem, as follows:

{
    test: /\.html$/,
    use: [ {
    loader: 'html-loader', options: {publicPath:". /",
        attrs: ['img:src']]}}}Copy the code

This will wrap up the HTML image file nicely. This plugin does not have a publicPath configuration, which relies on output.publicPath. If output.publicPath is empty, the packaged file address is images/xxx.jpg. If output.publicPath=”./”, the package is./images/xxx.jpg.

conclusion

Package paths say complex relative paths are really confusing, so this time need to keep a clear mind. The relative of the relative path. If you don’t need it, use the absolute path. Some plugins still have the publicPath option in a user-friendly way, and you can control it manually.

The loader and Plugin used in this article