深入理解 webpack 文件打包机制(小结)
前言
最近在重拾 webpack 一些知识点,希望对前端模块化有更多的理解,以前对 webpack 打包机制有所好奇,没有理解深入,浅尝则止,最近通过对 webpack 打包后的文件进行查阅,对其如何打包 js 文件有了更深的理解,希望通过这篇文章,能够帮助读者你理解:
- webpack 单文件如何进行打包?
- webpack 多文件如何进行代码切割?
- webpack1 和 webpack2 在文件打包上有什么区别?
- webpack2 如何做到 tree shaking?
- webpack3 如何做到 scope hoisting?
本文所有示例代码全部放在我的 github 上,看兴趣的可以看看:
git clone https://github.com/happylindz/blog.git cd blog/code/webpackbundleanalysis npm install
webpack 单文件如何打包?
首先现在 webpack 作为当前主流的前端模块化工具,在 webpack 刚开始流行的时候,我们经常通过 webpack 将所有处理文件全部打包成一个 bundle 文件, 先通过一个简单的例子来看:
// src/single/index.js var index2 = require('./index2'); var util = require('./util'); console.log(index2); console.log(util); // src/single/index2.js var util = require('./util'); console.log(util); module.exports = "index 2"; // src/single/util.js module.exports = "hello world"; // 通过 config/webpack.config.single.js 打包 const webpack = require('webpack'); const path = require('path') module.exports = { entry: { index: [path.resolve(__dirname, '../src/single/index.js')], }, output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[chunkhash:8].js' }, }
通过 npm run build:single 可看到打包效果,打包内容大致如下(经过精简):
// dist/index.xxxx.js (function(modules) { // 已经加载过的模块 var installedmodules = {}; // 模块加载函数 function __webpack_require__(moduleid) { if(installedmodules[moduleid]) { return installedmodules[moduleid].exports; } var module = installedmodules[moduleid] = { i: moduleid, l: false, exports: {} }; modules[moduleid].call(module.exports, module, module.exports, __webpack_require__); module.l = true; return module.exports; } return __webpack_require__(__webpack_require__.s = 3); })([ /* 0 */ (function(module, exports, __webpack_require__) { var util = __webpack_require__(1); console.log(util); module.exports = "index 2"; }), /* 1 */ (function(module, exports) { module.exports = "hello world"; }), /* 2 */ (function(module, exports, __webpack_require__) { var index2 = __webpack_require__(0); index2 = __webpack_require__(0); var util = __webpack_require__(1); console.log(index2); console.log(util); }), /* 3 */ (function(module, exports, __webpack_require__) { module.exports = __webpack_require__(2); })]);
将相对无关的代码剔除掉后,剩下主要的代码:
- 首先 webpack 将所有模块(可以简单理解成文件)包裹于一个函数中,并传入默认参数,这里有三个文件再加上一个入口模块一共四个模块,将它们放入一个数组中,取名为 modules,并通过数组的下标来作为 moduleid。
- 将 modules 传入一个自执行函数中,自执行函数中包含一个 installedmodules 已经加载过的模块和一个模块加载函数,最后加载入口模块并返回。
- __webpack_require__ 模块加载,先判断 installedmodules 是否已加载,加载过了就直接返回 exports 数据,没有加载过该模块就通过 modules[moduleid].call(module.exports, module, module.exports, __webpack_require__) 执行模块并且将 module.exports 给返回。
很简单是不是,有些点需要注意的是:
- 每个模块 webpack 只会加载一次,所以重复加载的模块只会执行一次,加载过的模块会放到 installedmodules,下次需要需要该模块的值就直接从里面拿了。
- 模块的 id 直接通过数组下标去一一对应的,这样能保证简单且唯一,通过其它方式比如文件名或文件路径的方式就比较麻烦,因为文件名可能出现重名,不唯一,文件路径则会增大文件体积,并且将路径暴露给前端,不够安全。
- modules[moduleid].call(module.exports, module, module.exports, __webpack_require__) 保证了模块加载时 this 的指向 module.exports 并且传入默认参数,很简单,不过多解释。
webpack 多文件如何进行代码切割?
webpack 单文件打包的方式应付一些简单场景就足够了,但是我们在开发一些复杂的应用,如果没有对代码进行切割,将第三方库(jquery)或框架(react)和业务代码全部打包在一起,就会导致用户访问页面速度很慢,不能有效利用缓存,你的老板可能就要找你谈话了。
那么 webpack 多文件入口如何进行代码切割,让我先写一个简单的例子:
// src/multiple/pagea.js const utila = require('./js/utila'); const utilb = require('./js/utilb'); console.log(utila); console.log(utilb); // src/multiple/pageb.js const utilb = require('./js/utilb'); console.log(utilb); // 异步加载文件,类似于 import() const utilc = () => require.ensure(['./js/utilc'], function(require) { console.log(require('./js/utilc')) }); utilc(); // src/multiple/js/utila.js 可类比于公共库,如 jquery module.exports = "util a"; // src/multiple/js/utilb.js module.exports = 'util b'; // src/multiple/js/utilc.js module.exports = "util c";
这里我们定义了两个入口 pagea 和 pageb 和三个库 util,我们希望代码切割做到:
- 因为两入口都是用到了 utilb,我们希望把它抽离成单独文件,并且当用户访问 pagea 和 pageb 的时候都能去加载 utilb 这个公共模块,而不是存在于各自的入口文件中。
- pageb 中 utilc 不是页面一开始加载时候就需要的内容,假如 utilc 很大,我们不希望页面加载时就直接加载 utilc,而是当用户达到某种条件(如:点击按钮)才去异步加载 utilc,这时候我们需要将 utilc 抽离成单独文件,当用户需要的时候再去加载该文件。
那么 webpack 需要怎么配置呢?
// 通过 config/webpack.config.multiple.js 打包 const webpack = require('webpack'); const path = require('path') module.exports = { entry: { pagea: [path.resolve(__dirname, '../src/multiple/pagea.js')], pageb: path.resolve(__dirname, '../src/multiple/pageb.js'), }, output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[chunkhash:8].js', }, plugins: [ new webpack.optimize.commonschunkplugin({ name: 'vendor', minchunks: 2, }), new webpack.optimize.commonschunkplugin({ name: 'manifest', chunks: ['vendor'] }) ] }
单单配置多 entry 是不够的,这样只会生成两个 bundle 文件,将 pagea 和 pageb 所需要的内容全部放入,跟单入口文件并没有区别,要做到代码切割,我们需要借助 webpack 内置的插件 commonschunkplugin。
首先 webpack 执行存在一部分运行时代码,即一部分初始化的工作,就像之前单文件中的 __webpack_require__ ,这部分代码需要加载于所有文件之前,相当于初始化工作,少了这部分初始化代码,后面加载过来的代码就无法识别并工作了。
new webpack.optimize.commonschunkplugin({ name: 'vendor', minchunks: 2, })
这段代码的含义是,在这些入口文件中,找到那些引用两次的模块(如:utilb),帮我抽离成一个叫 vendor 文件,此时那部分初始化工作的代码会被抽离到 vendor 文件中。
new webpack.optimize.commonschunkplugin({ name: 'manifest', chunks: ['vendor'], // minchunks: infinity // 可写可不写 })
这段代码的含义是在 vendor 文件中帮我把初始化代码抽离到 mainifest 文件中,此时 vendor 文件中就只剩下 utilb 这个模块了。你可能会好奇为什么要这么做?
因为这样可以给 vendor 生成稳定的 hash 值,每次修改业务代码(pagea),这段初始化时代码就会发生变化,那么如果将这段初始化代码放在 vendor 文件中的话,每次都会生成新的 vendor.xxxx.js,这样不利于持久化缓存,如果不理解也没关系,下次我会另外写一篇文章来讲述这部分内容。
另外 webpack 默认会抽离异步加载的代码,这个不需要你做额外的配置,pageb 中异步加载的 utilc 文件会直接抽离为 chunk.xxxx.js 文件。
所以这时候我们页面加载文件的顺序就会变成:
mainifest.xxxx.js // 初始化代码 vendor.xxxx.js // pagea 和 pageb 共同用到的模块,抽离 pagex.xxxx.js // 业务代码 当 pageb 需要 utilc 时候则异步加载 utilc
执行 npm run build:multiple 即可查看打包内容,首先来看下 manifest 如何做初始化工作(精简版)?
// dist/mainifest.xxxx.js (function(modules) { window["webpackjsonp"] = function webpackjsonpcallback(chunkids, moremodules) { var moduleid, chunkid, i = 0, callbacks = []; for(;i < chunkids.length; i++) { chunkid = chunkids[i]; if(installedchunks[chunkid]) callbacks.push.apply(callbacks, installedchunks[chunkid]); installedchunks[chunkid] = 0; } for(moduleid in moremodules) { if(object.prototype.hasownproperty.call(moremodules, moduleid)) { modules[moduleid] = moremodules[moduleid]; } } while(callbacks.length) callbacks.shift().call(null, __webpack_require__); if(moremodules[0]) { installedmodules[0] = 0; return __webpack_require__(0); } }; var installedmodules = {}; var installedchunks = { 4:0 }; function __webpack_require__(moduleid) { // 和单文件一致 } __webpack_require__.e = function requireensure(chunkid, callback) { if(installedchunks[chunkid] === 0) return callback.call(null, __webpack_require__); if(installedchunks[chunkid] !== undefined) { installedchunks[chunkid].push(callback); } else { installedchunks[chunkid] = [callback]; var head = document.getelementsbytagname('head')[0]; var script = document.createelement('script'); script.type = 'text/javascript'; script.charset = 'utf-8'; script.async = true; script.src = __webpack_require__.p + "" + chunkid + "." + ({"0":"pagea","1":"pageb","3":"vendor"}[chunkid]||chunkid) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkid] + ".js"; head.appendchild(script); } }; })([]);
与单文件内容一致,定义了一个自执行函数,因为它不包含任何模块,所以传入一个空数组。除了定义了 __webpack_require__ ,还另外定义了两个函数用来进行加载模块。
首先讲解代码前需要理解两个概念,分别是 module 和 chunk
- chunk 代表生成后 js 文件,一个 chunkid 对应一个打包好的 js 文件(一共五个),从这段代码可以看出,manifest 的 chunkid 为 4,并且从代码中还可以看到:0-3 分别对应 pagea, pageb, 异步 utilc, vendor 公共模块文件,这也就是我们为什么不能将这段代码放在 vendor 的原因,因为文件的 hash 值会变。内容变了,vendor 生成的 hash 值也就变了。
- module 对应着模块,可以简单理解为打包前每个 js 文件对应一个模块,也就是之前 __webpack_require__ 加载的模块,同样的使用数组下标作为 moduleid 且是唯一不重复的。
那么为什么要区分 chunk 和 module 呢?
首先使用 installedchunks 来保存每个 chunkid 是否被加载过,如果被加载过,则说明该 chunk 中所包含的模块已经被放到了 modules 中,注意是 modules 而不是 installedmodules。我们先来简单看一下 vendor chunk 打包出来的内容。
// vendor.xxxx.js webpackjsonp([3,4],{ 3: (function(module, exports) { module.exports = 'util b'; }) });
在执行完 manifest 后就会先执行 vendor 文件,结合上面 webpackjsonp 的定义,我们可以知道 [3, 4] 代表 chunkid,当加载到 vendor 文件后,installedchunks[3] 和 installedchunks[4] 将会被置为 0,这表明 chunk3,chunk4 已经被加载过了。
webpackjsonpcallback 一共有两个参数,chuckids 一般包含该 chunk 文件依赖的 chunkid 以及自身 chunkid,moremodules 代表该 chunk 文件带来新的模块。
var moduleid, chunkid, i = 0, callbacks = []; for(;i < chunkids.length; i++) { chunkid = chunkids[i]; if(installedchunks[chunkid]) callbacks.push.apply(callbacks, installedchunks[chunkid]); installedchunks[chunkid] = 0; } for(moduleid in moremodules) { if(object.prototype.hasownproperty.call(moremodules, moduleid)) { modules[moduleid] = moremodules[moduleid]; } } while(callbacks.length) callbacks.shift().call(null, __webpack_require__); if(moremodules[0]) { installedmodules[0] = 0; return __webpack_require__(0); }
简单说说 webpackjsonpcallback 做了哪些事,首先判断 chunkids 在 installedchunks 里有没有回调函数函数未执行完,有的话则放到 callbacks 里,并且等下统一执行,并将 chunkids 在 installedchunks 中全部置为 0, 然后将 moremodules 合并到 modules。
这里面只有 modules[0] 是不固定的,其它 modules 下标都是唯一的,在打包的时候 webpack 已经为它们统一编号,而 0 则为入口文件即 pagea,pageb 各有一个 module[0]。
然后将 callbacks 执行并清空,保证了该模块加载开始前所以前置依赖内容已经加载完毕,最后判断 moremodules[0], 有值说明该文件为入口文件,则开始执行入口模块 0。
上面解释了一大堆,但是像 pagea 这种同步加载 manifest, vendor 以及 pagea 文件来说,每次加载的时候 callbacks 都是为空的,因为它们在 installedchunks 中的值要嘛为 undefined(未加载), 要嘛为 0(已被加载)。installedchunks[chunkid] 的值永远为 false,所以在这种情况下 callbacks 里根本不会出现函数,如果仅仅是考虑这样的场景,上面的 webpackjsonpcallback 完全可以写成下面这样:
var moduleid, chunkid, i = 0, callbacks = []; for(;i < chunkids.length; i++) { chunkid = chunkids[i]; installedchunks[chunkid] = 0; } for(moduleid in moremodules) { if(object.prototype.hasownproperty.call(moremodules, moduleid)) { modules[moduleid] = moremodules[moduleid]; } } if(moremodules[0]) { installedmodules[0] = 0; return __webpack_require__(0); }
但是考虑到异步加载 js 文件的时候(比如 pageb 异步加载 utilc 文件),就没那么简单,我们先来看下 webpack 是如何加载异步脚本的:
// 异步加载函数挂载在 __webpack_require__.e 上 __webpack_require__.e = function requireensure(chunkid, callback) { if(installedchunks[chunkid] === 0) return callback.call(null, __webpack_require__); if(installedchunks[chunkid] !== undefined) { installedchunks[chunkid].push(callback); } else { installedchunks[chunkid] = [callback]; var head = document.getelementsbytagname('head')[0]; var script = document.createelement('script'); script.type = 'text/javascript'; script.charset = 'utf-8'; script.async = true; script.src = __webpack_require__.p + "" + chunkid + "." + ({"0":"pagea","1":"pageb","3":"vendor"}[chunkid]||chunkid) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkid] + ".js"; head.appendchild(script); } };
大致分为三种情况,(已经加载过,正在加载中以及从未加载过)
- 已经加载过该 chunk 文件,那就不用再重新加载该 chunk 了,直接执行回调函数即可,可以理解为假如页面有两种操作需要加载加载异步脚本,但是两个脚本都依赖于公共模块,那么第二次加载的时候发现之前第一次操作已经加载过了该 chunk,则不用再去获取异步脚本了,因为该公共模块已经被执行过了。
- 从未加载过,则动态地去插入 script 脚本去请求 js 文件,这也就为什么取名 webpackjsonpcallback ,因为跟 jsonp 的思想很类似,所以这种异步加载脚本在做脚本错误监控时经常出现 script error,具体原因可以查看我之前写的文章:
- 正在加载中代表该 chunk 文件已经在加载中了,比如说点击按钮触发异步脚本,用户点太快了,连点两次就可能出现这种情况,此时将回调函数放入 installedchunks。
我们通过 utilc 生成的 chunk 来进行讲解:
webpackjsonp([2,4],{ 4: (function(module, exports) { module.exports = "util c"; }) });
pageb 需要异步加载这个 chunk:
webpackjsonp([1,4],[ /* 0 */ (function(module, exports, __webpack_require__) { const utilb = __webpack_require__(3); console.log(utilb); const utilc = () => __webpack_require__.e/* nsure */(2, function(require) { console.log(__webpack_require__(4)) }); utilc(); }) ]);
当 pageb 进行某种操作需要加载 utilc 时就会执行 __webpack_require__.e(2, callback) 2,代表需要加载的模块 chunkid(utilc),异步加载 utilc 并将 callback 添加到 installedchunks[2] 中,然后当 utilc 的 chunk 文件加载完毕后,chunkids 包含 2,发现 installedchunks[2] 是个数组,里面还有之前还未执行的 callback 函数。
既然这样,那我就将我自己带来的模块先放到 modules 中,然后再统一执行之前未执行完的 callbacks 函数,这里指的是存放于 installedchunks[2] 中的回调函数 (可能存在多个),这也就是说明这里的先后顺序:
// 先将 moremodules 合并到 modules, 再去执行 callbacks, 不然之前未执行的 callback 依赖于新来的模块,你不放进 module 我岂不是得不到想要的模块 for(moduleid in moremodules) { if(object.prototype.hasownproperty.call(moremodules, moduleid)) { modules[moduleid] = moremodules[moduleid]; } } while(callbacks.length) callbacks.shift().call(null, __webpack_require__);
webpack1 和 webpack2 在文件打包上有什么区别?
经过我对打包文件的观察,从 webpack1 到 webpack2 在打包文件上有下面这些主要的改变:
首先,moduleid[0] 不再为入口执行函数做保留,所以说不用傻傻看到 moduleid[0] 就认为是打包文件的入口模块,取而代之的是 window["webpackjsonp"] = function webpackjsonpcallback(chunkids, moremodules, executemodules) {} 传入了第三个参数 executemodules,是个数组,如果参数存在则说明它是入口模块,然后就去执行该模块。
if(executemodules) { for(i=0; i < executemodules.length; i++) { result = __webpack_require__(__webpack_require__.s = executemodules[i]); } }
其次,webpack2 中会默认加载 occurrenceorderplugin 这个插件,即你不用 plugins 中添加这个配置它也会默认执行,那它有什么用途呢?主要是在 webpack1 中 moduleid 的不确定性导致的,在 webpack1 中 moduleid 取决于引入文件的顺序,这就会导致这个 moduleid 可能会时常发生变化, 而 occurrenceorderplugin 插件会按引入次数最多的模块进行排序,引入次数的模块的 moduleid 越小,比如说上面引用的 utilb 模块引用次数为 2(最多),所以它的 moduleid 为 0。
webpackjsonp([3],[ /* 0 */ (function(module, exports) { module.exports = 'util b'; }) ]);
最后说下在异步加载模块时, webpack2 是基于 promise 的,所以说如果你要兼容低版本浏览器,需要引入 promise-polyfill ,另外为引入请求添加了错误处理。
__webpack_require__.e = function requireensure(chunkid) { var promise = new promise(function(resolve, reject) { installedchunkdata = installedchunks[chunkid] = [resolve, reject]; }); installedchunkdata[2] = promise; // start chunk loading var head = document.getelementsbytagname('head')[0]; var script = document.createelement('script'); script.type = 'text/javascript'; script.charset = 'utf-8'; script.async = true; script.timeout = 120000; script.src = __webpack_require__.p + "" + chunkid + "." + {"0":"ae9c5f5f","1":"0ac69acb","2":"20651a9c","3":"0cdc6c84"}[chunkid] + ".js"; var timeout = settimeout(onscriptcomplete, 120000); script.onerror = script.onload = onscriptcomplete; function onscriptcomplete() { // 防止内存泄漏 script.onerror = script.onload = null; cleartimeout(timeout); var chunk = installedchunks[chunkid]; if(chunk !== 0) { if(chunk) { chunk[1](new error('loading chunk ' + chunkid + ' failed.')); } installedchunks[chunkid] = undefined; } }; head.appendchild(script); return promise; };
可以看出,原本基于回调函数的方式已经变成基于 promise 做异步处理,另外添加了 onscriptcomplete 用于做脚本加载失败处理。
在 webpack1 的时候,如果由于网络原因当你加载脚本失败后,即使网络恢复了,你再次进行某种操作需要同个 chunk 时候都会无效,主要原因是失败之后没把 installedchunks[chunkid] = undefined; 导致之后不会再对该 chunk 文件发起异步请求。
而在 webpack2 中,当脚本请求超时了(2min)或者加载失败,会将 installedchunks[chunkid] 清空,当下次重新请求该 chunk 文件会重新加载,提高了页面的容错性。
这些是我在打包文件中看到主要的区别,难免有所遗漏,如果你有更多的见解,欢迎在评论区留言。
webpack2 如何做到 tree shaking?
什么是 tree shaking,即 webpack 在打包的过程中会将没用的代码进行清除(dead code)。一般 dead code 具有一下的特征:
- 代码不会被执行,不可到达
- 代码执行的结果不会被用到
- 代码只会影响死变量(只写不读)
是不是很神奇,那么需要怎么做才能使 tree shaking 生效呢?
首先,模块引入要基于 es6 模块机制,不再使用 commonjs 规范,因为 es6 模块的依赖关系是确定的,和运行时的状态无关,可以进行可靠的静态分析,然后清除没用的代码。而 commonjs 的依赖关系是要到运行时候才能确定下来的。
其次,需要开启 uglifyjsplugin 这个插件对代码进行压缩。
我们先写一个例子来说明:
// src/es6/pagea.js import { utila, funca, // 引入 funca 但未使用, 故 funca 会被清除 } from './js/utila'; import utilb from './js/utilb'; // 引入 utilb(函数) 未使用,会被清除 import classc from './js/utilc'; // 引入 classc(类) 未使用,不会被清除 console.log(utila); // src/es6/js/utila.js export const utila = 'util a'; export function funca() { console.log('func a'); } // src/es6/js/utilb.js export default function() { console.log('func b'); } if(false) { // 被清除 console.log('never use'); } while(true) {} console.log('never use'); // src/es6/js/utilc.js const classc = function() {} // 类方法不会被清除 classc.prototype.saysomething = function() { console.log('class c'); } export default classc;
打包的配置也很简单:
const webpack = require('webpack'); const path = require('path') module.exports = { entry: { pagea: path.resolve(__dirname, '../src/es6/pagea.js'), }, output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[chunkhash:8].js' }, plugins: [ new webpack.optimize.commonschunkplugin({ name: 'manifest', minchunks: infinity, }), new webpack.optimize.uglifyjsplugin({ compress: { warnings: false } }) ] }
通过 npm run build:es6 对压缩的文件进行分析:
// dist/pagea.xxxx.js webpackjsonp([0],[ function(o, t, e) { 'use strict'; object.defineproperty(t, '__esmodule', { value: !0 }); var n = e(1); e(2), e(3); console.log(n.a); },function(o, t, e) { 'use strict'; t.a = 'util a'; },function(o, t, e) { 'use strict'; for (;;); console.log('never use'); }, function(o, t, e) { 'use strict'; const n = function() {}; n.prototype.saysomething = function() { console.log('class c'); }; } ],[0]);
引入但是没用的变量,函数都会清除,未执行的代码也会被清除。但是类方法是不会被清除的。因为 webpack 不会区分不了是定义在 classc 的 prototype 还是其它 array 的 prototype 的,比如 classc 写成下面这样:
const classc = function() {} var a = 'class' + 'c'; var b; if(a === 'array') { b = a; }else { b = 'classc'; } b.prototype.saysomething = function() { console.log('class c'); } export default classc;
webpack 无法保证 prototype 挂载的对象是 classc,这种代码,静态分析是分析不了的,就算能静态分析代码,想要正确完全的分析也比较困难。所以 webpack 干脆不处理类方法,不对类方法进行 tree shaking。
更多的 tree shaking 的副作用可以查阅: tree shaking class methods
webpack3 如何做到 scope hoisting?
scope hoisting,顾名思义就是将模块的作用域提升,在 webpack 中不能将所有所有的模块直接放在同一个作用域下,有以下几个原因:
- 按需加载的模块
- 使用 commonjs 规范的模块
- 被多 entry 共享的模块
在 webpack3 中,这些情况生成的模块不会进行作用域提升,下面我就举个例子来说明:
// src/hoist/utila.js export const utila = 'util a'; export function funca() { console.log('func a'); } // src/hoist/utilb.js export const utilb = 'util b'; export function funcb() { console.log('func b'); } // src/hoist/utilc.js export const utilc = 'util c'; // src/hoist/pagea.js import { utila, funca } from './utila'; console.log(utila); funca(); // src/hoist/pageb.js import { utila } from './utila'; import { utilb, funcb } from './utilb'; funcb(); import('./utilc').then(function(utilc) { console.log(utilc); })
这个例子比较典型,utila 被 pagea 和 pageb 所共享,utilb 被 pageb 单独加载,utilc 被 pageb 异步加载。
想要 webpack3 生效,则需要在 plugins 中添加 moduleconcatenationplugin。
webpack 配置如下:
const webpack = require('webpack'); const path = require('path') module.exports = { entry: { pagea: path.resolve(__dirname, '../src/hoist/pagea.js'), pageb: path.resolve(__dirname, '../src/hoist/pageb.js'), }, output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[chunkhash:8].js' }, plugins: [ new webpack.optimize.moduleconcatenationplugin(), new webpack.optimize.commonschunkplugin({ name: 'vendor', minchunks: 2, }), new webpack.optimize.commonschunkplugin({ name: 'manifest', minchunks: infinity, }) ] }
运行 npm run build:hoist 进行编译,简单看下生成的 pageb 代码:
webpackjsonp([2],{ 2: (function(module, __webpack_exports__, __webpack_require__) { "use strict"; var utila = __webpack_require__(0); // concatenated module: ./src/hoist/utilb.js const utilb = 'util b'; function funcb() { console.log('func b'); } // concatenated module: ./src/hoist/pageb.js funcb(); __webpack_require__.e/* import() */(0).then(__webpack_require__.bind(null, 3)).then(function(utilc) { console.log(utilc); }) }) },[2]);
通过代码分析,可以得出下面的结论:
- 因为我们配置了共享模块抽离,所以 utila 被抽出为单独模块,故这部分内容不会进行作用域提升。
- utilb 无牵无挂,被 pageb 单独加载,所以这部分不会生成新的模块,而是直接作用域提升到 pageb 中。
- utilc 被异步加载,需要抽离成单独模块,很明显没办法作用域提升。
结尾
好了,讲到这差不多就完了,理解上面的内容对前端模块化会有更多的认知,如果有什么写的不对或者不完整的地方,还望补充说明,希望这篇文章能帮助到你。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
上一篇: Nginx 配置多站点vhost 的方法
下一篇: Python爬取前程无忧十万条招聘数据