前端模块化杂记

更好的阅度体验

  • 前言
  • CMD\AMD简介
  • Commonjs简介
  • Module简介
  • Common和Module的区别
  • Module与webpack
  • Module与Babel
  • 一些问题
  • 总结
  • 引用

前言

前端模块化在近几年层出不穷，有Node的CommonJs,也有属于client端的CMD/AMD模式，而ES6本身也出现了Modules，再加上Webpack以及babel的普及，虽然在代码中经常使用到这些用法，但是如果不去深入研究，总觉得是一个黑魔法，无法探测一些问题的根源。

AMD/CMD简介

事实上，随着打包工具和Babel在前端工程化的世界里大放异彩，AMD/CMD也在逐步退出历史的舞台，这里简单的介绍下其用法及语义。

AMD及其用法

AMD 即Asynchronous Module Definition，中文名是异步模块定义的意思。代表（require.js）

/** main.js 入口文件/主模块 **/
// 首先用config()指定各模块路径和引用名
require.config({
  baseUrl: "js/lib",
  paths: {
    "jquery": "jquery.min",  //实际路径为js/lib/jquery.min.js
    "underscore": "underscore.min",
  }
});
// 执行基本操作
require(["jquery","underscore"],function($,_){
  // some code here
});

CMD及其用法

CMD 即Common Module Definition， 中文名是通用模块定义的意思。代表（Sea.js）

/** sea.js **/
// 定义模块 math.js
define(function(require, exports, module) {
    var $ = require(‘jquery.js‘);
    var add = function(a,b){
        return a+b;
    }
    exports.add = add;
});
// 加载模块
seajs.use([‘math.js‘], function(math){
    var sum = math.add(1+2);
});

两者的区别

1、AMD推崇依赖前置，在定义模块的时候就要声明其依赖的模块

2、CMD推崇就近依赖，只有在用到某个模块的时候再去require

Commonjs简介

Commonjs的应用主要是在Node应用中。

通过require引入文件， 文件内部则通过module.export暴露，如下a 就是 module.export

// 引入某个文件
const a = require(‘some.js‘)

// some.js

module.export = {
  ...
  // some code
}

除去module.export，Commonjs还有一个exports属性（不推荐使用）, 事实上exports就是module.export

// 对外输出接口可以添加变量
var exports = module.exports;
exports.area = function (r) {
  return Math.PI * r * r;
};

exports.circumference = function (r) {
  return 2 * Math.PI * r;
};

// 注意不要直接对exports赋值，这样会切断exports和module的关系
exports = a // 不要这么做

Module简介

ES6的Module是官方正式推出的模块化写法，虽然目前有挺多浏览器还不支持，不过我们可以利用babel将其转换，话不多说，先介绍下Module的基本用法。

ES6的module主要是以import导入想要的对象，export 和 export default导出对象

import x from ‘some.js‘  // 引用some.js中的export default
import {a, b} from ‘some.js‘  // 引用some.js的 export a 和 export b
import x, {a, b} from ‘some.js‘  // 引用 some.js的 export default 和 export a 和 export b

// some.js
const x = () => {}

export const a = () => {}
export const b = () => {}

export default x

因为import是编译时加载，所以import命令具有提升效果，会提升到整个模块的头部，首先执行。

// some code
...
...

import xxx from ‘xxx‘ // 提升到最顶部

Common和Module的区别

1. 加载的时机不同

Common是运行时加载的，可以使用变量或者表达式，如：

 const ‘f‘ + ‘oo‘ =  require(‘my_modules‘)

Module是编译时加载的，不可以使用变量或者表达式， 编译时加载效率较高。

2.暴露出的接口不同

Common暴露出来的是值的拷贝，也就是说，一旦输出一个值，模块内部的变化就影响不到这个值。

// lib.js
var counter = 3;
function incCounter() {
  counter++;
}
module.exports = {
  counter: counter,
  incCounter: incCounter,
}; 
// main.js
var counter = require(‘./lib‘).counter;
var incCounter = require(‘./lib‘).incCounter;

console.log(counter);  // 3
incCounter();
console.log(counter); // 3

Module则相反， 输出的是值的引用。

Module与webpack

webpack本身维护了一套模块系统，这套模块系统兼容了所有前端历史进程下的模块规范，包括 amd commonjs es6 等，为了看module在webpack中是怎么运行的，我们可以看一下下面简单的代码：

// webpack

const path = require(‘path‘);

module.exports = {
  entry: ‘./a.js‘,
  output: {
    path: path.resolve(__dirname, ‘dist‘),
    filename: ‘bundle.js‘,
  }
};

// a.js
import a from ‘./c‘;

export default ‘a.js‘;
console.log(a);
// c.js

export default 333;

打包后的代码如下：

