DEV Community: Lee

I have taken advantage of Excel's functionality to develop a CLI tool to better manage data

Lee — Fri, 22 Dec 2023 02:28:42 +0000

Hello everyone! Today I would like to introduce this tool I developed - ejc-cli.

Practical issues

Sometimes, in order to save back-end development costs, we use json files to store some data locally, and then use these data for rendering. However:

If there are too many pages or modules that require data, the corresponding json files will also increase. There are too many files and data is too fragmented, making managing so many files difficult
When the amount of data is large, the data can become very lengthy, and it is difficult to directly find a specific piece of data
Sometimes json is not a good way to spread our data when we want to share it with other non developers

Why choose Excel to manage data

More convenient operation. Excel is a professional office software. Adding, deleting, modifying, and querying data in Excel is of course much more convenient than modifying it in our editor
More visual. Each sheet can be used as data for a certain page or module; The name of each sheet is the name of our json; Each row of data in the sheet is the data of each of our json
More convenient management. The data is integrated into an Excel file, making it easier for us to manage the data of all modules or pages
More suitable for dissemination. json is not suitable for dissemination among non developers, but Excel is suitable for all people. Not only can non developers modify this Excel, but if you find a problem in Excel, you can also modify it and then sync it to others.

Tools are born

Therefore, in order to solve the above problems and combine the comprehensive advantages of Excel, ej-cli was born, so you only need to focus on managing the Excel file.

For more convenient use, ejc-cli does not require you to create a Excel yourself. It already has a Excel built-in, and you only need to execute:

ejc-cli gt

Or save the template file to the specified directory:

ejc-cli gt './ xlsx_ template/'

In this way, we can obtain a 'Excel' template file, and then replace the data in it with what you want. That's as simple as that.

Then export the json data:

ejc-cli -i './ xlsx_ template/template.xlsx'

The results are as follows:

End

I hope this tool can help you.

If you like it, you can give it a star
If you have any suggestions, you can give me a issue to improve it.

For more information about ejc-cli, you can check here.

I efficiently learned "webpack development environment configuration" using this idea

Lee — Fri, 08 Sep 2023 08:33:53 +0000

Preface

We often see structures like the following when using webpack:

build
├── webpack.common.js
└── webpack.dev.js
└── webpack.prod.js

Often times, webpack configurations we basically copy and paste without thinking about why we're breaking the config file down into so many. As a result, when we learn to configure webpack on our own, we often have problems such as the following:

Slow builds in development environments
Blank pages after packaging
Resources not found

In fact, these problems, all stem from us:

Not understanding webpack to build the development environment, production environment, the two environment configuration of the difference in thinking
We don't have a clear understanding of the file directories of the two environments.

So this article is the same as before, will not just copy the configuration over, but hope that summarize the relevant methods, so that we can better learn to configure.

Learning Outline

This article focuses on:

The core idea of webpack development environment configuration.
Completing a development environment configuration based on the core concepts
Explain some confusing points in the devServer configuration.
Summarize the core ideas of webpack development environment configuration.

Remarks

The article has been uploaded to github:

For the sake of reading convenience, the article only posted the relevant code, it is recommended to fork it to see the complete code; or follow along with the article and write the code yourself
It's not easy to create, if you think it's helpful, welcome to star🌟!

Development Environment Core Ideas

We mentioned above that we often see directories like the following when using webpack:

build
├── webpack.common.js
└── webpack.dev.js
└── webpack.prod.js

Why do we need to break the configuration file into so many, so cumbersome?

Let's first review, in our actual development, in order to project can be stable and safe on-line, we will generally be divided into several environments:

Development environment: local development, debugging environment
Test environment: we complete the local development, the code will be deployed to our test server, for testing
Production environment: the test passed, the code will be deployed to the official server, the official on-line

Some of the more rigorous tests will have pre-production environments, etc.

Our configuration should be specific to the environment, so of course our configuration should not be the same for different environments.

Purpose

We need to be clear about what the fundamental purpose of the development environment is.

The fundamental purpose of the development environment is to quickly locate problems during the development process, to see the effect of debugging faster, and to improve development efficiency.

Especially as a front-end, inseparable from the visual dealings. We can't wait to Ctrl+S, immediately after the effect, so that we can quickly debug. Imagine if every time we write an effect, we have to wait for a few seconds before we can see it, will this drive us crazy?

Ideas

Therefore, in order for us to see the effect debugging as soon as possible, reducing the webpack compilation process, development environment, the configuration should be everything from simple:

For styles, we don't need to separate them and insert them directly into the <head /> with the style-loader.
For js, img, media, font and other front-end resource files, we don't need to separate them.
Enable source map to locate the problem.
Use the devServer configuration provided by webpack for local development.
Don't compress code.
Don't use unnecessary loader and plugins.
...

Development environment configuration is also different from person to person, this is what I do. But we should remember that development environment, configuration should be kept simple, in order to let us see the results faster, improve development efficiency!

Development environment configuration

First experience

Through the previous explanation, I believe you are familiar with the basic configuration of webpack:

Handling css, less, front-end resources and other files
Compiling es6+ syntax and api.
Processing html files

have mastered the relevant configuration methods, and we also summarized a basic configuration, not too clear students can look at the first, this basic configuration is still quite important.

ok, then we first use learn-08 this case to experience how to do local development debugging. In order to be as close as possible to our real-life development projects, the case will:

refer to the image in html.
use less to reference an image
use es6+ in js to load images dynamically.
Use the devServer configuration item.

For ease of reading, I'm not going to put the source code in the article, you can go to github to see it.

Then perform the following steps:

