webpack原理与实战

布满荆棘的人生 2021-06-26 16:06 449阅读 0赞

`webpack`是一个`js`打包工具，不一个完整的前端构建工具。它的流行得益于模块化和单页应用的流行。`webpack`提供扩展机制，在庞大的社区支持下各种场景基本它都可找到解决方案。本文的目的是教会你用`webpack`解决实战中常见的问题。

## `webpack`原理 ##

在深入实战前先要知道`webpack`的运行原理

**`webpack`核心概念**

*  `entry` 一个可执行模块或库的入口文件。
 *  `chunk` 多个文件组成的一个代码块，例如把一个可执行模块和它所有依赖的模块组合和一个 chunk 这体现了webpack的打包机制。
 *  `loader` 文件转换器，例如把es6转换为es5，scss转换为css。
 *  `plugin` 插件，用于扩展webpack的功能，在webpack构建生命周期的节点上加入扩展hook为webpack加入功能。

**webpack构建流程**  
从启动webpack构建到输出结果经历了一系列过程，它们是：

1.  解析webpack配置参数，合并从shell传入和webpack.config.js文件里配置的参数，生产最后的配置结果。
2.  注册所有配置的插件，好让插件监听webpack构建生命周期的事件节点，以做出对应的反应。
3.  从配置的entry入口文件开始解析文件构建AST语法树，找出每个文件所依赖的文件，递归下去。
4.  在解析文件递归的过程中根据文件类型和loader配置找出合适的loader用来对文件进行转换。
5.  递归完后得到每个文件的最终结果，根据entry配置生成代码块chunk。
6.  输出所有chunk到文件系统。

需要注意的是，在构建生命周期中有一系列插件在合适的时机做了合适的事情，比如`UglifyJsPlugin`会在`loader`转换递归完后对结果再使用`UglifyJs`压缩覆盖之前的结果。

## 场景和方案 ##

通过各种场景和对应的解决方案让你深入掌握`webpack`

**单页应用**  
一个单页应用需要配置一个`entry`指明执行入口，`webpack`会为`entry`生成一个包含这个入口所有依赖文件的`chunk`，但要让它在浏览器里跑起来还需要一个HTML文件来加载`chunk`生成的`js`文件，如果提取出了`css`还需要让HTML文件引入提取出的`css`。`web-webpack-plugin`里的`WebPlugin`可以自动的完成这些工作。

`webpack`配置文件

const {  WebPlugin } = require('web-webpack-plugin');
    module.exports = { 
      entry: { 
        app: './src/doc/index.js',
      },
      plugins: [
        // 一个WebPlugin对应生成一个html文件
        new WebPlugin({ 
          //输出的html文件名称
          filename: 'index.html',
          //这个html依赖的`entry`
          requires: ['app'],
        }),
      ],
    };

`requires: ['doc']`指明这个`HTML`依赖哪些`entry`，`entry`生成的`js`和`css`会自动注入到`HTML`里。  
你还可以配置这些资源的注入方式，支持如下属性：

*  `_dist` 只有在生产环境下才引入该资源
 *  `_dev` 只有在开发环境下才引入该资源
 *  `_inline` 把该资源的内容潜入到html里
 *  `_ie` 只有IE浏览器才需要引入的资源

要设置这些属性可以通过在`js`里配置

new WebPlugin({ 
        filename: 'index.html',
        requires: { 
             app:{ 
                  _dist:true,
                  _inline:false,
             }
        },
    }),

或者在模版里设置，使用模版的好处是灵活的控制资源注入点。

new WebPlugin({
          filename: 'index.html',
          template: './template.html',
    }),
    <!DOCTYPE html>
    <html lang="zh-cn">
    <head>
        <link rel="stylesheet" href="app?_inline">
        <script src="ie-polyfill?_ie"></script>
    </head>
    <body>
    <div id="react-body"></div>
    <script src="app"></script>
    </body>
    </html>

`WebPlugin`插件借鉴了`fis3`的思想，补足了`webpack`缺失的以`HTML`为入口的功能。想了解`WebPlugin`的更多功能，见文档。