(function(modules) {

  function __webpack_require__(moduleId) {
    var module =  {
      i: moduleId,
      l: false,
      exports: {}
    };
    modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
    return module.exports;
  }

  return __webpack_require__(0);
})([
  (function (module, __webpack_exports__, __webpack_require__) {

    // 引用 模块 1
    "use strict";
    Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
    /* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__c__ = __webpack_require__(1);

/* harmony default export */ __webpack_exports__["default"] = (‘a.js‘);
console.log(__WEBPACK_IMPORTED_MODULE_0__c__["a" /* default */]);

  }),
  (function (module, __webpack_exports__, __webpack_require__) {

    // 输出本模块的数据
    "use strict";
    /* harmony default export */ __webpack_exports__["a"] = (333);
  })
]);

简化一波代码再看，可以看出打包后实际上是一个立即执行函数，并且入参为各个module文件， 最后返回的**是__webpack_require__(0)**：

(function(modules) {

  function __webpack_require__(moduleId) {
  }

  return __webpack_require__(0);
})([module1, module2]);

ok, 我们继续看__webpack_require__函数，可以看出它是调用了我们的入口模块，同时传入了module相关的属性，以及函数本身

function __webpack_require__(moduleId) {
    var module =  {
      i: moduleId,
      l: false,
      exports: {}
    };
    modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
    return module.exports;
  }

那么继续追溯到入口模块，也就是我们的第一个参数我们可以看到入口模块又调用了 webpack_require(1) 去引用入参数组里的第2个函数。

然后会将入参的 webpack_exports 对象添加 default 属性，并赋值。

这里我们就能看到模块化的实现原理，这里的 webpack_exports 就是这个模块的 module.exports 通过对象的引用传参，间接的给 module.exports 添加属性。

最后会将 module.exports return 出来。就完成了 webpack_require 函数的使命。

function (module, __webpack_exports__, __webpack_require__) {

/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__c__ = __webpack_require__(1);

    /* harmony default export */ __webpack_exports__["default"] = (‘a.js‘);
    console.log(__WEBPACK_IMPORTED_MODULE_0__c__["a" /* default */]);

  }

至此，我们可以看出module其实在webpack中，最后的打包结果。

Module与Babel

虽然webpack可以打包转换我们的module，但通常我们都会引入babel来对ES6转成ES5的代码，而Moduel属于ES6，也会被转译。

事实上，babel是将module转换成commonjs,这样 webpack 就无需再做处理，直接使用 webpack 运行时定义的 webpack_require 处理。

不过babel在转换的时候，会有一些特殊的处理， 像下面

首先 export 的时候， 会添加一个__esModule属性到exports，是为了表明这是经过转换的module

export default a

// 转换成
Object.defineProperty(exports, "__esModule", {
  value: true
});

exports.default = a;

再看 转出的

转出其实会多一个_interopRequireDefault函数，就是为了处理default这个属性

import d from ‘d‘
// 转化后
var _d = require(‘d‘);

var _d2 = _interopRequireDefault(_d);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

一些问题

1.为什么有的地方使用 require 去引用一个模块时需要加上 default？

我们在上文 babel 对导出模块的转换提到，es6 的 export default 都会被转换成 exports.default，即使这个模块只有这一个输出。

2.经常在各大UI组件引用的文档上会看到说明 import { button } from ‘xx-ui‘ 这样会引入所有组件内容，需要添加额外的 babel 配置，比如 babel-plugin-component？

import { Button, Select } from ‘element-ui‘
// 转换成
var a = require(‘element-ui‘);
var Button = a.Button;
var Select = a.Select;

babel-plugin-component就做了一件事，将 import { Button, Select } from ‘element-ui‘ 转换成了

import Button from ‘element-ui/lib/button‘
import Select from ‘element-ui/lib/select‘

3.我们在浏览一些 npm 下载下来的 UI 组件模块时（比如说 element-ui 的 lib 文件下），看到的都是 webpack 编译好的 js 文件，可以使用 import 或 require 再去引用。但是我们平时编译好的 js 是无法再被其他模块 import 的，这是为什么？

通过 webpack 模块化原理章节给出的 webpack 配置编译后的 js 是无法被其他模块引用的，webpack 提供了 output.libraryTarget 配置指定构建完的 js 的用途。入口模块返回的 module.exports 赋值给 module.exports

总结

在剖析了整体的流程之后，可以看到相关的技术细节还是比较清晰的，学无止境~~~

引用

import、require、export、module.exports 混合使用详解

Module的语法

前端模块化

Commonjs规范

原文地址：https://www.cnblogs.com/Darlietoothpaste/p/10310835.html

时间： 2024-10-26 23:18:28

前端模块化杂记的相关文章

前端模块化

前端模块化 前端模块化 在JavaScript发展初期就是为了实现简单的页面交互逻辑,寥寥数语即可:如今CPU.浏览器性能得到了极大的提升,很多页面逻辑迁移到了客 户端(表单验证等),随着web2.0时代的到来,Ajax技术得到广泛应用,jQuery等前端库层出不穷,前端代码日益膨胀 这时候JavaScript作为嵌入式的脚本语言的定位动摇了,JavaScript却没有为组织代码提供任何明显帮助,甚至没有类的概念,更不用说模块(module)了,JavaScript极其简单的代码组织规范不足以驾