for semantic purposes, we name the webpack configuration file webpack.dev.js
Start webpack on the command line - npm start.

"scripts": {
    "start": "webpack server --config ./webpack.dev.js"
}

Run the results:

We will find:

After the file compilation and processing is complete, no file is outputted
At this point, an internal server (http://192.168.0.196:8080/) is turned on. If we are on the same network as our computer, we can access this link from our phone and see the results. This is very efficient for debugging H5 development (this is mainly due to the deveServer configuration item, which will be explained later on)
The page is updated in real time after we change the code

The above is pretty much what we want for efficient development.

Analyzing

After the initial experience, let's take a look at how to configure the development environment based on the development environment configuration ideas summarized above:

Parsing styles does not require separating out the css file; we insert the parsed styles directly into the <header />:

module: {
    rules: [
        {
            test: /.(css|less)$/, 
            use: [
                'style-loader',
                'css-loader',
                'less-loader'
            ]
        },
    ]
},

For js, img, media, font and other front-end resource files, there is no need to subpackage:

output: {
    path: path.resolve(__dirname, './dist'),
    filename: '[name]-[chunkhash:5].js',
},
module: {
    rules: [
        {
            test: /\.(png|svg|jpg|jpeg|gif)$/i,
            type: 'asset',
            parser: {
                dataUrlCondition: {
                    maxSize: 1024 * 3 // When the image size is < 3kb it will be converted to base64
                }
            },
            generator: {
                filename: '[name]-[hash:5][ext]' // Set the name of the output file
            }
        },
        {
            test: /\.m?js$/,
            exclude: /(node_modules|bower_components)/,
            use: {
                loader: 'babel-loader'
            }
        }
    ]
},

Enable source map to make it easier to locate the problem; and not compress the code:

{
    mode: 'development',
    devtool: 'inline-cheap-module-source-map'
}

Use the devServer provided with webpack for local development:

devServer: {
    static: {
        directory: path.join(__dirname, 'static'),
    },
},

No other extra plugins were installed, only the plugin that parses html was installed because it parses html:

plugins: [
    new HtmlWebpackPlugin({
        filename: path.resolve(__dirname, './dist/[name].html'),
        template: path.resolve(__dirname, './src/index.html'),
        title: 'webpack.dev.config',
    })
],

If we compare the base configuration, we will find that the development environment configuration is almost the same as the base configuration, except that the devServer configuration item is used more to enable local server debugging:

// webpack.dev.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
+   mode: 'development',
+   devtool: 'inline-cheap-module-source-map',
    entry: {
        index: './src/index.js'
    },
    output: {
        path: path.resolve(__dirname, './dist'),
        filename: '[name]-[chunkhash:5].js',
    },
    module: {
        rules: [
            {
                test: /.(css|less)$/, 
                use: [
                    'style-loader',
                    'css-loader',
                    'less-loader'
                ]
            },
            {
                test: /\.(png|svg|jpg|jpeg|gif)$/i,
                type: 'asset',
                parser: {
                    dataUrlCondition: {
                        maxSize: 1024 * 3 // When the image size is < 3kb it will be converted to base64
                    }
                },
                generator: {
                    filename: '[name]-[contenthash:5][ext][query]' // Set the name of the output file
                }
            },
            {
                test: /\.m?js$/,
                exclude: /(node_modules|bower_components)/,
                use: {
                    loader: 'babel-loader'
                }
            }
        ]
    },
    plugins: [
        new HtmlWebpackPlugin({
            filename: path.resolve(__dirname, './dist/[name].html'),
            template: path.resolve(__dirname, './src/index.html'),
            title: 'webpack.dev.config',
        })
    ],
+   devServer: {
+       static: {
+           directory: path.join(__dirname, 'static'),
+       },
+   }
}

devServer

Remember our previous case, how we ran our code? We ran it with our own editor (vscode) to see the results after we had packaged it. If we were that inefficient, we wouldn't be able to go live with our project.

That's why webpack provides a very user-friendly configuration item called devServer.

To use it, we need to install the webpack-dev-server dependency npm i webpack-dev-server -D.

From such a semantic name, we know that it must be a configuration that provides some kind of service in the development environment.

The service is that this will enable a local service that will compile our configured webpack, in real time, and save it in memory, so that we can easily debug our code, which serves the purpose of our local development needs to be efficient very well.

So this configuration item, only used for our development environment configuration.

devServer.static

Documentation Explanation: tells the server where to serve content from. This is only necessary if you wish to serve static files

Misinterpretation

The devServe configuration item is actually written in quite a bit of detail in the documentation, so here's a potentially confusing one - devServe.static.

A lot of people use webpack and copy and paste, so it's common to see configurations like the following:

output: {
    path: path.resolve(__dirname, '. /dist'), .
}
devServer: {
    static: {
      directory: path.join(__dirname, 'dist'), }
    }
}

Because the folder we set up for output after packaging is generally dist, the devServe.static configuration item specifies that the directory of static files to be served is also dist. So, we would naturally assume that the contents of the local server access opened by webpack at this point would be the contents inside the dist folder.

Therefore, we would incorrectly conclude that devServe.static serves to set the directory that is accessed by the local server when webpack is turned on.

However, we can look at dev.config.js above, where we set the name of the folder we output after packaging to dist, and the directory set by devServe.static is static. If we follow our misinterpretation above, we should have a 404 or a blank page on our server at this point due to the difference in the two folder settings, but we can still run our service.

This means that devServe.static is not setting the directory where the packaged output folder is accessed when webpack is turned on for the local server.

Correctly understood

Analysis

Let's move on to the learn-08 case (the static folder holds the logo.png image inside).

