Before learning about Webpack, I felt it was important to understand the concept of modularity.

What is a module

For a long time, javascript didn’t have a module. If we want to reference other JS files in the page, we can only insert them into the page one by one with the script tag. This has a number of drawbacks, such as not being able to clearly see the dependencies between these JS files on the page. Moreover, the top-level scope in script tags is the global scope, which can cause global scope contamination, which can easily lead to naming conflicts and other issues in a large team project. Modular solved the problems above, in a modular js files, can depend on import and export statement is very clear, and the scope of each module is independent, not pollution globally, there will be no name conflict each other, greatly improved the efficiency of a large project development, maintainability. There are several modular specifications in the community, such as CommonJs,AMD,UMD and the ES6 Module released with ES6.

What is a webpack

In Webpack, each file is a separate module, and then through loader conversion, plugin injection hooks, and finally output a file composed of multiple modules. We just need to reference the final output file in the HTML file.

Look at a simple example.

Here is the directory structure

Webpack. Config. Js file

const path = require('path')

module.exports = {
    entry: {
        main: './main.js'
    },
    output: {
        path: path.join(__dirname, '/dist'),
        filename: 'bundle.js'}}Copy the code

This file is webpack’s configuration file from which WebPack reads configuration entry: the entry file that identifies the entire project. Webpack starts with this file and recursively resolves all modules output.path: Filename: specifies the name of the final output packaged file

main.js

import { foo } from './foo.js'

foo()
Copy the code

foo.js

export function foo () {
    document.write('hello webpack')}Copy the code

index.html

<! DOCTYPEhtml>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="Width = device - width, initial - scale = 1.0">
    <title>Document</title>
</head>
<body>
    <script src="./dist/bundle.js"></script>
</body>
</html> 
Copy the code

The foo.js file is referenced in the main.js entry file and the function foo is executed, which prints Hello Webpack on the page. When we execute the webpack command on the terminal, we can see that there is an additional dist directory in the project, which contains the bundle.js file generated by the package

This is the file generated when WebPack is packaged, and we import the file with script tags in the index.html file, which can be seen in the browser. As shown in figure

So far, we have implemented a simple modularity project using WebPack.

What is the loader

Webpack natively does not support parsing any non-javascript files. To parse non-javascript files, use the Loader. For example, in the example above, if we want to style the text, we need to write a CSS file. In order to load the CSS file, loader is required. Modify the webpack.config.js file as follows

const path = require('path')

module.exports = {
    entry: {
        main: './main.js'
    },
    output: {
        path: path.join(__dirname, '/dist'),
        filename: 'bundle.js'
    },
    module: {
        rules: [{test: /\.css$/,
                use: ['style-loader'.'css-loader'}]}}Copy the code

New fields: module: configures rules for processing modules rules: rules Configures read and parse rules for modules, which are usually used to configure loader. The test,include, and exclude configuration items are used to specify the file to which the loader applies the rule. The use field is then used to specify the loader to use. Note that loader executes in reverse order based on the use array. In the example above, all CSS files are handed to CSS-loader first and then to style-loader after processing.

We create a CSS file in the project and import it in the main.js file as follows

main.css

* {
    color: red;
}
Copy the code

main.js

import { foo } from './foo.js'
import './main.css'

foo()
Copy the code

Repackage it, open your browser, and you can see that the font is red

This is what loader does. For each file type, you can find the corresponding loader in the community, such as vue-loader, TS-loader, etc. You can find out for yourself.

plugin

Plugin extends the functionality of WebPack. This is achieved by injecting hooks into the build process, greatly increasing the flexibility of WebPack. Using the above configuration as an example, we import a CSS file into the project and load it with CSS-loader and style-loader. The final package still generates only one JS file. This is because all styles are incorporated into the JS file as strings. In real development, this can be detrimental to maintenance and optimization. So we want to package the CSS file into a separate file and import the CSS file separately. This need to use plugin to achieve. Modify the webpack.config.js file as follows

webpack.config.js

const path = require('path')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')

module.exports = {
    entry: {
        main: './main.js'
    },
    output: {
        path: path.join(__dirname, '/dist'),
        filename: 'bundle.js'
    },
    module: {
        rules: [{test: /\.css$/.// Replace style-loader with plug-in loader
                use: [MiniCssExtractPlugin.loader, 'css-loader']]}},plugins: [
        new MiniCssExtractPlugin({
            // The extracted CSS file name
            filename: `[name]@[hash].css`}})]Copy the code

As you can see, the plugins configuration item accepts an array. In the array are instances of each plugin. The specific configuration of plugin needs to be queried. After configuration, run webpack again to package the project, you can see an extra CSS file in the dist directory, as shown in the following figure

The name is the CSS source file name and the hash value of the file that we configured. Let’s import this file directly into index.html.

devServer

With the above configuration, we can get WebPack up and running. But in real development, every change to the code needs to be packaged, which makes our development efficiency greatly reduced. DevServer starts an HTTP server to service web requests, helps start webpack, and automatically refreshes the page through the WebSocket protocol when it listens for changes in the file content.

The first time to send an article, have wrong place welcome everybody to correct