关于前端:webpack三两事浅入深出原理解析构建优化

基础知识回顾

入口(entry)

module.exports = {  entry: './path/to/my/entry/file.js'};//或者module.exports = {  entry: {    main: './path/to/my/entry/file.js'  }};

输入(output)

module.exports = {  output: {    filename:'[name][chunkhash:8].js',    path:path.resolve(__dirname,'dist')  }};

loader
预处理loader
- css-loader 解决css中门路援用等问题
- style-loader 动静把款式写入css
- sass-loader scss编译器
- less-loader less编译器
- postcss-loader scss再解决

解决js loader

babel-loader
jsx-loader
ts-loader

图片解决loader

url-loader

插件(plugin)
plugins外面放的是插件，插件的作用在于进步开发效率，可能解放双手，让咱们去做更多有意义的事件。一些很low的事就通通交给插件去实现。

const webpackConfig = {    plugins: [        //革除文件        new CleanWebpackPlugin(),        //css独自打包        new MiniCssExtractPlugin({            filename: "[name].css",            chunkFilename: "[name].css"        }),        // 引入热更新插件        new webpack.HotModuleReplacementPlugin()     ]}

模式(mode)
- production 生产环境
development 开发环境
- 晋升了构建速度
- 默认为开发环境，不须要专门配置
- 提供压缩性能，不须要借助插件
- 提供SouceMap，不须要专门配置
浏览器兼容性(browser compatibility)
环境(environment)

我的项目中具体配置

构建过程

Webpack 解决应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中蕴含应用程序须要的每个模块，而后将所有模块打包成一个或多个 bundle

其实就是：Webpack 是一个 JS 代码打包器。

至于图片、CSS、Less、TS等其余文件，就须要 Webpack 配合 loader 或者 plugin 性能来实现。

构建流程

依据配置，辨认入口文件；
逐层辨认模块依赖（包含 Commonjs、AMD、或 ES6 的 import 等，都会被辨认和剖析）；
Webpack 次要工作内容就是剖析代码，转换代码，编译代码，最初输入代码；
输入最初打包后的代码。

webpack构建的三个阶段：

初始化阶段
编译阶段
输入阶段

初始化

初始化参数: 从配置文件和 Shell 语句中读取与合并参数，得出最终的参数。这个过程中还会执行配置文件中的插件实例化语句 new Plugin()。
初始化默认参数配置: new WebpackOptionsDefaulter().process(options)
实例化Compiler对象:用上一步失去的参数初始化Compiler实例，Compiler负责文件监听和启动编译。Compiler实例中蕴含了残缺的Webpack配置，全局只有一个Compiler实例。
加载插件: 顺次调用插件的apply办法，让插件能够监听后续的所有事件节点。同时给插件传入compiler实例的援用，以不便插件通过compiler调用Webpack提供的API。
解决入口: 读取配置的Entrys，为每个Entry实例化一个对应的EntryPlugin，为前面该Entry的递归解析工作做筹备

编译

1、生成chunk

chunk是webpack外部运行时的概念；一个chunk是对依赖图的局部进行封装的后果（`Chunkthe class is the encapsulation for parts of your dependency graph`）；能够通过多个entry-point来生成一个chunk
chunk能够分为三类;

entry chunk
- 蕴含webpack runtime code并且是最先执行的chunk
initial chunk
- 蕴含同步加载进来的module且不蕴含runtime code的chunk
- 在entry chunk执行后再执行的
normal chunk
- 应用require.ensure、System.import、import()异步加载进来的module，会被放到normal chunk中

每个chunk都至多有一个属性：

name: 默认为main
id: 惟一的编号，开发环境和name雷同，生产环境是一个数字，从0开始

2、构建依赖模块

var compiler = webpack(options);

从入口文件index.js开始剖析，查看右侧表格中的记录，如果有记录就完结。没有记录就持续读取文件内容，读取完文件内容后，开始进行形象树语法分析，将代码字符串转换成一个对象的形容文件。并将其中的依赖保留在dependencies数组中

dependencies：["./src/a.js"]

保留完当前，替换依赖函数

console.log("index.js");_webpack_reuqire("./src/a.js");

将转换后的代码字符串保留在右侧的表格中

模块id	转换后的代码
./src/index.js	console.log("index.js");_webpack_reuqire("./src/a.js");

因为dependencies中有数据，开始递归解析dependencies中的数据。取出.src/a.js

// .src/a.jsconsole.log("a.js");require("b")

查看右侧表格，发现没有a.js，开始读取文件内容，生成ast形象语法树，将依赖记录在数组中

dependencies: ["./src/b.js"]

而后替换函数依赖

console.log("a.js");_webpack_require("./src/b.js");module.exports = "a"

将转换后的代码记录在右侧的表格中

模块id	转换后的代码
./src/index.js	console.log("index.js");_webpack_reuqire("./src/a.js");
./src/a.js	console.log("a.js");_webpack_require("./src/b.js");module.exports = "a"

而后持续取出来dependencies的内容./src/b.js

console.log("b.js");module.exports = "b";

发现右侧表格中没有b.js这个文件，就持续读取文件内容，进行ast形象语法树剖析，发现没有依赖项，就不须要往数组中放货色，也不须要替换依赖项，将代码字符串存在表格中

模块id	转换后的代码
./src/index.js	console.log("index.js");_webpack_reuqire("./src/a.js");
./src/a.js	console.log("a.js");_webpack_require("./src/b.js");module.exports = "a"
./src/b.js	console.log("b.js");module.exports = "b";

而后递归回去，发现index下产生的数组是空，整个文件依赖就解析结束

3、产生chunk assets

在第二步实现当前，chunk中会产生一个模块列表，列表中蕴含了模块id和模块转换后的代码

接下来，webpack会依据配置为chunk生成一个资源列表，即chunk assets,资源列表能够了解为是生成到最终文件的文件名和文件内容

为什么叫资源列表呢？
因为有可能配置devtool生成的除了./dist/main.js还有./dist/main.js.map

即：文件名：./dist/main.js

文件内容：

(function(){})({    "./src/index.js": function(){        //是否是eval能够依据devtool来设置，有很多种形式        eval("console.log(\"index module\");\nvar a = __webpack_require__(/*! ./a */ \"./src/a.js\"); \na.abc();\nconsole.log(a);\n\n\n//# sourceURL=webpack:///./src/index.js?")    }})

chunk hash: 是依据所有的chunk assets的内容生成的一个hash字符串
hash: 一种算法，具备很多分类。特点是将一个任意长度的字符串转换成一个固定长度的字符串，而且能够保障原始内容不变

就是将咱们下面生成的文件内容，全副联结起来，而后生成一个固定长度的哈希值链接

简图：

多个chunk assets就是一个bundle（一捆）

4、合并chunk assets

将多个chunk的assets合并到一起，并产生一个总的hash

输入

webpack将利用node中的fs模块（文件解决模块），依据编译产生的总的assets，生成相应的文件

波及术语

module: 模块，宰割的代码单元，webpack中的模块能够是任何内容的文件，不仅限于JS
chunk: webpack外部构建模块的块，一个chunk中蕴含多个模块，这些模块是从入口模块通过依赖剖析得来的
bundle：chunk构建好模块后会生成chunk的资源清单，清单中的每一项就是一个bundle，能够认为bundle就是最终生成的文件
hash：最终的资源清单所有内容联结生成的hash值
chunkhash: chunk生成的资源清单内容联结生成的hash值
chunkname：chunk的名称，如果没有配置则应用main
id: 通常指chunk的惟一编号，如果在开发环境下构建，和chunkname雷同；如果是生产环境下构建，则应用一个从0开始的数字进行编号

HMR热更新原理

简介

Hot Module Replacement（以下简称：HMR 模块热替换）是 Webpack 提供的一个十分有用的性能，它容许在 JavaScript 运行时更新各种模块，而无需齐全刷新。

当咱们批改代码并保留后，Webpack 将对代码从新打包，HMR 会在利用程序运行过程中替换、增加或删除模块，而无需从新加载整个页面。
HMR 次要通过以下几种形式，来显著放慢开发速度：

保留在齐全从新加载页面时失落的应用程序状态；
只更新变更内容，以节俭贵重的开发工夫；
调整款式更加疾速 - 简直相当于在浏览器调试器中更改款式。

服务启动

webpack-dev-server：不是一个插件，而是一个web服务器

服务启动流程

webpack-dev-server源码解析

//启动服务的具体方法function startDevServer(config, options) {  const log = createLogger(options);  //申明全局webpack实例  let compiler;  try {    compiler = webpack(config);  } catch (err) {    if (err instanceof webpack.WebpackOptionsValidationError) {      log.error(colors.error(options.stats.colors, err.message));      // eslint-disable-next-line no-process-exit      process.exit(1);    }    throw err;  }  try {    //创立server服务    server = new Server(compiler, options, log);    serverData.server = server;  } catch (err) {    if (err.name === 'ValidationError') {      log.error(colors.error(options.stats.colors, err.message));      // eslint-disable-next-line no-process-exit      process.exit(1);    }    throw err;  }  if (options.socket) {    //设置服务监听    server.listeningApp.on('error', (e) => {      if (e.code === 'EADDRINUSE') {        //应用socket建设长连贯        //初始化socket        const clientSocket = new net.Socket();        clientSocket.on('error', (err) => {          if (err.code === 'ECONNREFUSED') {            // No other server listening on this socket so it can be safely removed            fs.unlinkSync(options.socket);            server.listen(options.socket, options.host, (error) => {              if (error) {                throw error;              }            });          }        });        clientSocket.connect({ path: options.socket }, () => {          throw new Error('This socket is already used');        });      }    });    server.listen(options.socket, options.host, (err) => {      if (err) {        throw err;      }      // chmod 666 (rw rw rw)      const READ_WRITE = 438;      fs.chmod(options.socket, READ_WRITE, (err) => {        if (err) {          throw err;        }      });    });  } else {    server.listen(options.port, options.host, (err) => {      if (err) {        throw err;      }    });  }}//启动webpack-dev-server服务器processOptions(config, argv, (config, options) => {  startDevServer(config, options);});

server.js源码解析

class Server {  constructor(compiler, options = {}, _log) {    ......    //构造函数初始化服务  }    //创立初始化express利用  setupApp() {    this.app = new express();  }     // 绑定监听事件  setupHooks() {    //当监听到一次webpack编译完结，就会调用_sendStats办法通过websocket给浏览器发送告诉，    //ok和hash事件，这样浏览器就能够拿到最新的hash值了，做查看更新逻辑    const addHooks = (compiler) => {      const { compile, invalid, done } = compiler.hooks;      compile.tap('webpack-dev-server', invalidPlugin);      invalid.tap('webpack-dev-server', invalidPlugin);      // 监听webpack的done钩子，tapable提供的监听办法      done.tap('webpack-dev-server', (stats) => {        this._sendStats(this.sockets, this.getStats(stats));        this._stats = stats;      });    };        ......  }    //应用webpack-dev-middleware中间件，返回生成的bundle文件  setupDevMiddleware() {    // middleware for serving webpack bundle    this.middleware = webpackDevMiddleware(      this.compiler,      Object.assign({}, this.options, { logLevel: this.log.options.level })    );  }    ......  //创立http服务，并启动服务  createServer() { ... }    //创立socket服务器建设长连贯  createSocketServer() {    ......  }  //应用socket在服务器和浏览器间接建设一个websocket长连贯  listen(port, hostname, fn){ ... }  // 通过websoket给客户端发消息  _sendStats(sockets, stats, force) {    ......    this.sockWrite(sockets, 'hash', stats.hash);    if (stats.errors.length > 0) {      this.sockWrite(sockets, 'errors', stats.errors);    } else if (stats.warnings.length > 0) {      this.sockWrite(sockets, 'warnings', stats.warnings);    } else {      this.sockWrite(sockets, 'ok');    }  }

client/index.js源码解析

var onSocketMessage = {   hash: function hash(_hash) {        // 更新currentHash值        status.currentHash = _hash;    },    ok: function ok() {        sendMessage('Ok');        // 进行更新查看等操作        reloadApp(options, status);    },}// 连贯服务地址socketUrl，?http://localhost:8080，本地服务地址socket(socketUrl, onSocketMessage);

热更新

热更新流程

文件系统发生变化
当监听到文件发生变化时，webpack 应用HotModuleReplacementPlugin编译文件，并将代码保留在内存中(webpack-dev-middleware)。
同时，webpack-dev-server通过编译器compiler取得文件的编译状况。
在compiler的 done 钩子函数（生命周期）里调用_sendStats发送向client发送hash值，在client保留下来。
client接管到ok或warning音讯后调用reloadApp公布客户端查看更新事件webpackHotUpdate。
webpack/hot监听到webpackHotUpdate事件，调用check办法进行hash值比照以及查看各modules是否须要更新。
调用JsonpMainTemplate.runtime的hotDownloadManifest办法向server端发送ajax申请
服务端返回hot-update.json（manifest）文件，该文件蕴含所有要更新模块的hash值和chunk名。
JsonpRuntime依据返回的json值应用jsonp申请具体的代码块
jsonp返回最新的chunk代码，并间接执行。
HotModulePlugin 将会对新旧模块进行比照，决定是否更新模块，查看模块之间的依赖关系，更新模块的同时更新模块间的依赖援用。
HMR runtime自身并不会解决代码批改，它会将不同文件交给对应的loader runtime解决
更新代码
如果更新失败，则间接刷新

webpaserver端源码

在我的项目初始化时，服务端与客户端曾经开启了长连贯服务，当webpack对文件编译产生变动时，服务端会及时告诉客户端。

class Server {  ...  setupHooks() {    //增加webpack的done事件回调    const addHooks = (compiler) =&gt; {      const { compile, invalid, done } = compiler.hooks;      //告诉正在客户端编译        compile.tap(\'webpack-dev-server\', invalidPlugin);      done.tap(\'webpack-dev-server\', (stats) =&gt; {        //编译实现向客户端发送音讯        this._sendStats(this.sockets, this.getStats(stats));         this._stats = stats;      });    };    addHooks(this.compiler);  }   _sendStats(sockets, stats, force) {    if (...) { //无变动则return      return this.sockWrite(sockets, \'still-ok\');    }    //如果有变动，则发送hash值    this.sockWrite(sockets, \'hash\', stats.hash);        if (stats.errors.length &gt; 0) {      this.sockWrite(sockets, \'errors\', stats.errors);    } else {//没有报错发送ok      this.sockWrite(sockets, \'ok\');    }  }  ...  //应用sockjs在浏览器端和服务端之间建设一个 websocket 长连贯  listen(port, hostname, fn) {...}}

这里依然是Server.js中的代码，我具体的写展现了setupHooks中的代码，setupHooks 调用 webpack api 监听 compile的 done 事件，当编译实现，执行done钩子，调用_sendStats，在_sendStats办法中如果文件变动则发送hash。最初发送ok，客户端在承受到OK后会执行reload。

client端源码

客户端socket承受到hash后保存起来，随后承受到ok执行reload命令。

//Client/index.jsvar onSocketMessage = {  ...  hash: function hash(_hash) {    //将hash保留到全局currentHash中    status.currentHash = _hash;   },  ok: function ok() {    ...      //执行更新的reloadApp函数    reloadApp(options, status);   },  ...};socket(socketUrl, onSocketMessage);//Client/utils/reloadApp.jsfunction reloadApp(_ref, _ref2) {  if (hot) {    //hotEmitter是events类，webpack-dev-server公布webpackHotUpdate给webapck    var hotEmitter = require(\'webpack/hot/emitter\');    hotEmitter.emit(\'webpackHotUpdate\', currentHash);    if (typeof self !== \'undefined\' && self.window) {      // broadcast update to window      self.postMessage("webpackHotUpdate".concat(currentHash), \'*\');    }  } }

客户端接管到ok指令后，执行reloadApp函数。reloadApp函数中，hotEmitter其实是events模块的实例，即在全局实现公布订阅模式，hotEmitter公布了webpackHotUpdate事件，同时webpack订阅这个指令。

在这里当前，浏览器端进入webpack的代码，webpack-dev-server在客户端的局部实现。

订阅webpackHotUpdate事件的代码在webpack/hot/dev-server.js中:

if (module.hot) {    var lastHash;    var check = function check() {        module.hot            .check(true)            .then(function (updatedModules) {                //查看所有要更新的模块，如果没有模块要更新那么回调函数就是null                if (!updatedModules) {                    window.location.reload();                    return;                }                if (!upToDate()) {//如果还有更新                    check();                }            })    };    var hotEmitter = require("./emitter");    hotEmitter.on("webpackHotUpdate", function (currentHash) {        lastHash = currentHash;        check(); //调用check办法    });}

module为全局对象，module.hot的代码在HMR runtime中，module.hot.check对应hotCheck办法：

hotCheck = () =&gt; { //module.hot.check办法    return hotDownloadManifest.then((update) =&gt; {         //保留全局的热更新信息        hotAvailableFilesMap = update.c;        hotUpdateNewHash = update.h;        /*globals chunkId */        hotEnsureUpdateChunk(chunkId)    })}hotDownloadManifest(){ //ajax申请模块manifest    return new Promise(...);}hotEnsureUpdateChunk(){ //检测模块    if (!hotAvailableFilesMap[chunkId]) {...} else     {        hotRequestedFilesMap[chunkId] = true;        hotDownloadUpdateChunk();    }}hotDownloadUpdateChunk(){} //jsonp格局申请代码模块chunk//chunk是js代码块，格局是webpackHotUpdate("main", {...})，收到后间接执行，window全局中有对应办法window["webpackHotUpdate"]=function webpackHotUpdateCallback(){    hotAddUpdateChunk()}hotAddUpdateChunk(){//动静的更新代码模块    for (var moduleId in moreModules) {        //记录全局的热更新模块        hotUpdate[moduleId] = moreModules[moduleId];    }    hotUpdateDownloaded()}hotUpdateDownloaded(){ //执行hotApply模块    hotApply()}hotApply(){    //将代码更新到modules中}

次要蕴含了两个申请，在hotDownloadManifest中客户端申请了ajax的manifest，他的格局为 {"h":"bbff25e45ca71af784d0","c":{"main":true}} 蕴含了要更新模块的hash值和chunk名；另一个hotDownloadUpdateChunk通过jsonp办法申请更新的代码块，

获取到的代码块能够间接执行，webpack曾经在window中注册了webpackHotUpdate办法，执行后调用hotApply热模块替换办法。

function hotApply(options) {    function getAffectedStuff(updateModuleId) {        ...        return { //返回过期的模块和依赖            type: "accepted",            moduleId: updateModuleId,            outdatedModules: outdatedModules,            outdatedDependencies: outdatedDependencies        };    }    ...                result = getAffectedStuff(moduleId);    ...        {            switch (result.type) {                case "self-declined":                    ...                    break;                case "accepted"://对后果进行标记及解决                    if (options.onAccepted) options.onAccepted(result);                    doApply = true;                     break;                case "disposed":                    ...                    break;                default:                    ...            }    ...    while (queue.length &gt; 0) {        moduleId = queue.pop();        ...        delete installedModules[moduleId];//删除过期的模块和依赖        delete outdatedDependencies[moduleId];    }    ...    for (moduleId in appliedUpdate) {         if (Object.prototype.hasOwnProperty.call(appliedUpdate, moduleId)) {            //新的模块增加到modules中            modules[moduleId] = appliedUpdate[moduleId];        }    }    ...}

模块热替换次要分三个局部，首先是找出 outdatedModules 和 outdatedDependencies；而后从缓存中删除这些；最初，将新的模块增加到 modules 中，当下次调用 webpack_require (webpack 重写的 require 办法)办法的时候，就是获取到了新的模块代码了。

如果在热更新过程中呈现谬误，热更新将回退到刷新浏览器。

当用新的模块代码替换老的模块后，然而咱们的业务代码并不能晓得代码曾经发生变化，也就是说，当入口文件批改后，咱们须要在入口文件中调用 HMR 的 accept 办法

// index.jsif(module.hot) {    module.hot.accept(\'./main.js\', function() {        render()    })}

更新的代码每次在上面这个循环中执行， cb(moduleOutdatedDependencies)
就是module.hot.accept的内容，从而实现对代码的渲染

function hotApply(options) {    ...    for (moduleId in outdatedDependencies) {        ...        moduleOutdatedDependencies = outdatedDependencies[moduleId];        var callbacks = [];        for (i = 0; i &lt; moduleOutdatedDependencies.length; i++) {            dependency = moduleOutdatedDependencies[i];            cb = module.hot._acceptedDependencies[dependency];            callbacks.push(cb); //获取所有的模块        }        for (i = 0; i &lt; callbacks.length; i++) {            cb = callbacks[i];            cb(moduleOutdatedDependencies);//执行代码模块        }        ...    }    ...}

手写webpack构建工具

手写webpack流程

AST

AST(Abstract Syntax Tree)

形象语法树，源代码语法结构的一种形象示意

以树状的模式体现编程语言的语法结构
树上的每个节点都示意源代码中的一种构造

AST生成过程

形象语法树的生成次要依附的是Javascript Parser(js解析器)

词法剖析（Lexical Analysis）
语法分析（Parse Analysis）

在手写webpack中应用

通过Visitor实现依赖的收集

访问者（visitor）是一个用于 AST 遍历的跨语言模式，定义了用于在一个树状构造中获取具体节点的办法

树的宽度优先搜寻（BFS）算法思维

利用于循环剖析依赖

树的宽度优先搜寻（BFS）算法思维

循环剖析后果

打包后果为一个IIFE

打包后果剖析

后果运行剖析

webpack构建优化

背景

现在前端工程化的概念早曾经深入人心，抉择一款适合的编译和资源管理工具曾经成为了所有前端工程中的标配，而在诸多的构建工具中，webpack以其丰盛的性能和灵便的配置而深受业内吹捧，逐渐取代了grunt和gulp成为大多数前端工程实际中的首选，React，Vue，Angular等诸多出名我的项目也都相继选用其作为官网构建工具，极受业内追捧。然而，随者工程开发的复杂程度和代码规模一直地减少，webpack裸露进去的各种性能问题也愈发显著，极大的影响着开发过程中的体验。

问题演绎

历经了多个web我的项目的实战测验，咱们对webapck在构建中逐渐裸露进去的性能问题演绎次要有如下几个方面：

代码全量构建速度过慢，即便是很小的改变，也要期待长时间能力查看到更新与编译后的后果（引入HMR热更新后有显著改良）；
随着我的项目业务的复杂度减少，工程模块的体积也会急剧增大，构建后的模块通常要以M为单位计算；
多个我的项目之间共用根底资源存在反复打包，根底库代码复用率不高；
node的单过程实现在耗cpu计算型loader中体现不佳；
针对以上的问题，咱们来看看怎么利用webpack现有的一些机制和第三方扩大插件来一一击破。

慢在何处

作为工程师，咱们始终激励要感性思考，用数据和事实谈话，“我感觉很慢”，“太卡了”，“太大了”之类的表述不免显得太抽象和太形象，那么咱们无妨从如下几个方面来着手进行剖析：

从我的项目构造着手，代码组织是否正当，依赖应用是否正当；
从webpack本身提供的优化伎俩着手，看看哪些api未做优化配置；
从webpack本身的有余着手，做有针对性的扩大优化，进一步晋升效率；
在这里咱们举荐应用一个wepback的可视化资源剖析工具：webpack-bundle-analyzer，在webpack构建的时候会主动帮你计算出各个模块在你的我的项目工程中的依赖与散布状况，不便做更准确的资源依赖和援用的剖析。

从上图中咱们不难发现大多数的工程项目中，依赖库的体积永远是大头，通常体积能够占据整个工程项目的7-9成，而且在每次开发过程中也会从新读取和编译对应的依赖资源，这其实是很大的的资源开销节约，而且对编译后果影响微不足道，毕竟在理论业务开发中，咱们很少会去被动批改第三方库中的源码，改良计划如下：

计划一、合理配置 CommonsChunkPlugin

webpack的资源入口通常是以entry为单元进行编译提取，那么当多entry共存的时候，CommonsChunkPlugin的作用就会施展进去，对所有依赖的chunk进行公共局部的提取，然而在这里可能很多人会误认为抽取公共局部指的是能抽取某个代码片段，其实并非如此，它是以module为单位进行提取。

假如咱们的页面中存在entry1，entry2，entry3三个入口，这些入口中可能都会援用如utils，loadash，fetch等这些通用模块，那么就能够思考对这部分的共用局部机提取。通常提取形式有如下四种实现：

1、传入字符串参数，由chunkplugin主动计算提取

new webpack.optimize.CommonsChunkPlugin('common.js')

这种做法默认会把所有入口节点的公共代码提取进去, 生成一个common.js

2、有抉择的提取公共代码

new webpack.optimize.CommonsChunkPlugin('common.js',['entry1','entry2']);

只提取entry1节点和entry2中的共用局部模块, 生成一个common.js

3、将entry下所有的模块的公共局部（可指定援用次数）提取到一个通用的chunk中

new webpack.optimize.CommonsChunkPlugin({    name: 'vendors',    minChunks: function (module, count) {       return (          module.resource &&          /\.js$/.test(module.resource) &&          module.resource.indexOf(            path.join(__dirname, '../node_modules')          ) === 0       )    }});

提取所有node_modules中的模块至vendors中，也能够指定minChunks中的最小援用数；

4、抽取enry中的一些lib抽取到vendors中

entry = {    vendors: ['fetch', 'loadash']};new webpack.optimize.CommonsChunkPlugin({    name: "vendors",    minChunks: Infinity});

增加一个entry名叫为vendors，并把vendors设置为所须要的资源库，CommonsChunk会主动提取指定库至vendors中。

计划二、通过 externals 配置来提取罕用库

在理论我的项目开发过程中，咱们并不需要实时调试各种库的源码，这时候就能够思考应用external选项了。

简略来说external就是把咱们的依赖资源申明为一个内部依赖，而后通过script外链脚本引入。这也是咱们晚期页面开发中资源引入的一种翻版，只是通过配置后能够告知webapck遇到此类变量名时就能够不必解析和编译至模块的外部文件中，而改用从内部变量中读取，这样能极大的晋升编译速度，同时也能更好的利用CDN来实现缓存。

external的配置绝对比较简单，只须要实现如下三步：

1、在页面中退出须要引入的lib地址，如下：

<head><script src="//cdn.bootcss.com/jquery.min.js"></script><script src="//cdn.bootcss.com/underscore.min.js"></script><script src="/static/common/react.min.js"></script><script src="/static/common/react-dom.js"></script><script src="/static/common/react-router.js"></script><script src="/static/common/immutable.js"></script></head>

2、在webapck.config.js中退出external配置项：

module.export = {    externals: {        'react-router': {            amd: 'react-router',            root: 'ReactRouter',            commonjs: 'react-router',            commonjs2: 'react-router'        },        react: {            amd: 'react',            root: 'React',            commonjs: 'react',            commonjs2: 'react'        },        'react-dom': {            amd: 'react-dom',            root: 'ReactDOM',            commonjs: 'react-dom',            commonjs2: 'react-dom'        }    }}

这里要提到的一个细节是：此类文件在配置前，构建这些资源包时须要采纳amd/commonjs/cmd相干的模块化进行兼容封装，即打包好的库曾经是umd模式包装过的，如在node_modules/react-router中咱们能够看到umd/ReactRouter.js之类的文件，只有这样webpack中的require和import * from 'xxxx'能力正确读到该类包的援用，在这类js的头部个别也能看到如下字样：

if (typeof exports === 'object' && typeof module === 'object') {

module.exports = factory(require("react"));

} else if (typeof define === 'function' && define.amd) {

define(["react"], factory);

} else if (typeof exports === 'object') {

exports["ReactRouter"] = factory(require("react"));

} else {

root["ReactRouter"] = factory(root["React"]);

}

3、十分重要的是肯定要在output选项中退出如下一句话：

output: {  libraryTarget: 'umd'}

因为通过external提取过的js模块是不会被记录到webapck的chunk信息中，通过libraryTarget可告知咱们构建进去的业务模块，当读到了externals中的key时，须要以umd的形式去获取资源名，否则会有呈现找不到module的状况。

通过配置后，咱们能够看到对应的资源信息曾经能够在浏览器的source map中读到了。

对应的资源也能够间接由页面外链载入，无效地减小了资源包的体积。

计划三、利用 DllPlugin 和 DllReferencePlugin 预编译资源模块

咱们的我的项目依赖中通常会援用大量的npm包，而这些包在失常的开发过程中并不会进行批改，然而在每一次构建过程中却须要重复的将其解析，如何来躲避此类损耗呢？这两个插件就是干这个用的。

简略来说DllPlugin的作用是事后编译一些模块，而DllReferencePlugin则是把这些事后编译好的模块援用起来。这边须要留神的是DllPlugin必须要在DllReferencePlugin执行前先执行一次，dll这个概念应该也是借鉴了windows程序开发中的dll文件的设计理念。

绝对于externals，dllPlugin有如下几点劣势：

dll预编译进去的模块能够作为动态资源链接库可被重复使用，尤其适宜多个我的项目之间的资源共享，如同一个站点pc和手机版等；
dll资源能无效地解决资源循环依赖的问题，局部依赖库如：react-addons-css-transition-group这种原先从react外围库中抽取的资源包，整个代码只有一句话：

module.exports = require('react/lib/ReactCSSTransitionGroup');

却因为从新指向了react/lib中，这也会导致在通过externals引入的资源只能辨认react,寻址解析react/lib则会呈现无奈被正确索引的状况。

因为externals的配置项须要对每个依赖库进行一一定制，所以每次减少一个组件都须要手动批改，稍微繁琐，而通过dllPlugin则能齐全通过配置读取，缩小保护的老本；

1、配置dllPlugin对应资源表并编译文件

那么externals该如何应用呢，其实只须要减少一个配置文件：webpack.dll.config.js：

const webpack = require('webpack');const path = require('path');const isDebug = process.env.NODE_ENV === 'development';const outputPath = isDebug ? path.join(__dirname, '../common/debug') : path.join(__dirname, '../common/dist');const fileName = '[name].js';// 资源依赖包，提前编译const lib = [  'react',  'react-dom',  'react-router',  'history',  'react-addons-pure-render-mixin',  'react-addons-css-transition-group',  'redux',  'react-redux',  'react-router-redux',  'redux-actions',  'redux-thunk',  'immutable',  'whatwg-fetch',  'byted-people-react-select',  'byted-people-reqwest'];const plugin = [  new webpack.DllPlugin({    /**     * path     * 定义 manifest 文件生成的地位     * [name]的局部由entry的名字替换     */    path: path.join(outputPath, 'manifest.json'),    /**     * name     * dll bundle 输入到那个全局变量上     * 和 output.library 一样即可。     */    name: '[name]',    context: __dirname  }),  new webpack.optimize.OccurenceOrderPlugin()];if (!isDebug) {  plugin.push(    new webpack.DefinePlugin({      'process.env.NODE_ENV': JSON.stringify('production')    }),    new webpack.optimize.UglifyJsPlugin({      mangle: {        except: ['$', 'exports', 'require']      },      compress: { warnings: false },      output: { comments: false }    })  )}module.exports = {  devtool: '#source-map',  entry: {    lib: lib  },  output: {    path: outputPath,    filename: fileName,    /**     * output.library     * 将会定义为 window.${output.library}     * 在这次的例子中，将会定义为`window.vendor_library`     */    library: '[name]',    libraryTarget: 'umd',    umdNamedDefine: true  },  plugins: plugin};

而后执行命令：

$ NODE_ENV=development webpack --config  webpack.dll.lib.js --progress$ NODE_ENV=production webpack --config  webpack.dll.lib.js --progress

即可别离编译出反对调试版和生产环境中lib动态资源库，在构建进去的文件中咱们也能够看到会主动生成如下资源：

common├── debug │   ├── lib.js │   ├── lib.js.map │   └── manifest.json└── dist    ├── lib.js    ├── lib.js.map    └── manifest.json

文件阐明：

lib.js能够作为编译好的动态资源文件间接在页面中通过src链接引入，与externals的资源引入形式一样，生产与开发环境能够通过相似charles之类的代理转发工具来做路由替换；
manifest.json中保留了webpack中的预编译信息，这样等于提前拿到了依赖库中的chunk信息，在理论开发过程中就无须要进行反复编译；

2、dllPlugin的动态资源引入

lib.js和manifest.json存在一一对应的关系，所以咱们在调用的过程兴许遵循这个准则，如以后处于开发阶段，对应咱们能够引入common/debug文件夹下的lib.js和manifest.json，切换到生产环境的时候则须要引入common/dist下的资源进行对应操作，这里思考到手动切换和保护的老本，咱们举荐应用add-asset-html-webpack-plugin进行依赖资源的注入，可失去如下后果：

<head><script src="/static/common/lib.js"></script></head>在webpack.config.js文件中减少如下代码：const isDebug = (process.env.NODE_ENV === 'development');const libPath = isDebug ? '../dll/lib/manifest.json' : '../dll/dist/lib/manifest.json';// 将mainfest.json增加到webpack的构建中module.export = {  plugins: [       new webpack.DllReferencePlugin({       context: __dirname,       manifest: require(libPath),      })  ]}

配置实现后咱们能发现对应的资源包曾经实现了纯业务模块的提取

多个工程之间如果须要应用独特的lib资源，也只须要引入对应的lib.js和manifest.js即可，plugin配置中也反对多个webpack.DllReferencePlugin同时引入应用，如下：

module.export = {  plugins: [     new webpack.DllReferencePlugin({        context: __dirname,        manifest: require(libPath),      }),      new webpack.DllReferencePlugin({        context: __dirname,        manifest: require(ChartsPath),      })  ]

计划四、应用 Happypack 减速你的代码构建

以上介绍均为针对webpack中的chunk计算和编译内容的优化与改良，对资源的理论体积改良上也较为显著，那么除此之外，咱们是否针对资源的编译过程和速度优化上做些尝试呢？

家喻户晓，webpack中为了不便各种资源和类型的加载，设计了以loader加载器的模式读取资源，然而受限于node的编程模型影响，所有的loader尽管以async的模式来并发调用，然而还是运行在单个 node的过程以及在同一个事件循环中，这就间接导致了当咱们须要同时读取多个loader文件资源时，比方babel-loader须要transform各种jsx，es6的资源文件。在这种同步计算同时须要大量消耗cpu运算的过程中，node的单过程模型就无劣势了，那么happypack就针对解决此类问题而生。

开启happypack的线程池

happypack的解决思路是将原有的webpack对loader的执行过程从繁多过程的模式扩大多过程模式，本来的流程放弃不变，这样能够在不批改原有配置的根底上来实现对编译过程的优化，具体配置如下：

 const HappyPack = require('happypack'); const os = require('os') const HappyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length}); // 启动线程池});module:{    rules: [      {        test: /\.(js|jsx)$/,        // use: ['babel-loader?cacheDirectory'],        use: 'happypack/loader?id=jsx',        exclude: /^node_modules$/      }    ]  },  plugins:[    new HappyPack({     id: 'jsx',     cache: true,     threadPool: HappyThreadPool,     loaders: ['babel-loader']   })  ]

咱们能够看到通过在loader中配置间接指向happypack提供的loader，对于文件理论匹配的解决 loader，则是通过配置在plugin属性来传递阐明，这里happypack提供的loader与plugin的连接匹配，则是通过id=happybabel来实现。配置实现后，laoder的工作模式就转变成了如下所示：

happypack在编译过程中除了利用多过程的模式减速编译，还同时开启了cache计算，能充分利用缓存读取构建文件，对构建的速度晋升也是非常明显的，通过测试，最终的构建速度晋升如下：

优化前：

优化后：

对于happyoack的更多介绍能够查看：

[happypack]()
｜
[happypack 原理解析]()

计划五、加强 uglifyPlugin

uglifyJS凭借基于node开发，压缩比例高，使用方便等诸多长处曾经成为了js压缩工具中的首选，然而咱们在webpack的构建中察看发现，当webpack build进度走到80%前后时，会产生很长一段时间的停滞，经测试比照发现这一过程正是uglfiyJS在对咱们的output中的bunlde局部进行压缩耗时过长导致，针对这块咱们能够应用webpack-uglify-parallel来晋升压缩速度。

从插件源码中能够看到，webpack-uglify-parallel的是实现原理是采纳了多核并行压缩的形式来晋升咱们的压缩速度。

plugin.nextWorker().send({    input: input,    inputSourceMap: inputSourceMap,    file: file,    options: options});plugin._queue_len++;                if (!plugin._queue_len) {    callback();}               if (this.workers.length < this.maxWorkers) {    var worker = fork(__dirname + '/lib/worker');    worker.on('message', this.onWorkerMessage.bind(this));    worker.on('error', this.onWorkerError.bind(this));    this.workers.push(worker);}this._next_worker++;return this.workers[this._next_worker % this.maxWorkers];

应用配置也非常简单，只须要将咱们原来webpack中自带的uglifyPlugin配置：

new webpack.optimize.UglifyJsPlugin({   exclude:/\.min\.js$/   mangle:true,   compress: { warnings: false },   output: { comments: false }})批改成如下代码即可：const os = require('os');    const UglifyJsParallelPlugin = require('webpack-uglify-parallel');        new UglifyJsParallelPlugin({      workers: os.cpus().length,      mangle: true,      compressor: {        warnings: false,        drop_console: true,        drop_debugger: true       }    })

目前webpack官网也保护了一个反对多核压缩的UglifyJs插件：uglifyjs-webpack-plugin,应用形式相似，劣势在于齐全兼容webpack.optimize.UglifyJsPlugin中的配置，能够通过uglifyOptions写入，因而也做为举荐应用，参考配置如下：

 const UglifyJsPlugin = require('uglifyjs-webpack-plugin');  new UglifyJsPlugin({    uglifyOptions: {      ie8: false,      ecma: 8,      mangle: true,      output: { comments: false },      compress: { warnings: false }    },    sourceMap: false,    cache: true,    parallel: os.cpus().length * 2  })

计划六、Tree-shaking & Scope Hoisting

wepback在2.X和3.X中从rolluo中借鉴了tree-shaking和Scope Hoisting，利用es6的module个性，利用AST对所有援用的模块和办法做了动态剖析，从而能无效地剔除我的项目中的没有援用到的办法，并将相干办法调用归纳到了独立的webpack_module中，对打包构建的体积优化也较为显著，然而前提是所有的模块写法必须应用ES6 Module进行实现，具体配置参考如下：

 // .babelrc: 通过配置缩小没有援用到的办法  {    "presets": [      ["env", {        "targets": {          "browsers": ["last 2 versions", "safari >= 7"]        }      }],      // https://www.zhihu.com/question/41922432      ["es2015", {"modules": false}]  // tree-shaking    ]  }  // webpack.config: Scope Hoisting  {    plugins:[      // https://zhuanlan.zhihu.com/p/27980441      new webpack.optimize.ModuleConcatenationPlugin()    ]  }

实用场景

在理论的开发过程中，可灵便地抉择适宜本身业务场景的优化伎俩。

优化伎俩	开发环境	生产环境
CommonsChunk	√	√
externals		√
DllPlugin	√	√
Happypack	√
uglify-parallel		√