We previously wanted to reference the image in question inside js, which we typically do:

// index.js
const img = new Image();
img.src = require('Your image path');

We normally require the image according to the relative path, which is equivalent to a module, so the image will be compiled by webpack (adding hash or converting it to base64), and then written to the final directory (output.path) that we have set up.

But when we set up:

devServer: {
    static: {
      directory: path.join(__dirname, 'static'),
    }
}

After opening the local server, this line prompts:

Content not from webpack is served from 'your path/static' directory

First of all, this means that the static directory we set up will not be processed and packaged by webpack, so the resources in this folder will not be parsed and compiled by webpack, and therefore it will not be hashed or converted to base64.

Let's take a look at how index.js from learn-08 uses the resources in static:

// index.js
loadImage('./logo.png').then(img => {
    console.log('I am from index.js');
    img.width = 120;
    document.querySelector('#js_content .img_content').append(img);
});

We will see that we are introducing the image directly using the ./ way to bring in the image, indicating that webpack has a local server turned on that will map the contents of the static directory we set up to the root directory.

If you've used vue-cli before, you'll appreciate that this is what the public folder in vue-cli does.

We can access the contents of the set devServer.static.directory folder in the following way:

Normally devServer.static.directory is mapped to the root directory, so we access it using http://[devServer.host]:[devServer.port]/[devServer.static.directory]
If you want to change the access path, you can add devServer.static.publicPath configuration. In this case, you can use http://[devServer.host]:[devServer.port]/[devServer.static.publicPath]/[devServer.static.directory] for accessing

Summary

After analyzing the explanation above, we can conclude that the correct understanding of devServer.static should be:

It is a directory for static resources that are not compiled by webpack (e.g., images, third-party resources, etc.), so it won't be hashed or base64; it is a directory.
When opening a webpack local server, it is usually mapped to the root directory of our project (you can change the access directory via devServe.static.publicPath)
Since it's not compiled and packaged by webpack, we usually end up copying devServer.static.directory to the root of output.path with copy-webpack-plugin
It functions much like the public folder inside vue-cli, which we can use when we develop via ./ or ../ to access that resource (depending on the directory relationship).

Core

Okay, so we know from the above explanation of the development environment configuration and devServer:

The development environment configuration is kept simple, so resources such as img, js, etc. are mapped directly to the root directory (css is inserted into <head />).
The development environment webpack also maps devServer.static.directory to the root directory when the local server is enabled.

So after running the development environment configuration, our structure directory is roughly as follows:

dist
├── ecj-cli-b6fa8.png
├── index-c466b.js
├── index.html
└── logo.png

Configuration varies from person to person, the most important thing is that after we configure the development environment, production environment, the compilation and packaging of output content, directory, a good understanding of the structure of the mind, which is very important.

It is very important that we have a good understanding of the directory structure of the compiled and packaged output, which is very important.

We can see the structure of the development environment by the following method:

devServer.devMiddleware.writeToDisk: true
http://[devServer.host]:[devServer.port]/webpack-dev-server
Chrome F12 -> Sources

Finally

This article learned how to configure the development environment, the next article will explain the configuration of the production environment before some of the preparations, so that we can better learn the production environment configuration
The cases covered in the article have been uploaded to github, and you are really welcome to star or fork them.
You can support me by following my github!

Regarding the content of the article, if you have similarities and differences, feel free to discuss them in the comments section!

You'll be more productive learning webpack with these methods

Lee — Tue, 11 Jul 2023 09:42:00 +0000

Preface

As explained in the previous article - Take your webpack to the next level by understanding these concepts, we have a general understanding:

Some of the concepts that arise in using webpack process
Combined with the concepts of the packaging process, we analyzed the webpack packaging process, so that we can have a general understanding of the packaging process.

We all know that in the actual development process, we use webpack only to finally output css, img, js, html and other front-end resources that the browser can run.

So, in order to be more close to the actual situation, in this article, we will learn how to configure webpack with the purpose of how to output css, img, js, html and other front-end resources.

Learning Outline

This article explains the following basic configuration:

Handling css, less files
Handling img, font, audio and other front-end resource files.
Compiling es6+ syntax and API.
Processing html files

The webpack documentation is pretty detailed, so I don't want to copy and paste it and write it all over again, so it's better to just read the documentation.

Learning can't be learned the hard way, there should be some methods and techniques. Therefore, I would like to summarize some methods in the process of explaining the configuration, so that we can better understand the configuration of webpack. In this way, some similar configurations, we can match them by looking at the documentation.

Remarks

The article has been uploaded to github:

For the sake of reading convenience, the article only posted the relevant code, it is recommended to fork it to see the complete code; or follow the article together with the side of the knock, so that the impression will be more profound!
It's not easy to create, if you think it's helpful, welcome to star🌟!

Handling `css, less` files

Let's start with the learn-03 case to see how webpack handles style files.

We install the appropriate loader to parse them:

less-loader: parses less into css.
css-loader: parses css into valid modules recognized by webpack.
style-loader: parses css and inserts it into <header />.

npm install less less-loader css-loader style-loader -D

Then configure it:

// webpack.config.js
module.exports = {
    ...,
    module: {
        rules: [
            {
                test: /.(css|less)$/, 
                use: [
                    'style-loader',
                    'css-loader',
                    'less-loader',
                ],
            },
        ]
    }
}

The parsing of loader is performed in reverse order (or right-to-left), so this configuration will be performed in the following order (less-loader → css-loader → style-loader):

parses less into css.
pass the result to css-loader, which parses it into a valid module recognized by webpack.
passes the result to style-loader, which inserts the parsed styles into <header />) in the following order.