**一个项目里管理多个单页应用**  
一般项目里会包含多个单页应用，虽然多个单页应用也可以合并成一个但是这样做会导致用户没访问的部分也加载了。如果项目里有很多个单页应用，为每个单页应用配置一个`entry`和`WebPlugin`？如果项目又新增了一个单页应用，又去新增`webpack`配置？这样做太麻烦了，`web-webpack-plugin`里的`AutoWebPlugin`可以方便的解决这些问题。

module.exports = { 
        plugins: [
            // 所有页面的入口目录
            new AutoWebPlugin('./src/'),
        ]
    };

`AutoWebPlugin`会把`./src/`目录下所有每个文件夹作为一个单页页面的入口，自动为所有的页面入口配置一个`WebPlugin`输出对应的`html`。要新增一个页面就在`./src/`下新建一个文件夹包含这个单页应用所依赖的代码，`AutoWebPlugin`自动生成一个名叫文件夹名称的`html`文件。`AutoWebPlugin`的更多功能见文档。

**代码分割优化**  
一个好的代码分割对浏览器首屏效果提升很大。比如对于最常见的`react`体系你可以

1.  先抽出基础库`react react-dom redux react-redux`到一个单独的文件而不是和其它文件放在一起打包为一个文件，这样做的好处是只要你不升级他们的版本这个文件永远不会被刷新。如果你把这些基础库和业务代码打包在一个文件里每次改动业务代码都会导致文件hash值变化从而导致缓存失效浏览器重复下载这些包含基础库的代码。以上的配置为：

// vender.js 文件抽离基础库到单独的一个文件里防止跟随业务代码被刷新
    // 所有页面都依赖的第三方库
    // react基础
    import 'react';
    import 'react-dom';
    import 'react-redux';
    // redux基础
    import 'redux';
    import 'redux-thunk';
    // webpack配置
    { 
      entry: { 
        vendor: './path/to/vendor.js',
      },
    }

1.  再通过`CommonsChunkPlugin`可以提取出多个代码块都依赖的代码形成一个单独的`chunk`。在应用有多个页面的场景下提取出所有页面公共的代码减少单个页面的代码，在不同页面之间切换时所有页面公共的代码之前被加载过而不必重新加载。

**构建npm包**  
demo remd  
除了构建可运行的web应用，`webpack`也可用来构建发布到`npm`上去的给别人调用的`js`库。

const nodeExternals = require('webpack-node-externals');
    module.exports = { 
      entry: { 
        index: './src/index.js',
      },
      externals: [nodeExternals()],
      target: 'node',
      output: { 
        path: path.resolve(__dirname, '.npm'),
        filename: '[name].js',
        libraryTarget: 'commonjs2',
      },
    };

这里有几个区别于web应用不同的地方：

*  `externals: [nodeExternals()]`用于排除`node_modules`目录下的代码被打包进去，因为放在`node_modules`目录下的代码应该通过`npm`安装。
 *  `libraryTarget: 'commonjs2'`指出`entry`是一个可供别人调用的库而不是可执行的，输出的`js`文件按照`commonjs`规范。

**构建服务端渲染**  
服务端渲染的代码要运行在`nodejs`环境，和浏览器不同的是，服务端渲染代码需要采用`commonjs`规范同时不应该包含除js之外的文件比如`css`。`webpack`配置如下：

module.exports = { 
      target: 'node',
      entry: { 
        'server_render': './src/server_render',
      },
      output: { 
        filename: './dist/server/[name].js',
        libraryTarget: 'commonjs2',
      },
      module: { 
        rules: [
          { 
            test: /\.js$/,
            loader: 'babel-loader',
          },
          { 
            test: /\.(scss|css|pdf)$/,
            loader: 'ignore-loader',
          },
        ]
      },
    };

其中几个关键的地方在于：

*  `target: 'node'` 指明构建出的代码是要运行在node环境里
 *  `libraryTarget: 'commonjs2'` 指明输出的代码要是commonjs规范
 *  `{test: /\.(scss|css|pdf)$/,loader: 'ignore-loader'}`是为了防止不能在node里执行服务端渲染也用不上的文件被打包进去。