js前端模块化之加载器原理解析(一)

先来说一下前端模块化的价值:引用模块此处有详细的介绍,可以自行前往观看. 一.总结如下优点: (1)解决命名冲突(2)烦琐的文件依赖(3)模块的版本管理(4)提高可维护性(5)前端性能优化(6)跨环境共享模块 二.加载器的基本思路: 如何去定义我们的模块? 如何将我们定义的模块去合并? 我们想一下,如果我们正常的引用入js到页面我们需要做神马事情,是否是使用:<script type="text/javascript" src="xxx"></sc

前端模块化杂谈

Teambition是一家追求卓越技术的公司,我们工程师都很Geek,我们使用了很多新潮的,开源的技术.同时我们也贡献了很多开源的项目.我们希望能够把一些技术经验分享给大家.于是有了这个「创作随笔」.废话休说,「创作随笔」第一弹,来自我们的前端工程师寸志,谈一谈他在前端模块化开发方面的一些感想. 在模块化方面,Node.js就显得游刃有余. 作为用户,我们把代码放到一个个JavaScript文件中,然后Node.js就有一套规则帮我们把这些代码组织起来,Node.js还有包的概 念,于是我们就可

前端模块化开发的价值

本文发表在<程序员>杂志 2013 年 3 月刊,推荐购买. 前端模块化开发的价值 随着互联网的飞速发展,前端开发越来越复杂.本文将从实际项目中遇到的问题出发,讲述模块化能解决哪些问题,以及如何使用 Sea.js 进行前端的模块化开发. 恼人的命名冲突 我们从一个简单的习惯出发.我做项目时,常常会将一些通用的.底层的功能抽象出来,独立成一个个函数,比如 function each(arr) { // 实现代码 } function log(str) { // 实现代码 } 并像模像样地把这些函

前端模块化发展简史

前端发展日新月异,短短不过 10 年已经从原始走向现代,甚至引领潮流.网站逐渐变成了互联网应用程序,代码量飞速增长,为了支撑这种需求和变化,同时兼顾代码质量.降低开发成本,接入模块化势在必行.伴随这一变化的是相对应的构建工具的快速成长,或是为了优化.或是为了转义,都离不开这类工具. 所谓温故而知新,本篇回顾总结下前端模块化的发展历程及辅助工具.在回顾中可以更清晰的看到当前我们用的方案所处的位置,为什么会发展到这一步,目前模块化方案带来的优势等. 1. 没有模块化的日子 最开始 JavaScrip

前端模块化工具-webpack

详解前端模块化工具-webpack webpack是一个module bundler,抛开博大精深的汉字问题,我们暂且管他叫'模块管理工具'.随着js能做的事情越来越多,浏览器.服务器,js似乎无处不在,这时,使日渐增多的js代码变得合理有序就显得尤为必要,也应运而生了很多模块化工具.从服务器端到浏览器端,从原生的没有模块系统的`<script>`到基于Commonjs和AMD规范的实现到ES6 modules.为了模块化和更好的模块化,我们总是走在探索的路上. 但是这些实现模块化的方法或多或

前端模块化（CommonJs,AMD和CMD）

前端模块规范有三种:CommonJs,AMD和CMD. CommonJs用在服务器端,AMD和CMD用在浏览器环境AMD 是 RequireJS 在推广过程中对模块定义的规范化产出.CMD 是 SeaJS 在推广过程中对模块定义的规范化产出.AMD:提前执行(异步加载:依赖先执行)+延迟执行CMD:延迟执行(运行到需加载,根据顺序执行) 模块 函数写法 function f1(){ //... } function f2(){ //... } 模块就是实现特定功能的文件,把几个函数放在一个文件里

前端模块化方案：CommonJS/AMD/CMD/ES6规范

模块化的开发方式可以提高代码复用率,方便进行代码的管理.通常一个文件就是一个模块,有自己的作用域,只向外暴露特定的变量和函数.目前流行的js模块化规范有CommonJS.AMD.CMD以及ES6的模块系统.前端模块化的演进过程可以看看阮一峰老师的文章.本文主要介绍各规范下的模块化实现方式. 一.CommonJS Node.js是commonJS规范的主要实践者,它有四个重要的环境变量为模块化的实现提供支持:module.exports.require.global.实际使用时,用module.e

前端模块化开发学习之gulp&amp;browserify篇

 随着web应用的发展,前端的比重占得越来越多,编写代码从而也越来越复杂.而通常我们需要将不同功能或者不同模块的代码分开写,最后在html中一起加载,这样做是可以的,但是当你需要进行维护或者是二次开发的时候,你会觉得十分费劲,因为你不知道文件之间复杂的关系,所以我们需要利用一些插件来配合进行模块化的开发. 所谓模块化的开发,写过nodejs的人都知道,文件之间的依赖可以用require()实现,但是浏览器端是不支持这样的依赖形式的,而browserify却可以解决这个问题,再加上gulp这个强大