The less, css, and entry file code is:

// index.less
*{
    margin: 0;
    padding: 0;
}
h1{
    color: red;
    margin-top: 20px;
}

/* index.css */
h2{
    color: green;
}

// index.js
import './assets/index.less';
import './assets/index.css';

Output:

We'll see that the style we wrote was processed successfully and inserted into the <head/>.

Summary

We previous post said:

The resource files that we come in via import or require, or each file in our project, can be viewed as an individual module
The role of the Loader is to convert these modules into valid modules that webpack recognizes.

webpack humanely exposes the module configuration item, which is specifically designed to configure the relevant loader to parse the corresponding module. So if we want to parse some module used in our source code, we should:

download the appropriate loader first
Find the module configuration directly and configure it according to the loader usage.

So, we can try to configure our own .scss or .txt files according to the above summarized methods and ideas.

OK, we successfully got the styles (css) we need for our project, next we will see how to deal with images (img) and other front-end resource files.

Handling front-end resource files

There are a lot of front-end resource files, here, we roughly divide them into two categories first:

Common class: img, font, video and so on.
Special category: .csv, .xml and so on.

These resources are also modules as long as they are imported or required into our source code. Since they are modules, we need to install the appropriate loader to parse them, and then configure them in the module configuration.

Prior to wepack5, For resources of commonly used classes, we generally needed to install the following loader to parse them:

raw-loader: parses files into strings
file-loader: parses files coming in from import/require() into a fully referenced url and sends the file to the output directory
url-loader: can convert files to base64.

We often use file-loader and url-loader. This is because common resources are often introduced into our projects as url, or converted to base64 in order to reduce http requests.

But after webpack5, webpack has built-in the functions of the above several loaders, so we can no longer need to install the above loaders; we can directly use webpack's own asset module.

The resource module built in after webpack5:

asset/source: equivalent to raw-loader.
asset/resource: equivalent to file-loader.
asset/inline: equivalent to a url-loader.
asset: more flexible, has both asset/resource and asset/inline. If you set a file size limit, the file will be converted to base64 if it doesn't exceed the limit; if you don't set a size limit, it works the same as file-loader.

This is why I love webpack5 so much, because we don't have to install so many messy loaders.

Let's use the case of learn-04 to see how we can use the resource module to parse our front-end resources.

Let's add the configuration from the previous chapter on parsing styles together and use the image resources in less and js respectively.

We have two images:

preview.gif: size 349kb
ecj-cli.png: size 4kb.

// webpack.config.js
module.exports = {
 ...,
 module: {
        rules: [
            {
                test: /.(css|less)$/, 
                use: [
                    'style-loader',
                    'css-loader',
                    'less-loader',
                ],
            },
            {
                test: /\.(png|svg|jpg|jpeg|gif)$/i,
                type: 'asset',
                parser: {
                    dataUrlCondition: {
                      maxSize: 1024 * 10 // // When the image size is < 10kb it will be converted to base64
                    }
                },
                generator: {
                    filename: '[name][ext]' // Set the name of the output file
                }
            }
        ]
    }
}

Entry file:

// index.js
import './assets/index.less';

const img = new Image();
img.src = require('./assets/ecj-cli.png');
img.width = 500;
document.querySelector('#js_logo').append(img);

Style:

.bg_logo{
    width: (1434/3px);
    height: (1212/3px);
    background-image: url('./preview.gif');
    background-size: 100%;
}

Output results:

We'll see that the style and js both process the image successfully:

preview.gif is larger than 10kb, so instead of being converted to base64, a full reference path is returned (equivalent to file-loader)
ejc-cli.png is smaller than 10kb so it was converted to base64 (equivalent to url-loader)

The gif above is a command line tool ejc-cli that I developed that is very useful in everyday projects. It can convert the Excel data collected by the docking staff into json data in a certain format which is needed by our code. It is very convenient for us to develop and maintain the data, and also to interface with other people.

If you are interested, you can check out 👉🏻 learn about ejc-cli

Summary

Resources that are imported into our source code via import or require are also modules. So you need to download the appropriate loader and configure it in the module configuration.

For common resources (img, font, video, audio, etc.):

Because they are commonly used, webpack5 has built-in functionality to handle them, so that we don't need to install an additional loader, and we use the asset module to manage them directly.
We generally use asset/resource, asset/inline, asset modules to manage common class resources. Because the resources of our common classes are often introduced in our projects, we need to parse them to introduce the full url, or convert them to base64 in order to reduce the number of http requests.

For special classes of resources (.csv, .xml, etc.):

We can understand that because they are not commonly used, webpack does not have their functionality built in.
Therefore, we need to install the appropriate loader to parse them. For example, if we want to parse a .csv file, we need to install the csv-loader to parse it.

We can try to configure ourselves to handle .video or font as summarized above.

OK, so far, we've got css, img. Let's see how we can get our js through webpack processing.

Compiling `es6+`

To this day, js is evolving rapidly, and every year some new syntax or new API appears in order to improve development efficiency and code quality.

For example, in terms of syntax appeared:

Arrow functions: ()=>
class syntactic sugar: class People {}
Deconstructed assignment: const [x, y] = [1, 2];
...

On the API side again:

Promise
Array.prototype.includes()
Object.keys()
...

But these new additions are not supported on some lower browsers, so we need to use webpack to compile our es6+ into a version that these lower browsers can support.

Let's start with the learn-05 case and see how we configure webpack to compile es6+.

We install the relevant dependencies:

