利用webpack理解CommonJS和ES Modules的差异区别

2023-07-23 00:01:14 80

前言

问：CommonJS和ESModules中模块引入的区别？

CommonJS输出的是一个值的拷贝；ESModules生成一个引用，等到真的需要用到时，再到模块里面去取值，模块里面的变量，绑定其所在的模块。

我相信很多人已经把这个答案背得滚瓜烂熟，好，那继续提问。

问：CommonJS输出的值是浅拷贝还是深拷贝？

问：你能模拟实现ESModules的引用生成吗？

对于以上两个问题，我也是感到一脸懵逼，好在有webpack的帮助，作为一个打包工具，它让ESModules,CommonJS的工作流程瞬间清晰明了。

准备工作

初始化项目，并安装beta版本的webpack5，它相较于webpack4做了许多优化：对ESModules的支持度更高，打包后的代码也更精简。

$mkdirdemo&&cddemo
$yarninit-y
$yarnaddwebpack@nextwebpack-cli
#oryarnaddwebpack@5.0.0-beta.17webpack-cli

早在webpack4就已经引入了无配置的概念，既不需要提供webpack.config.js文件，它会默认以src/index.js为入口文件，生成打包后的main.js放置于dist文件夹中。

确保你拥有以下目录结构：

├──dist
│└──index.html
├──src
│└──index.js
├──package.json
└──yarn.lock

在index.html中引入打包后的main.js：






Document

在package.json中添加命令脚本：

"scripts":{
"start":"webpack"
},

运行无配置打包：

$yarnstart

终端会提示：

WARNINGinconfiguration
The'mode'optionhasnotbeenset,webpackwillfallbackto'production'forthisvalue.Set'mode'optionto'development'or'production'toenabledefaultsforeachenvironment.
Youcanalsosetitto'none'todisableanydefaultbehavior.Learnmore:https://webpack.js.org/configuration/mode/

webpack要求用户在打包时必须提供mode选项，来指明打包后的资源用于开发环境还是生产环境，从而让webpack相应地使用其内置优化，默认为production（生产环境）。

我们将其设置为none来避免默认行为带来的干扰，以便我们更好的分析源码。
修改package.json：

"scripts":{
"start":"webpack--mode=none"
},

重新运行，webpack在dist目录下生成了打包后的main.js，由于入口文件是空的，所以main.js的源码只有一个IIFE（立即执行函数），看似简单，但它的地位却极其重要。

(()=>{
//webpackBootstrap
})();

我们知道无论在CommonJS或ESModules中，一个文件就是一个模块，模块之间的作用域相互隔离，且不会污染全局作用域。此刻IIFE就派上了用场，它将一个文件的全部JS代码包裹起来，形成闭包函数，不仅起到了函数自执行的作用，还能保证函数间的作用域不会互相污染，并且在闭包函数外无法直接访问内部变量，除非内部变量被显式导出。

varname="webpack";

(()=>{
varname="parcel";
varage=18;
console.log(name);//parcel
})();

console.log(name);//webpack
console.log(age);//ReferenceError:ageisnotdefined

引用vs拷贝

接下里进入实践部分，涉及源码的阅读，让我们深入了解CommonJS和ESModules的差异所在。

CommonJS

新建src/counter.js

letnum=1;

functionincrease(){
returnnum++;
}

module.exports={num,increase};

修改index.js

const{num,increase}=require("./counter");

console.log(num);
increase();
console.log(num);

如果你看过前面叙述，毫无疑问，打印11.

sowhy？我们查看main.js，那有我们想要的答案，去除无用的注释后如下：

(()=>{
var__webpack_modules__=[
,
module=>{
letnum=1;

functionincrease(){
returnnum++;
}

module.exports={num,increase};
},
];

var__webpack_module_cache__={};

function__webpack_require__(moduleId){
//Checkifmoduleisincache
if(__webpack_module_cache__[moduleId]){
return__webpack_module_cache__[moduleId].exports;
}
//Createanewmodule(andputitintothecache)
varmodule=(__webpack_module_cache__[moduleId]={
exports:{},
});

//Executethemodulefunction
__webpack_modules__[moduleId](module,module.exports,__webpack_require__);

returnmodule.exports;
}

(()=>{
const{num,increase}=__webpack_require__(1);

console.log(num);
increase();
console.log(num);
})();
})();

可以简化为:

(()=>{
var__webpack_modules__=[...];
var__webpack_module_cache__={};

function__webpack_require__(moduleId){...}

(()=>{
const{num,increase}=__webpack_require__(1);

console.log(num);
increase();
console.log(num);
})();
})();

最外层是一个IIFE，立即执行。

__webpack_modules__，它是一个数组，第一项为空，第二项是一个箭头函数并传入module参数，函数内部包含了counter.js中的所有代码。

__webpack_module_cache__缓存已经加载过的模块。

function__webpack_require__(moduleId){...}类似于require()，他会先去__webpack_module_cache__中查找此模块是否已经被加载过，如果被加载过，直接返回缓存中的内容。否则，新建一个module:{exports:{}}，并设置缓存，执行模块函数，最后返回module.exports

最后遇到一个IIFE，它将index.js中的代码包装在内，并执行__webpack_require__(1)，导出了num和increase供index.js使用。

这里的关键点在于counter.js中的module.exports={num,increase};，等同于以下写法：

module.exports={
num:num,
increase:increase,
};

