2019-06-19

CommonJS规范

最近做了一点环境模拟的工作，还是有点意思的，无意中发现自己其实已经在实现CommonJS规范了，那就正好去学习一下。
本来想上来就总结一下commonJS规范的概念，然后放一段完美的原理实现代码，perfect！其实最早也是按照这个模式去写了（一如既往的知识点搬来主义，哈哈哈），但是想了想还是从自己如何一步步实现并理解模块定义加载的角度来写，感觉这样印象更深更有助于理解。

问题一：实现以下两个函数

define('hello.js', function(require, module, exports){
  console.log('hello world');
});
require('hello.js');

解：简洁版的实现可以先不考虑define第二个参数的参数。很明显define是用来定义一个模块，require用来引入模块，则需要一个全局对象记录模块名对应的模块。

const modules = {};
const define = function(path, fn){
  modules[path] = fn;
}
const require = function(path){
  modules[path](require, {}, {});
}

至此，一个简洁版的模块定义加载就实现了。

问题二：模块导出

define('hello.js', function(require, module, exports){
    const des = 'hello world';
    module.exports = {
        des
    };
})
const hello = require('hello.js');
console.log(hello.des);

解：require返回的是module.exports这个对象，module可以认为是define定义的模块本身。

const modules = {};
const define = function(path, fn){
    modules[path] = fn;
}
const require = function(path){
    const mod = modules[path];
    if(!mod) throw new Error(`fail to require module ${path}`);
    if(!mod.exports) mod.exports = {};
    mod(require, mod, mod.exports);
    return mod.exports;
}

之前总是纠结怎么区分module.exports和exports，到这里就可以看出它们的区别了。在一个模块内，exports指向module.exports，由于exports是对module.exports的引用，在使用时需要注意，更高效的，可以完全不理解exports直接使用module.exports。

问题三：模块加载

define('lib/hello.js', function(req, module, exports){
    const hi = req('./hi');
    console.log(hi);
})
define('lib/hi.js', function(req, module, exports){
    module.exports = 'hi';
})
req('lib/hello.js');

解：req时可以省略后缀引入模块，还可以使用相对路径引入模块。这里实现比较困难的就是处理相对路径，如何在req新模块时拿到当前模块的路径。因为在req加载新模块时已经在一个模块内部，这时当前模块的路径只能看是通过什么方式绑到模块传进来的req这个参数上。只要能拿到所在模块define的路径就方便处理req相对路径了。

const modules = {};
const resolve = function(path, basePath){
    if(!/\.js$/.test(path)) path += '.js';
    if(basePath) {
        const dir = basePath.replace(/[^\/]+\.js$/, '');
        path = path.replace(/^\.\//, dir);
        path = path.replace(/(\.\.\/)+/, function(match, p1){
            const times = match.length / p1.length;
            const realPath = dir.split('/').filter(p => !!p).slice(0, -times).join('/');
            return realPath + '/';
        })
    }
    return path;
}
const req = function(path){
    path = resolve(path, this.basePath);
    const mod = modules[path];
    if(!mod) throw new Error(`fail to require module ${path}`);
    if(!mod.exports) mod.exports = {};
    mod(mod, mod.exports); // 这里之所以不需要传入第一个参数req，是因为在define时req已默认传入
    return mod.exports;
}
const define = function(path, fn){
    modules[path] = fn.bind(null, req.bind({
        basePath: path
    }))
}

至此，模块规范基本已经实现。当然还有很多需要考虑的，比如模块循环加载、模块加载规则等等。

题外话。。。

偶然发现webpack打包后的文件中其实也实现了模块加载机制，摘出其中的代码放在下面，样例代码看这里。

// The module cache
var installedModules = {};
// The require function
function __webpack_require__(moduleId) {
    // Check if module is in cache
    if(installedModules[moduleId]) {
      	return installedModules[moduleId].exports;
    }
    // Create a new module (and put it into the cache)
    var module = installedModules[moduleId] = {
      	i: moduleId,
    		l: false,
      	exports: {}
    };
  	// Execute the module function
  	modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
  	// Flag the module as loaded
  	module.l = true;
  	// Return the exports of the module
  	return module.exports;
}

可以看出模块加载的实现和上面自己实现的基本差不多，不过有一处不解，为何调用模块需要用call的形式把module.exports作为上下文传入呢？

然后在Github上看到一篇博文，https://github.com/youngwind/blog/issues/98，文中让我感触比较深的并不是对模块加载的设计实现，而是其在开头处提到的”陷入了面向过程编程的误区”，我在上面列出的几个递进问题的实现其实就是面向过程的实现方式，专门去查了一下面向过程和面向对象的区别，再看看webpack中对require的封装，感觉明白了什么。以前可能以为面向对象就是给原型对象绑一些方法，然后需要new实例出来使用，看webpack中对require的实现给我的感觉用一个词来形容就是”行云流水”，实现思路还是得open起来啊，webpack中把方法或变量都绑给函数，直接调用函数的方式来做，其实也是符合面向对象的思想的。