...
"devDependencies": {
    "@babel/core": "^7.22.8",
    "@babel/plugin-transform-runtime": "^7.22.7",
    "@babel/preset-env": "^7.22.7",
    "babel-loader": "^9.1.3",
    "webpack": "^5.88.1",
    "webpack-cli": "^5.1.4"
},
"dependencies": {
    "core-js": "^3.31.1"
},

Entry files. Uses es6+ syntax such as class, Promise, ()=>{} and API:

// index.js
class People {
    constructor(name) {
        this.name = name;
    }
    sayHi() {
        return Promise.resolve(this.name);
    }
}
const Lee = new People('Lee');
Lee.sayHi().then(name => console.log(`Hi, I am ${name}.`));

Configure webpack:

// webpack.config.js
module.exports = {
    ...,
    module: {
        rules: [
            {
                test: /\.m?js$/,
                exclude: /(node_modules|bower_components)/,
                use: {
                    loader: 'babel-loader'
                }
            }
        ]
    }
}

Configure Babel. Create a new babel.config.js file in the project root directory:

// babel.config.js
const presets = [
    [
        '@babel/preset-env',
        {
            useBuiltIns: 'usage',
            corejs: {
                version: require('core-js/package.json').version,
                proposals: true
            }
        }
    ]
];
const plugins = [
    '@babel/plugin-transform-runtime',
];
module.exports = {presets, plugins}

Set the target browser to be compatible with. Add the browserslist field to package.json:

"browserslist": [
    "ie 11"
]

The result of running it in ie 11:

We will find:

The es6+ we wrote runs successfully in ie 11.
Promise, the es6+ API, has also been added to ie 11.

It means that our compilation of es6+ was successful.

About `Babel`

In the configuration above, you will notice that if we want to compile es6+ with webpack, we also need to add the babel.config.js file to the root directory, which is a much more complicated and troublesome step than dealing with other modules. This is because compiling the core of es6+ requires Babel to work with it. Babel is a tool for compiling es6+.

Since this post is mainly about webpack, we'll just give a general mention of Babel here. Here are some common configurations for Babel.

If the project we are developing is an application or a large project, we can configure it like this:

const presets = [
    [
        '@babel/preset-env',
        {
            modules: false,
            useBuiltIns: 'entry', // or useBuiltIns: 'usage',
            corejs: {
                version: '3.27.2',
                proposals: true
            }
        }
    ]
];
const plugins = [
    '@babel/plugin-transform-runtime'
];
module.exports = {plugins, presets};

// index.js
// If use useBuiltIns: 'entry'
import 'core-js/stable'

If we are trying to develop a third party library, we can configure it like this:

// Babel配置
const presets = [
    [
        '@babel/preset-env',
        {
            modules: false
        }
    ]
];
const plugins = [
    [
        '@babel/plugin-transform-runtime',
        {
            corejs: {
                version: 3,
                proposals: true
            }
        }
    ]
];
module.exports = {plugins, presets};

Summary

If js is imported or required into our source code, then it is also a module. So we have to download the corresponding loader (babel-loader) and configure it in the module configuration.
In addition, we need to configure babel-loader and, most importantly, Babel (babel.config.js).

So, if we want to "compile es6+", we need to configure webapck, and most importantly we need to configure babel.config.js. If you don't want to just copy and paste the Babel configuration, you have to learn about Babel.

Remember what we use webpack for? To output css, img, js, html and other front-end resources that the browser can run.

OK, so far we have processed css, img, js through webpack. Let's take a look at how we can get our html through webpack processing.

Processing `html` files

In the above example, we want to see the effect in the browser, we need to:

Create a new html file in the root directory.
In the new html file, we need to bring in the packaged resource files manually.

This process is too troublesome, is there a way, we just provide a html template file, and then through the webpack compilation, it automatically help us to pack the packaged files into the good. This way, we can run html directly after packaging and see the effect in the browser.

webpack is so user-friendly, of course there is.

Let's start by using the learn-06 example here to see how we can utilize webpack to achieve the results we described above.

Install the relevant plugins:

npm i html-webpack-plugin -D

This time, the webpack configuration is a little different:
We set the packaged js storage directory to be the js folder; and we add a hash value of 5 lengths to the packaged js name.

// webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin');
const path = require('path');

module.exports = {
    entry: {
        index: './src/index.js'
    },
    output: {
        path: path.resolve(__dirname, './dist'),
        filename: './js/[name]-[chunkhash:5].js',
        clean: true
    },

    plugins: [
        new HtmlWebpackPlugin({
            filename: path.resolve(__dirname, './dist/[name].html'),
            template: path.resolve(__dirname, './index.html'),
            title: 'HtmlWebpackPlugin',
        })
    ],
}

The structure of the packaged file is:

dist
├── index.html
└── js
    └── index-efbfd.js

The packaged html is as follows:

We will find:

Our html and js are packaged and exported to the dist folder, which is very convenient for us to deploy (before we created index.html in the root directory, so there are only img and js files in the dist folder after packaging).
The packaged html will automatically bring in our packaged js file for us.

Analyzing

As we can see from the above example, if we want webpack to process html files, we need to configure it in plugins provided by webpack. Some of you may wonder why html is a module and why it is configured in plugins and not in module. Let's analyze it.

All the files of our project can be considered as a module, but whether we configure them in module or plugins depends on what we want to use them for. Generally, if we use the module in our own source code, we need a Loader to parse it**.

When we explained how to deal with img and js above, our purpose was to parse these files in the source code:

img, which we need to convert to base64
js, we need to compile es6+ stuff into es5 and below

And, our files are introduced into our project by import or require(), so of course we need the appropriate Loader to convert these modules.

But when dealing with html files, our purpose is not to parse the html, we just want the packaged html to automatically reference our js and img, which is more like using the auto-introduction feature; moreover, we don't introduce our html into our project, so of course we don't need the appropriate Loader to parse it.