num属于基本类型，假设其内存地址指向n1，当它被赋值给module.exports['num']时，module.exports['num']已经指向了一个新的内存地址n2，只不过其值同样为1，但和num已是形同陌路，毫不相干。

letnum=1;
//mun相当于module.exports['num']
mun=num;

num=999;
console.log(mun);//1

increase是一个函数，属于引用类型，即increase只作为一个指针，当它被赋值给module.exports['increase']时，只进行了指针的复制，是浅拷贝（基本类型没有深浅拷贝的说法），其内存地址依旧指向同一块数据。所以本质上module.exports['increase']就是increase，只不过换个名字。

而由于词法作用域的特性，counter.js中increase()修改的num变量在函数声明时就已经绑定不变了，永远绑定内存地址指向n1的num.

JavaScript采用的是词法作用域，它规定了函数内访问变量时，查找变量是从函数声明的位置向外层作用域中查找，而不是从调用函数的位置开始向上查找

functionfoo(){
varx=10;
console.log(x);
}
functionbar(f){
varx=20;
f();
}
bar(foo);//10

调用increase()并不会影响内存地址指向n2的num，这也就是为什么打印11的理由。

ESModules

分别修改counter.js和index.js，这回使用ESModules.

letnum=1;

functionincrease(){
returnnum++;
}

export{num,increase};

import{num,increase}from"./counter";

console.log(num);
increase();
console.log(num);

很明显，打印12.

老规矩，查看main.js，删除无用的注释后如下：

(()=>{
"usestrict";
var__webpack_modules__=[
,
(__unused_webpack_module,__webpack_exports__,__webpack_require__)=>{
__webpack_require__.d(__webpack_exports__,{
num:()=>/*binding*/num,
increase:()=>/*binding*/increase,
});
letnum=1;

functionincrease(){
returnnum++;
}
},
];

var__webpack_module_cache__={};

function__webpack_require__(moduleId){}//笔者注：同一个函数，不再展开

/*webpack/runtime/definepropertygetters*/
(()=>{
__webpack_require__.d=(exports,definition)=>{
for(varkeyindefinition){
if(
__webpack_require__.o(definition,key)&&
!__webpack_require__.o(exports,key)
){
Object.defineProperty(exports,key,{
enumerable:true,
get:definition[key],
});
}
}
};
})();

/*webpack/runtime/hasOwnPropertyshorthand*/
(()=>{
__webpack_require__.o=(obj,prop)=>
Object.prototype.hasOwnProperty.call(obj,prop);
})();

(()=>{
var_counter__WEBPACK_IMPORTED_MODULE_0__=__webpack_require__(1);

console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
(0,_counter__WEBPACK_IMPORTED_MODULE_0__.increase)();
console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
})();
})();

经过简化，大致如下：

(()=>{
"usestrict";
var__webpack_modules__=[...];
var__webpack_module_cache__={};

function__webpack_require__(moduleId){...}

(()=>{
__webpack_require__.d=(exports,definition)=>{...};
})();

(()=>{
__webpack_require__.o=(obj,prop)=>{...}
})();

(()=>{
var_counter__WEBPACK_IMPORTED_MODULE_0__=__webpack_require__(1);

console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
(0,_counter__WEBPACK_IMPORTED_MODULE_0__.increase)();
console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
})();
})();

首先查看两个工具函数：__webpack_require__.o和__webpack_require__.d。

__webpack_require__.o封装了Object.prototype.hasOwnProperty.call(obj,prop)的操作。

__webpack_require__.d则是通过Object.defineProperty(exports,key,{enumerable:true,get:definition[key]})来对exports对象设置不同属性的getter

随后看到了熟悉的__webpack_modules__，它的形式和上一节差不多，最主要的是以下这段代码：

__webpack_require__.d(__webpack_exports__,{
num:()=>/*binding*/num,
increase:()=>/*binding*/increase,
});

与CommonJS不同，ESModules并没有对module.exports直接赋值，而是将值作为箭头函数的返回值，再把箭头函数赋值给module.exports，之前我们提过词法作用域的概念，即这里的num()和increase()无论在哪里执行，返回的num变量和increase函数都是counter.js中的。

在遇到最后一个IIFE时，调用__webpack_require__(1)，返回module.exports并赋值给_counter__WEBPACK_IMPORTED_MODULE_0__，后续所有的属性获取都是使用点操作符，这触发了对应属性的get操作，于是执行函数返回counter.js中的值。

所以打印12.

懂了词法作用域的原理，就可以实现一个”乞丐版“的ESModules：

functionmy_require(){
varmodule={
exports:{},
};
letcounter=1;

functionadd(){
returncounter++;
}

module.exports={counter:()=>counter,add};
returnmodule.exports;
}

varobj=my_require();

console.log(obj.counter());//1
obj.add();
console.log(obj.counter());//2

总结

多去看源码，会有不少的收获，这是一个思考的过程。
ESModules已经写入了ES2020规范中，意味着浏览器原生支持import和export，有兴趣的小伙伴可以试试Snowpack，它能直接export第三方库供浏览器使用，省去了webpack中打包的时间。

到此这篇关于利用webpack理解CommonJS和ESModules的差异区别的文章就介绍到这了,更多相关webpackCommonJS和ESModules内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！

利用webpack理解CommonJS和ES Modules的差异区别

热门推荐

随机推荐