NoteDeep
package.json 官方文档
https://docs.npmjs.com/cli/v6/configuring-npm/package-json#local-paths
如何引用一个本地的依赖。
es6 modules 是 js 原生的 module,但是大部分浏览器还不支持,甚至低版本的note不支持,高版本的node要在一定的条件下才支持。参考。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export
所以需要通过babel编译为遵循es5
Keep in mind that there is no JavaScript engine yet that natively supports ES6 modules. You said yourself that you are using Babel. Babel converts import and export declaration to CommonJS (require/module.exports) by default anyway. So even if you use ES6 module syntax, you will be using CommonJS under the hood if you run the code in Node.
There are technical differences between CommonJS and ES6 modules, e.g. CommonJS allows you to load modules dynamically. ES6 doesn't allow this, but there is an API in development for that.
Since ES6 modules are part of the standard, I would use them.
Update 2020
Since Node v12, support for ES modules is enabled by default, but it's still experimental at the time of writing this. Files including node modules must either end in .mjs or the nearest package.json file must contain "type": "module". The Node documentation has a ton more information, also about interop between CommonJS and ES modules.
Performance-wise there is always the chance that newer features are not as well optimized as existing features. However, since module files are only evaluated once, the performance aspect can probably be ignored. In the end you have to run benchmarks to get a definite answer anyway.
ES modules can be loaded dynamically via the import() function. Unlike require, this returns a promise.
commonJS 是什么?commonJs modules
https://zhaoda.net/webpack-handbook/commonjs.html
https://nodejs.org/docs/latest/api/modules.html#modules_modules_commonjs_modules
In the Node.js module system, each file is treated as a separate module.
https://requirejs.org/docs/commonjs.html
CommonJS 规范是为了解决 JavaScript 的作用域问题而定义的模块形式,可以使每个模块它自身的命名空间中执行。该规范的主要内容是,模块必须通过 module.exports 导出对外的变量或接口,通过 require() 来导入其他模块的输出到当前模块作用域中。
一个直观的例子:
// moduleA.js module.exports = function( value ){ return value * 2; }
// moduleB.js var multiplyBy2 = require('./moduleA'); var result = multiplyBy2(4);

peerDependence 的问题
https://stackoverflow.com/questions/66488492/solve-having-more-than-one-copy-of-react-in-the-same-app

立即执行函数的写法

内部的_count不会暴露在外面
  var module1 = (function(){
    var _count = 0;
    var m1 = function(){       //...     };
    var m2 = function(){       //...     };
    return {       m1 : m1,       m2 : m2     };
  })();

宽松的放大模式

为模块添加新的方法
  var module1 = ( function (mod){
  mod.m3 = function () {       //...     };
    return mod;
  })(window.module1 || {});

输入全局变量

把外部的全局变量传入模块,可以看出这个模块的依赖
  var module1 = (function ($, YAHOO) {
    //...
  })(jQuery, YAHOO);


浏览器环境

有了服务器端模块以后,很自然地,大家就想要客户端模块。而且最好两者能够兼容,一个模块不用修改,在服务器和浏览器都可以运行。
  var math = require('math');   math.add(2, 3);

必须等math.js加载完成。也就是说,如果加载时间很长,整个应用就会停在那里等。
这对服务器端不是一个问题,因为所有的模块都存放在本地硬盘,可以同步加载完成,等待时间就是硬盘的读取时间。
但是,对于浏览器,这却是一个大问题,因为模块都放在服务器端,等待时间取决于网速的快慢,可能要等很长时间,浏览器处于"假死"状态。

因此,浏览器端的模块,不能采用"同步加载"(synchronous),只能采用"异步加载"(asynchronous)。这就是AMD规范诞生的背景。

AMD

AMD是"Asynchronous Module Definition"的缩写,意思就是"异步模块定义"。它采用异步方式加载模块,模块的加载不影响它后面语句的运行。所有依赖这个模块的语句,都定义在一个回调函数中,等到加载完成之后,这个回调函数才会运行。
AMD也采用require()语句加载模块,但是不同于CommonJS,它要求两个参数:
  require([module], callback);

第一个参数[module],是一个数组,里面的成员就是要加载的模块;第二个参数callback,则是加载成功之后的回调函数。如果将前面的代码改写成AMD形式,就是下面这样:
  require(['math'], function (math) {     math.add(2, 3);   });

math.add()与math模块加载不是同步的,浏览器不会发生假死。所以很显然,AMD比较适合浏览器环境。
目前,主要有两个Javascript库实现了AMD规范:require.jscurl.js。本系列的第三部分,将通过介绍require.js,进一步讲解AMD的用法,以及如何将模块化编程投入实战。

require_js
http://www.ruanyifeng.com/blog/2012/11/require_js.html
参考文章:
http://www.ruanyifeng.com/blog/2012/10/asynchronous_module_definition.html





评论列表

    立即执行函数的写法
    宽松的放大模式
    输入全局变量
    浏览器环境
    AMD