Remember from our previous post we explained that Loader is used to transform the modules, and Plugin is used to enhance the webpack package when compiling.

In this case, we are dealing with the html file, and our goal is to make the packaged html automatically reference our js and img. So we need to configure the plugins configuration item to enhance the webpack packaging and compilation functionality.

Similarly, suppose we want to parse an html file in our project (in our project, import html from '. /x.html'), then we have to install the appropriate loader (html-loader) and configure it in the module configuration item.

Summary

Whether to configure in the module or plugins configuration item depends on the purpose for which we are using these modules.

At this point, we have successfully configured webpack to get the css, img, js, and html we need for a project; this is also equivalent to learning the basic configuration of webpack.

You can use the methods summarized above to handle sass, font, video and other resources on your own to deepen your impression.

Learning Summary

From the above explanation of some configuration items, we can have the following summary:

To parse css, we need to install the loader and configure it in the module.
To parse img, font, video, etc., we don't need to install the loader (webpack has built-in functionality to parse them). We usually use asset/resource, asset/inline, asset in module configuration to parse them.
To parse js, we need to install the appropriate loader (babel-loader), configure it in the module configuration, and most importantly, learn about Babel.
To parse the html file, we need to configure the html-webpack-plugin plugin in the plugins configuration field.
Whether we configure it in the module or plugins configuration depends on what we want to do with the modules.

With the above learning, let's organize and output a complete webpack base configuration to make it more impressive:

const HtmlWebpackPlugin = require('html-webpack-plugin');
const path = require('path');

module.exports = {
    entry: {
        index: './src/index.js'
    },
    output: {
        path: path.resolve(__dirname, './dist'),
        filename: './js/[name]-[chunkhash:5].js',
        clean: true
    },
    module: {
        rules: [
            {
                test: /.(css|less)$/, 
                use: [
                    'style-loader',
                    'css-loader',
                    'less-loader',
                ],
            },
            {
                test: /\.(png|svg|jpg|jpeg|gif)$/i,
                type: 'asset',
                parser: {
                    dataUrlCondition: {
                        maxSize: 1024 * 10 // When the image size is < 10kb it will be converted to base64
                    }
                },
                generator: {
                    filename: '[name]-[hash:5][ext]' // Set the name of the output file
                }
            },
            {
                test: /\.m?js$/,
                exclude: /(node_modules|bower_components)/,
                use: {
                    loader: 'babel-loader'
                }
            }
        ]
    },
    plugins: [
        new HtmlWebpackPlugin({
            filename: path.resolve(__dirname, './dist/[name].html'),
            template: path.resolve(__dirname, './src/index.html'),
            title: 'Webpack Basic Configuration',
        })
    ],
}

The full base configuration is at learn-07, and we recommend that you take a look at the full version, only webpack.config.js is posted here.

Finally

I hope some of the methods summarized in this article for learning purposes will help you learn how to configure webapck better.
Later articles will be in-depth configuration. In real projects, most of them are divided into development and production environments, so we will learn how to configure webpack differently for different environments of development and production, which is closer to our real projects.
You can support me by following my github!

Regarding the content of the article, if you have similarities and differences, feel free to discuss them in the comments section!

Take your webpack to the next level by understanding these concepts

Lee — Mon, 26 Jun 2023 15:03:27 +0000

What is webpack?

It is a packaging tool:

It can take the es6+ js, less, sass, img, font and many other module resource files in our source code, and compile them through a series of processing to create front-end resources such as css, js, html that our browsers can recognize and run
At the same time, it also provides many highly configurable features (tree shaking, code-splitting, module hot-replacement) to help us better optimize the management of our code and resources

Remarks

The article has been uploaded to github:

For the sake of reading convenience, the article only posted the relevant code, it is recommended to fork it to see the complete code; or follow the article together with the side of the knock, so that the impression will be more profound!
It's not easy to create, if you think it's helpful, welcome to star🌟!

webpack.config.js

Let's take a look at the general framework of this configuration file to get an idea of what it looks like:

// webpack.config.js
module.exports = {
  entry: {},
  output: {},
  resolve: {},
  module: {},
  plugins: [],
  optimization: {},
  devServer: {}
};

webapck of course also supports many configuration items, but we usually use the general on these few, other configuration items can see documentation

Attention:

webpack configuration file, the code inside is free to play around with, and the name of the configuration file doesn't have to be webpack.config.js, just make sure that the final output is a webpack configured object:

// myconfig.js

// Various logic codes
...
...

// Just make sure to export a `webpack` configured object at the end
module.exports = {
    entry: {},
    output: {},
    ....
}

"build": "webpack --config myconfig.js"

Optimization

All the configurations are written in one file, which is not good for our maintenance and development; and when we develop a project, there are multiple environments (local development environment, test environment, production environment), so we usually have a configuration file for different environments, and a configuration file that is common to all environments.

We usually merge the "common configuration file" with the "different environment configuration file", and then webpack will run the merged configuration file.

Configuration files are generally available as follows:

Common configuration for development and production environments (webpack.common.js)
Development environment configuration (webpack.dev.js)
Production environment configuration (webpack.pro.js)

Subsequent articles will teach you how to do this configuration method.

entry

It refers to the starting point where webpack starts parsing and building the dependency graph. We generally configure entry in the form of a {key: value} object, e.g:

module.exports = {
 entry: {
   index: '. /src/index.js'.
   share: '. /src/share.js'.
 }
}

This means:

We have two entry points in our project index, share
webpack will start building the modules they depend on from the index and share portals, thus forming a dependency graph (more on this later)
After packaging, the packaged file will be named with key.