**从`fis3`迁移到`webpack`**  
`fis3`和`webpack`有相似的地方也有不同的地方。相似在于他们都采用`commonjs`规范，不同在于导入`css`这些非`js`资源的方式。`fis3`通过`// @require './index.scss'`而`webpack`通过`require('./index.scss')`。如果想从`fis3`平滑迁移到`webpack`可以使用`comment-require-loader`。比如你想在`webpack`构建是使用采用了`fis3`方式的`imui`模块，配置如下：

loaders:[{ 
         test: /\.js$/,
         loaders: ['comment-require-loader'],
         include: [path.resolve(__dirname, 'node_modules/imui'),]
    }]

## 自定义`webpack`扩展 ##

如果你在社区找不到你的应用场景的解决方案，那就需要自己动手了写`loader`或者`plugin`了。  
在你编写自定义`webpack`扩展前你需要想明白到底是要做一个`loader`还是`plugin`呢？可以这样判断：

如果你的扩展是想对一个个单独的文件进行转换那么就编写`loader`剩下的都是`plugin`。

其中对文件进行转换可以是像：

*  `babel-loader`把`es6`转换成`es5`
 *  `file-loader`把文件替换成对应的`URL`
 *  `raw-loader`注入文本文件内容到代码里去

**编写 `webpack loader`**

编写`loader`非常简单，以`comment-require-loader`为例：

module.exports = function (content) { 
        return replace(content);
    };

`loader`的入口需要导出一个函数，这个函数要干的事情就是转换一个文件的内容。  
函数接收的参数`content`是一个文件在转换前的字符串形式内容，需要返回一个新的字符串形式内容作为转换后的结果，所有通过模块化倒入的文件都会经过`loader`。从这里可以看出`loader`只能处理一个个单独的文件而不能处理代码块。想编写更复杂的`loader`可参考官方文档

**编写 `webpack plugin`**

**plugin**应用场景广泛，所以稍微复杂点。以`end-webpack-plugin`为例：

class EndWebpackPlugin { 
    
        constructor(doneCallback, failCallback) { 
            this.doneCallback = doneCallback;
            this.failCallback = failCallback;
        }
    
        apply(compiler) { 
            // 监听webpack生命周期里的事件，做相应的处理
            compiler.plugin('done', (stats) => { 
                this.doneCallback(stats);
            });
            compiler.plugin('failed', (err) => { 
                this.failCallback(err);
            });
        }
    }
    
    module.exports = EndWebpackPlugin;

`loader`的入口需要导出一个`class`, 在`new EndWebpackPlugin()`的时候通过构造函数传入这个插件需要的参数，在`webpack`启动的时候会先实例化`plugin`再调用`plugin`的`apply`方法，插件需要在`apply`函数里监听`webpack`生命周期里的事件，做相应的处理。  
`webpack plugin` 里有2个核心概念：

*  `Compiler`: 从`webpack`启动到推出只存在一个`Compiler`，`Compiler`存放着`webpack`配置
 *  `Compilation`: 由于`webpack`的监听文件变化自动编译机制，`Compilation`代表一次编译。

`Compiler` 和 `Compilation` 都会广播一系列事件。  
`webpack`生命周期里有非常多的事件可以在`event-hooks`和`Compilation`里查到。以上只是一个最简单的`demo`，更复杂的可以查看 [how to write a plugin][]或参考[web-webpack-plugin][]。

## 总结 ##

`webpack`其实很简单，可以用一句话涵盖它的本质：

> `webpack`是一个打包模块化`js`的工具，可以通过loader转换文件，通过`plugin`扩展功能。

如果`webpack`让你感到复杂，一定是各种`loader`和`plugin`的原因。  
希望本文能让你明白`webpack`的原理与本质让你可以在实战中灵活应用`webpack`。

[how to write a plugin]: https://github.com/webpack/docs/wiki/how-to-write-a-plugin
[web-webpack-plugin]: https://github.com/gwuhaolin/web-webpack-plugin