PHP是世界上最好的语言,而JavaScript将统治全世界
这个梗,已经完全不能被扒出是什么时候,由哪位神经大条的网友创造出来的。之所以这个梗被无时无刻的搬出来调侃,是因为编程世界的坑多到走完这条路,就脚残的节奏。
今天就来扒一扒在node和ES6中的module,主要是为了区分node和ES6中的不同意义,避免概念上的混淆,同时也分享一下,自己在这个坑里获得的心得。
在ES6之前
模块的概念是在ES6发布之前就出现的,我感觉主要是为了适应大型应用开发的需要而引入了JavaScript世界。模块化编程已经从噱头上升为必备,所以ES6也顺应时代,把这个写进了标准。
CommonJS和AMD都是JavaScript模块化规范,在ES6之前,Node主要遵循CommonJS,而AMD则主要运用在浏览器端,比如requirejs。
而且node发布的时候,就天生具备module,所以从某种意义上讲,是node促进了js世界里面的模块化编程。
// module-file.js for node module.exports = { a : function() {}, b : 'xxx' };
把上面这个js文件放在node环境中,我们这样去用它:
var myModule = require('./module-file'); var b = myModule.b;myModule.a();
当然了,node中module的知识有很多,这里就不再挖坑了。
从模块化思想出发,requirejs和国内前端大牛发布的seajs(遵循CMD)也允许前端猿们通过require去加载另一个模块。不过在模块定义的时候,需要借助一个define函数:
// module-file.js for requirejs define(function(require, exports, module){ module.exports = {}; });
requirejs和seajs都支持上面这种形式,在define的回调函数中提供了模拟的require, exports, module,折让习惯了node环境中使用方法的猿类可以顺便在浏览器端写基本相同的代码。
node,requirejs,seajs也同时支持下面这种导出模块的方式:
define(function(){ return {}; // return的值就是导出的模块 });
这就出现了UMD,即一个兼容多种环境的方案。
Node,requirejs中的exports
node中导出模块接口就是用exports,你可以这样做:
module.exports.a = function() {}; module.exports.b = 'xxx';
也可以写在一个对象中:
module.exports = { a : function() {}, b : 'xxx' }
在requirejs中,还提供了一个exports变量作为module.exports的别名:
define(function(require, exports, module){ exports.a = function(){}; exports.b = 'xxx'; });
注意“别名”的含义:exports是module.exports的地址的引用。它的本质是:
var exrpots = module.exports;
因此,你必须注意两个点,就是导出接口的时候:1.不能直接用exports={}来导出整个接口;2.如果使用了module.exports={},那么exports.a等都会被覆盖无效。
这是非常容易理解的,如果你不是很理解,可以阅读我写的《JavaScript引用类型数据》一文。
ES6中的import和export
在ES6之前,要使用一个模块,必须使用require函数将一个模块引入,但ES6并没有采用这种模块化方案,在ES6中使用import指令引入一个模块或模块中的部分接口,并没有将require写入标准,这也就是说require对于ES6代码而言,只是一个普通函数。
同理,在ES6标准中,导出模块的接口也只能使用export指令,而非exports对象,这也同样意味着module.exports只是node,requirejs等模块化库的自定义变量,而非ES标准接口。
当然,ES6的模块化也很复杂,不只模块接口的导入导出这点东西,只不过本文无耻的只讨论这个相对而言比较常见的问题。
常见export方式
在ES6规定中,这样导出一个模块的接口:
export function fun() {}; export { name1, name2, …, nameN }; export { variable1 as name1, variable2 as name2, …, nameN }; export let name1, name2, …, nameN; // also var export let name1 = …, name2 = …, …, nameN; // also var, const export default expression; export default function (…) { … } // also class, function* export default function name1(…) { … } // also class, function* export { name1 as default, … }; export * from …;export { name1, name2, …, nameN } from …; export { import1 as name1, import2 as name2, …, nameN } from …;
ES6里面,直接把要导出的变量、函数、对象、类等前面加一个export关键字。比如:
// module-file.js export function a(){}; export var obj = {};
有一个点:export必须导出具有对应关系的变量,下面的接口输出是错误的:
// 错误演示
export 1; // 这种导出的内容不是变量是绝对错误的,包括导出表达式,也是绝对错误的
var a = 1;
export a;
function b() {}
export b;
上面的这些方法都是错误的,不能这样导出接口。导出接口仅限两种:
1.声明时导出
2.以对象的形式导出(和解构联系起来)
如果要导出某个变量,可以用花括号括起来,像这样:
var a = 1; export {a};// 等效于:{a:a}function b() {} export {b};
我有点疑惑的是,为何export允许多次export {}这种形式?看上去很奇怪。另外,ES6更厉害之处在于,可以在export变量之后,继续修改变量:
export var obj {};obj.a = 1;
在import之后,obj的值仍然可以在模块内继续改变,这是CommonJS以往不可能做到的。
import基本用法
在另外一个js文件里面这样使用这些接口:
import {a,obj} from './module-file';a();alert(obj.b);
和node之前的require不一样,require只能把模块放到一个变量中,而在ES6中,拥有对象解构赋值的能力,所以直接就把引入的模块的接口赋值给变量了。内在机理也有不同,require需要去执行整个模块,将整个模块放到内存中(也就是我们说的运行时),如果只是使用到其中一个方法,性能上就差很多,而import...from则是只加载需要的接口方法,其他方法在程序启动之后根本触及不到,所以这种又被称为“编译时”,性能上好很多。
as关键字
编程的同学对as都容易理解,简单的说就是取一个别名。上面export中可以用,import中其实也可以用:
// a.jsvar a = function() {};export {a as fun}; // b.jsimport {fun as a} from './a';a();
上面这段代码,export的时候,对外提供的接口是fun,它是a.js内部a这个函数的别名,但是在模块外面,认不到a,只能认到fun。
import中的as就很简单,就是你在使用模块里面的方法的时候,给这个方法取一个别名,好在当前的文件里面使用。之所以是这样,是因为有的时候不同的两个模块可能通过相同的接口,比如有一个c.js也通过了fun这个接口:
// c.jsexport function fun() {};
如果在b.js中同时使用a和c这两个模块,就必须想办法解决接口重名的问题,as就解决了。
default关键字
其他人写教程什么的,都把default放到export那个部分,我觉得不利于理解。在export的时候,可能会用到default,说白了,它其实是别名的语法糖:
// d.jsexport default function() {} // 等效于:function a() {};export {a as default};
在import的时候,可以这样用:
import a from './d'; // 等效于,或者说就是下面这种写法的简写,是同一个意思import {default as a} from './d';
这个语法糖的好处就是import的时候,可以省去花括号{}。简单的说,如果import的时候,你发现某个变量没有花括号括起来,那么你在脑海中应该把它还原成有花括号的as语法。
所以,下面这种写法你也应该理解了吧:
import _,{each,map} from '_';
*符号
*就是代表所有,只用在import中,我们看下两个例子:
import * as underscore from '_';
在意义上和import _ from '_';
是不同的,虽然实际上后面的使用方法是一样的。它表示的是把'_'模块中的所有接口挂载到underscore这个对象上,所以可以用underscore.each调用某个接口。
export * from '_'; // 等效于:import * as all from '_';export all;
该用require还是import?
接下来的问题,就是我们在实操中,还有必要用require吗?我感觉ES6标准已经将之前的所有模块化规范都给碾压了,这在以前的标准发布中极少见,ES6用更加简单的方式,实现了更加有效的module,感觉require可以回家养老了。
标准与非标准
既然是标准,那么就是所有引擎应该去实现的,node和浏览器未来都会直接支持这种模块加载方式,require完成历史使命回家自己玩儿。而且作为node或浏览器,同时可以利用import提供自己的API,比如手机端提供基于网络的定位API,这都不用SDK了,直接内置在客户端内部,import一下就可以了。
不过现在import导入模块还并不是全部环境都支持,使用babel可以让node支持ES6,但在浏览器端,则毫无办法,可能还得暂时依赖require。但是非常不好的消息是,require不是ES6标准,这也就是说如果将来浏览器支持import后,你想用它,就必须升级代码,而不能直接被兼容。
import只能在文件开头使用,在import之前,你不能有其他的代码,这和其他语言是一样的。但是require则不同,它相当于node的一个定义在全局的函数,你可以在任意地方使用它,甚至使用变量表达式作为它的参数,这样有一个好处,就是可以在循环中加载模块。
有没有兼容import和require的模块?
但是很坑的是,node的模块导出和ES6标准也不符,因为node的模块体系遵循的是CommonJS规范,这就导致你写的模块文件,不可能同时支持require和import。
要强调的就是,不要把require和import两种模块加载方案混用,比如:
// module-file.jsmodule.exports = {}; // a.jsimport a from './moule-file';
这种混搭感觉不是很好(但可以用,下面有解释)。所以,其实我没有任何建议,我只是觉得,躺在坑里,挺自在的……毕竟node中require的使用更加灵活一点,它没有必须放在哪里的限制,所以可以在任意位置使用,而且它的结果也非常形象,甚至可以把require当做一个引用类型别名,可以这样使用:
require('./a')(); // a模块是一个函数,立即执行a模块函数 var data = require('./a').data; // a模块导出的是一个对象 var a = require('./a')[0]; // a模块导出的是一个数组
这样的写法感觉像给模块取了一个别名,使用的时候非常灵活。但是需要注意的是,如果你打算使用require来导入这个模块,那么请使用module.exports导出这个模块。
(临时)兼容方案
有没有一种兼容方案呢?
function a() {} class b {} module.exports = {a,b}; // {a,b}是ES6的写法
在实践中发现,module.exports可以兼容require和import,而且这个案例需要你的node环境配置好支持ES6语法。module.exports导出的模块,如果使用import,那么完全就是一个对象赋值、解构的过程:
import mod,{a,b} from './a';
之所以这是成立的,是因为我们使用babel对ES6代码进行转码后执行,而实际上,目前为止,没有任何一个环境是支持ES6 module方案的,即使babel,也仅仅是将ES6的import,export转码为require, module.exports后交给node去执行。
导出的模块接口被赋值给mod,所以mod是一个对象,含有a,b两个方法。这里的mod并没有通过default导出,所以和ES6有非常大的意义上的区别,这种非标准的写法,墙裂建议永远不要用。而且,由于require和module.exports是非标准的东西,仅在Node环境中有效,所以当未来浏览器支持模块导入时,并不会主动提供require,而是采用import,如果要使用require,还是不得不使用requirejs等库,借助define来用。
所以,最终,如果你打算用CommonJS,就不要掺和进ES6.
node有用es module的打算吗,作为小白来说,不知道他两的性能,但是论好用程度后者明显碾压啊,但是我怎么看node文档,node挺自豪commonjs的。。。甚至还有点瞧不起esmodule
node已经支持import mjs文件,浏览器也支持了。
node作为js的运行环境,只会向ES标准靠近。当然,它保留自己的commonjs和独特api,是无可厚非的。
有兴趣可以体验一下deno这个环境。
抱歉,在下是来挑刺的,阁下文中有一处严重的错误,
》以对象的形式导出(和解构联系起来)
》export {a}; // 等效于:{a:a}
此处export的‘{ }’是语法结构,而非对象或解构
eg: export { a as ax, a as default }
若以阁下所言,》等效于:{a:a}。然经在下实测,无论export {a:a},export {b:a},export {a:b},皆为非法。
export导出接口,而非对象,【https://es6.ruanyifeng.com/#docs/module】,
换言之,它对外暴露模块内部的变量(方法,类..)的引用
还望阁下认真求证,谨言慎行。
我看了很久,也没有找到你所指出的export {a:a}问题,export 导出语法只有 export { a as b } 这种形式。
这篇文章后面部分讨论的是ESModule和commonjs混用的时候的一些实际情况,你评论中估计是在说这一块。具体可以再阅读一下文章,另外,后续我也更新了关于webpack tree shaking使用时的一些新规则,可以查看这篇文章 https://www.tangshuang.net/7686.html
在3.export 命令
以下是原话
需要特别注意的是,export命令规定的是对外的接口,必须与模块内部的变量建立一一对应关系。
// 报错
export 1;
// 报错
var m = 1;
export m;
上面两种写法都会报错,因为没有提供对外的接口。第一种写法直接输出 1,第二种写法通过变量m,还是直接输出 1。1只是一个值,不是接口。正确的写法是下面这样。
看到你所说的“等效于:{a:a}”这句话,已经做了修改,确实会让人误解,谢谢指出
寫得很好!謝謝您的分享!
多交流
写的很好
var b = myModule;\na(); 这里a undefined
谢谢指出