output

It's easy to understand, it sets the name of the compiled file after webpack packaging and where it should be output to.

Note that even if we set multiple entry entries, we can only specify one output configuration.

Module

The resource files we bring in via import or require, or each file in our project, can be seen as a separate module. So, it can be a js file, a css file, or any kind of resource such as an image. So we often see the following statement in our development:

import 'index.css'
import A from './x.js'
import pic from './x.png'
...

The combination of modules will in turn form a Chunk. Chunk is a very important concept and will be discussed in detail later.

Reference article: Modules

Loader

As we know from above, each file in the project can be considered as a module, and since we have a variety of file types, we need something that can parse these modules into valid modules that webpack can recognize and add them to the dependency graph, and that something is Loader.

webpack is also kind enough to provide us with a module configuration item, which is specifically used to configure different loaders to parse different file types (modules). This is because webpack can only parse js and json files by default, so if we want to parse different types of files (modules), we have to install the corresponding loader:

// webpack.config.js
module.exports = {
 ...,
 modules: {
  rules: [
    // Parsing .txt files, using raw-loader
    { test: /.txt$/, use: 'raw-loader' },
  ],
 }
}

The loader has two properties:

The test property, which identifies which files will be converted.
The use property, which defines which loader should be used when doing the conversion.

What other loaders are available in webpack can be seen here

Plugin

Loader is used to transform modules, Plugin is used to enhance the functionality of webpack when it is packaged and compiled. So it generally has functions like packaging optimization, resource management, injection of environment variables, etc.

Because webpack is also kind enough to provide us with a plugin configuration item, we can just go to plugin and configure what features we want to enhance, for example, if we define some global variables directly in our project:

// webpack.config.js
module.exports = {
 ...,
 plugins: [
  new webpack.DefinePlugin({
   AUTHOR_NAME: JSON.stringify('Lee')
  })
 ]
}

// index.js
console.log(AUTHOR_NAME); // Lee

You can check here to see what other plugins are available.

Dependency graph

When we have a file that depends on another file, webpack treats the file as having a direct "dependency".

As a simple example, let's say we have three files that have the following relationship:

// main.js
import './index.js';

// index.js
import 'plugin.js'
console.log('I am from index.js');

// plugin.js
console.log('I am plugin.js');

Let's analyze:

main.js, index.js, plugin.js are equivalent to three modules;
then main.js introduces index.js, and index.js introduces plugin.js;
so all three files have a cross-reference relationship;
a graph with references is formed as follows: main.js → index.js → plugin.js

To summarize:

webpack will start with entry and use it as the starting point of the dependency graph; then analyze and process the import inside entry and keep recursively querying the dependencies similar to the above example, this process will finally form a graph with dependencies, this graph is the "dependency graph ".

webpack will then operate further based on this dependency graph.

⭐️ Chunk

Chunk is a relatively important concept inside webapck, if we understand it, we will have a good understanding of the whole process of webpack packaging, code partitioning.

Explanation

In the webpack packaging process, a module or a group of modules (any of the files in webpack that we mentioned above can be considered as a module) will be combined into a whole, then this whole can be treated as a Chunk. Generally speaking, the webpack packaging process has several Chunks and will end up outputting several js files.

Let's go through the case learn-01, which is the simplest configuration, the simplest code, so that we can better understand what Chunk is.

We have three js files:

index.js: the entry file
async.js: file for asynchronous introduction
vendors.js: you can use it as some third-party dependency file

The file code and webpack configuration are as follows:

// webpack.config.js
module.exports = {
    entry: {
        index: './src/index.js'
    },
    output: {
        filename: '[name]-bundle.js'
    }
}

// index.js
import './vendors';
import(/* webpackChunkName: "async" */ './async');
console.log('I am from index.js');

// async.js
console.log('I am from async.js');

// vendors.js
console.log('I am from vendors.js');

When we see this, we can first guess how many files are packed out.

Analysis

Let's first analyze the packaged files and their structure:

dist
├── async-bundle.js
└── index-bundle.js

A total of two js files are output.

From the above, we know that

Each file can be seen as a module
In the webpack packaging process, a module or a group of modules will be combined into a whole, then this whole can be treated as a Chunk

We proceed to analyze:

By looking at the dist/index-bundle.js file, we will find that it contains js files that are not introduced asynchronously: the entry files index.js, vendors.js (and some code that was added by webpack itself when it was packaged runtime). This means that the two modules index.js and vendors.js form a Chunk. Here we call it chunk[initial];
By looking at the async-bundle.js file, it only contains the code for async.js. This means that the module introduced asynchronously is split into a separate Chunk. Here we call this Chunk chunk[no-initial]
Both chunk[initial] and chunk[no-initial] come from the same entry index.js, so the two Chunks combined can be seen as a Chunk group, or the entry files will form a whole Chunk group. We call it Chunk[index]

Okay, I believe that by now, you should have a general impression of Chunk formation, let's run through the process again.

When webpack is compiled, through our configuration:

it will first find enrty, there are several entry, it will use these entry to form a Chunk group (Chunk[index] in the example)
then analyze these Chunk group, the entry js and all the related dependency modules of this entry, to form a chunk (chunk[initial] in the example)
if there is an asynchronous introduction of the module, the module is a separate Chunk (chunk[no-initial] in the example)
finally package the output chunk[initial] (index-bundle.js), chunk[no-initial] (async-bundle.js)

In the above example, chunk, module are related as follows:

Form

From the above analysis, we can know that Chunk has two forms:

initial: the initial one. Our entry js and all the related dependency modules of this entry, combined into a collection, can be seen as a Chunk. (i.e. chunk[initial] composed of index.js, vendors.js above)
non-initial: non-initial. Indicates that it is an asynchronously loaded module, if we use something like import('. /A.js'), this js will be split into a separate asynchronous Chunk. (i.e. the chunk[no-initial] composed of async.js above)

How to generate Chunk

With the entry configuration, a Chunk group is generated with the entry as a whole (this group will not be packed out, it will just form this Chunk group)
Generate initial Chunk with our entry js and all related dependency modules of this entry
Generate non-initial Chunk by asynchronous import()
Generate other chunk through webpack powerful code splitting

Through the above explanation and analysis, I hope you can have a rough process of Chunk formation in your mind when you use webpack in the future, which is very helpful for us to use code splitting.

Reference article: Revealing internal principles

Bundle

Bundle refers to all the products of webpack after packaging.

If our output configuration output file directory is dist, our Bundle is all the products in the dist folder.

Generally speaking there are a few Chunks and a few js bundle files packaged out.

Packing process

A brief analysis

In order to better understand the concepts parsed above, let's take a look at the webpack packaging process and see in which processes the concepts above are reflected.

After we run webpack in the terminal, it will go through the following process:

read the configuration file we specified (webpack.config.js)
start with the entry entry, analyze our Module and recurse the dependencies between the modules of our entire project
Load the appropriate Loader, parse these Modules into valid modules recognized by webpack and add them to the Dependency graph.
the compilation process will trigger several events to execute the configured Plugin.
the analyzed modules are grouped to form Chunk.
according to the configuration file (output), the final Bundle is output

The above process can be seen as three phases:

Initialization phase (process 1)
Compilation phase (process 2 - process 5)
Output phase (process 6)

The actual packaging process of webpack is of course much more complex, and here, for better understanding, is simplified

Experience

Let's start from the practical side, with the case learn-02, and use the actual code to have a deeper experience to understand the webpack packaging process and the concepts involved.

Let's take a look at the learn-02 project structure:

learn-02
├── index.html
├── package-lock.json
├── package.json
├── project.config.js
└── src
    ├── assets
    │   └── style.less
    ├── index.js
    ├── plugin
    │   ├── common.js
    │   ├── index-vendors.js
    │   └── share-vendors.js
    └── share.js

Let's introduce the corresponding files:

index.html: used to run our packaged files and see the results
project.config.js: the webpack configuration file (a separate name to distinguish it from webpack.config.js)
style.less: style
index.js: entry file
share.js: entry file
common.js: holds the common methods, which will be referenced twice by the two entry files, respectively
index-vendors.js: can be used as some dependencies of index.js
share-vendors.js: can be used as some dependencies of share.js

Relevant code from the following projects:

After we see the configuration of project.config.js, we can later guess how many files will be output after packaging as well.

Okay, now let's start the analysis:

1️⃣ When we run npm run build in the terminal, webpack will read the file project.config.js that we specified

2️⃣ Starting with entry, we analyze our module. Our entry has two index, share, so this will form two Chunk groups: Chunk[index], Chunk[share], and recurse our module's corresponding dependencies.

3️⃣ index.js introduces style.less, so it will load the corresponding Loader, parse it into a valid module that webpack can recognize, and add it to the dependency graph. This results in two dependency graphs:

A dependency graph consisting of the entry index.js and its dependencies (index.js -> style.less, common.js, index-vendors.js)
A dependency graph consisting of the entry share.js and its dependencies (share.js -> common.js, share-vendors.js)

4️⃣ These modules are then grouped into:

A chunk[initial-index] composed of the entry index.js and its dependencies;
A chunk[initial-share] composed of the entry share.js and its dependencies

5️⃣ found that our configuration also splits commonjs independently using code splitting, so it forms a separate chunk[initial-common]

6️⃣ At this point, webpack has split into three chunks:

chunk[initial-index]
chunk[initial-share]
chunk[initial-common]

7️⃣ Final output Bundle according to output

Again, the actual packing process is certainly much more complex

Finally

This article analyzes and explains some of the concepts involved in webpack, especially the knowledge of Chunk is more important. After understanding Chunk, you will definitely have a better understanding of webpack. Hopefully, after reading this article, we will have a general process in mind when using webpack, and we will be able to tell how many Chunks there are.
The following article will start to teach you how to configure webpack, if you are interested you can stay tuned!
You can support me by following my github!

Regarding the content of the article, if you have similarities and differences, feel free to discuss them in the comments section!

DEV Community: Lee

I have taken advantage of Excel's functionality to develop a CLI tool to better manage data

Practical issues

Why choose Excel to manage data

Tools are born

End

I efficiently learned "webpack development environment configuration" using this idea

Preface

Learning Outline

Remarks

Development Environment Core Ideas

Purpose

Ideas

Development environment configuration

First experience

Analyzing

devServer

devServer.static

Misinterpretation

Correctly understood

Analysis

Summary

Core

Finally

You'll be more productive learning webpack with these methods

Preface

Learning Outline

Remarks

Handling css, less files

Summary

Handling front-end resource files

Summary

Compiling es6+

About Babel

Summary

Processing html files

Analyzing

Summary

Learning Summary

Finally

Take your webpack to the next level by understanding these concepts

What is webpack?

Remarks

webpack.config.js

Attention:

Optimization

entry

output

Module

Loader

Plugin

Dependency graph

⭐️ Chunk

Explanation

Analysis

Form

How to generate Chunk

Bundle

Packing process

A brief analysis

Experience

Finally

Handling `css, less` files

Compiling `es6+`

About `Babel`

Processing `html` files