文章/答案/技术大牛

发布

社区首页 >专栏 >前端模块化方案：前端模块化/插件化异步加载方案探索

前端模块化方案：前端模块化/插件化异步加载方案探索

原创

周陆军博客

发布于 2023-05-14 14:40:01

1.5K00

代码可运行

文章被收录于专栏：前端博客前端博客

运行总次数：0

代码可运行

前端模块化序篇

这里建议先复习一下《再唠叨JS模块化加载之CommonJS、AMD、CMD、ES6》

AMD: define + require
CMD: exports + require
ES6: export + import

之前由于由于ES6本身是原生语言支持实现的模块化，但是现代浏览器大多都还未支持，因此必须使用相应的transpiler工具转换成ES5的AMD,CMD模块，再借助于systemjs/requirejs等模块加载工具才能使用。

前端的模块系统经历了长久的演变，对应的模块化方案也几经变迁。

JavaScript打包方案从最初简单的文件合并，到AMD 的模块具名化并合并，再到browserify将CommonJS 模块转换成为浏览器端可运行的代码，打包器做的事情越来越复杂，角色也越来越重要，加载器貌似在弱化。
Javascript中模块加载器从最初小而简单lab.js/curl.js到RequireJS/sea.js、Browserify、Webpack和SystemJS一直在演进发展。

js语言本身并不支持模块化，同时浏览器中js和服务端nodejs中的js运行环境是不同的，如何实现浏览器中js模块化主流有两种方案：

requirejs/seajs: 是一种在线“编译”模块的方案，相当于在页面上加载一个CommonJS/AMD模块格式解释器。这样浏览器就认识了define, exports,module这些东西，也就实现了模块化。
browserify/webpack：是一个预编译模块打包的方案，相比于第一种方案，这个方案更加智能。由于是预编译的，不需要在浏览器中加载解释器。你在本地直接写JS，不管是AMD/CMD/ES6风格的模块化，它都能认识，并且编译成浏览器认识的JS。

到了2021，以webkit为内核的众多浏览器都支持了es6 原生加载。本篇再来梳理一下前端模块方案。

ES6异步加载

浏览器加载 ES6 模块，也使用<script>标签，但是要加入type="module"属性。

<script type="module" src="./foo.js"></script>

其实这个并没有什么好书的。我想说的是在代码中异步加载模块。实现cmd的效果。比如：

app/es6-file.js:

export class q {
export let counter = 3;
export function incCounter() {
  counter++;
}

浏览器加载：

<script>
  import { counter, incCounter } from './lib';
  // import { counter, incCounter } from 'https://www.zhoulujun.cn/demo/lib'; 
   console.log(counter); // 3
  incCounter();
  console.log(counter); // 4
</script>

ES6模块定义名为export，提供一个静态构造函数访问器。

更多的推荐阅读

ES6模块加载实现，以及异步加载 https://juejin.cn/post/7002007274877091870
万岁，浏览器原生支持ES6 export和import模块啦！ https://www.zhangxinxu.com/wordpress/2018/08/browser-native-es6-export-import-module/

es5时代模块加载器

比较代表性的就是require.js/sea.js、Browserify

AMD阵营

超快速AMD入门 (Super Quick AMD Primer)

如果您不熟悉AMD的结构，我将为您提供您所听到的最简单的解释。 AMD是您用来异步定义和要求模块的系统。定义返回一个或零个对象。 define和require的第一个参数通常是一个依赖项数组。第二个参数是一个函数； define返回结果，require执行基本的回调：

// "define" a module
define(["namespace/dependencyA", "namespace/dependencyB"], function(depA, depB) {
	// Whole bunch of processing
	
	
	// Return what this module defines
	return function() {
		// Or an object, or whatever
	}
});
// "require" to use modules:
require(["namespace/dependencyC"], function(depC) {
	
	// depC can be used in here only
	// Yay for modularity!

有数十种AMD JavaScript加载程序可用，其中最受欢迎的是RequireJS。还有鲜为人知JavaScript加载程序，例如YepNope，script.js，LAB.js和Dojo的新本机加载程序。我最先接触的就是 curl.js，具体查看 https://github.com/cujojs/curl。

Require.JS

RequireJS 是一个JavaScript 模块加载器，基于AMD 规范实现。

它同时也提供了对模块进行打包与构建的工具r.js，通过将开发时单独的匿名模块具名化并进行合并，实现线上页面资源加载的性能优化。

RequireJS 与r.js 等一起提供的一个模块化构建方案。

Require是出现在2009年，它完全不同于之前的那些懒加载器，它将脚本标签写入到DOM中，监听完成的事件，然后递归加载依赖：

<script src=“tools/require.js” data-main=“myAppInit.js” ></script>

...或者如下调用指明的函数名称...

<script src=“tools/require.js”></script>

再调用

<script>
require([‘myAppInit’, ‘libs/jQuery’], function (myApp, $) { ...
</script>

上面两个用法不建议同时使用。虽然Require存在各种特殊情况，但是其灵活性和强大性还是支持它成为浏览器端流行的加载器。

更多参看官网：https://requirejs.org/

Browserify

https://browserify.org/

Browserify允许CommonJS格式模块在前端使用，主要用于在浏览器中使用 npm 包，最终会转换为 commonJS (require) 类似方式，在浏览器使用。

它不只是一个模块加载器，而是模块捆绑器(bundler)，是一个完整的代码构建段的工具，提供客户端能加载一堆代码的功能。

首先需要node和npm已经安装，获得包：

npm install -g –save-dev browserify

以CommonaJS格式编写你的模块即可。然后使用下面命令捆绑：

npm install -g –save-dev browserify

它会递归以此发现entry-point中所有依赖包，然后将它们组装在一个单个文件中：

<script src=”bundle-name.js”></script>

对于前端，你可以最小化合并核心代码，然后让可选模块在之后需要时加载，这样即节约了带宽也不影响模块编程功能实现。

更多请参看官网：https://browserify.org/

Browserify缺点

基于流 Stream，旧时代产物，尽管也能勉强处理 css（CSS bundlers），html（brfs），但是不太友好，且年久失修

browserify必须把源代码打成bundle然后再引用，就决定了他不能直接调试源代码，这对于程序员是很不友好的。虽然我们可以使用 watchify(可以动态把你写的代码立即编译成bundle) 和 --debug 选项(给编译后的代码加上source maps)。但是依然只是近似于直接调试源代码。

SystemJS

https://github.com/systemjs/

Systemjs是一个可配置模块加载器，为浏览器和NodeJs启用动态的Es模板加载器。任何具有标准的URL都可被加载为一个模块：

<script src="system.js"></script>
<script>
  // 加载相对于当前地址的url
  SystemJS.import('./local-module.js');
  // 加载绝对url的地址
  SystemJS.import('https://code.jquery.com/jquery.js');
</script>

可以加载任何类型的模块格式，并由SystemJS自动检测。

SystemJS 诞生于 2015 年，那个时候 ES Module 还未成为标准，在浏览器端只能通过 requirejs、seajs 等方案实现模块加载，随着 npm 在前端界的流行，一个项目中可能存在多种模块规范，所以我认为 SystemJS 最初诞生的目的是为了做一个通用的模块加载器，在浏览器端实现对 CommonJS、AMD、UMD 等各种模块的加载。 SystemJS 是（浏览器尚未正式支持importMap）原生 ES Module 的替代品，ES Module 被编译成 System.register 格式之后能够跑在旧版本的浏览器当中。

在本地运行时，请确保从本地服务器或启用了本地XHR请求的浏览器运行。如果不是，将会收到一条错误消息。

对于Mac上的Chrome，您可以运行它： /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files &> /dev/null & 在Firefox中，这需要导航到about:config，进入security.fileuri.strict_origin_policy过滤器框并将选项切换为false。

SystemJS加载配置

baseURL

baseURL提供了一种根据一个相对地址装载模块的机制。

这使得能够从许多不同的请求URL访问相同的模块

SystemJS.config({
  // set all requires to "lib" for library code
  baseURL: '/lib/',
   // set "app" as an exception for our application code
    paths: {
      'app/*': '/app/*.js'
    }
});
// 加载 /modules/jquery.js
SystemJS.import('jquery.js');<br>

更多的参看官方文档：https://github.com/systemjs/systemjs

es5时代模块打包方案

Grunt和Gulp属于任务流工具Tast Runner , 而 webpack属于模块打包工具 Bundler。

grunt

https://gruntjs.com/

Grunt 是老牌的构建工具，特点是配置驱动，你需要做的就是了解各种插件的功能，然后把配置整合到 Gruntfile.js 中

module.exports = function(grunt) {
  grunt.initConfig({
    // js格式检查任务
    jshint: {
      files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'],
      options: {
        globals: {
          jQuery: true
        }
      }
    },
    //  代码压缩打包任务
    uglify: {}
    watch: {
      files: ['<%= jshint.files %>'],
      tasks: ['jshint']
    }
  });
  grunt.initConfig({

  });
  // 导入任务插件
  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadnpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-watch');
  // 注册自定义任务, 如果有多个任务可以添加到数组中
  grunt.regusterTask('default', ['jshint'])
};

Grunt 缺点也是配置驱动，当任务非常多的情况下，试图用配置完成所有事简直就是个灾难；再就是它的 I/O 操作也是个弊病，它的每一次任务都需要从磁盘中读取文件，处理完后再写入到磁盘，例如：我想对多个 less 进行预编译、压缩操作，那么 Grunt 的操作就是：

读取 less 文件 -> 编译成 css -> 存储到磁盘 -> 读取 css -> 压缩处理 -> 存储到磁盘

这样一来当资源文件较多，任务较复杂的时候性能就是个问题了。

glup

https://gulpjs.com/

Gulp是后起之秀。他们的本质都是通过 JavaScript 语法实现了shell script 命令的一些功能。比如利用jshint插件实现 JavaScript 代码格式检查这一个功能。早期需要手动在命令行中输入 jshint test.js，而 Grunt 则通过文件 Gruntfile.js 进行配置

Gulp吸取了Grunt的优点，拥有更简便的写法，通过流（Stream）的概念来简化多任务之间的配置和输出，让任务更加简洁和容易上手。

Gulp 特点是代码驱动，写任务就和写普通的 Node.js 代码一样：

// gulpfile.js
var gulp = require('gulp');
var jshint = require('gulp-jshint');
var uglify = require('gulp-uglify');

// 代码检查任务 gulp 采取了pipe 方法，用流的方法直接往下传递
gulp.task('lint', function() {
  return gulp.src('src/test.js')
    .pipe(jshint())
    .pipe(jshint.reporter('default'));
});

// 压缩代码任务
gulp.task('compress'， function() {
  return gulp.src('src/test.js')
    .pipe(uglify())
    .pipe(gulp.dest('build'));
});

// 将代码检查和压缩组合，新建一个任务
gulp.task('default', ['lint', 'compress']);

再一个对文件读取是流式操作（Stream），也就是说一次 I/O 可以处理多个任务，还是 less 的例子，Gulp 的流程就是：

读取 less 文件 -> 编译成 css -> 压缩处理 -> 存储到磁盘

在 Grunt 与 Gulp 对比看来还是比较推荐 Gulp！

webpack

https://webpack.js.org/

传统的模块化基于单种编程语言，目的是为了解耦和重用，而因为前端本身的特点（需要三种编程语言配合）以及能力限制，所以不能实现跨资源加载也就难以实现组件化。

而 Webpack 打破的这种思维局限，它的 Require anything 的理念在实现模块化的同时也能够很方便实现组件化，借助 Webpack 就可以很轻松的实现这种代码组织结构：

Webpack 的特点：

把一切都视为模块：不管是 CSS、JS、Image 还是 HTML 都可以互相引用，通过定义 entry.js，对所有依赖的文件进行跟踪，将各个模块通过 loader 和 plugins 处理，然后打包在一起。
按需加载：打包过程中 Webpack 通过 Code Splitting 功能将文件分为多个 chunks，还可以将重复的部分单独提取出来作为 commonChunk，从而实现按需加载。

Webpack 也是通过配置来实现管理，与 Grunt 不同的时，它包含的许多自动化的黑盒操作所以配置起来会简单很多（但遇到问题调试起来就很麻烦），一个典型的配置如下：

module.exports = {
    //插件项
    plugins: [commonsPlugin],
    //页面入口文件配置
    entry: {
        index : './src/js/page/index.js'
    },
    //入口文件输出配置
    output: {
        path: 'dist/js/page',
        filename: '[name].js'
    },
    module: {
        //加载器配置
        loaders: [
            { test: /\.css$/, loader: 'style-loader!css-loader' },
            { test: /\.js$/, loader: 'jsx-loader?harmony' },
            { test: /\.scss$/, loader: 'style!css!sass?sourceMap'},
            { test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'}
        ]
    },
    //其它解决方案配置
    resolve: {
        root: '/Users/Bell/github/flux-example/src', //绝对路径
        extensions: ['', '.js', '.json', '.scss'],
        alias: {
            AppStore : 'js/stores/AppStores.js',
            ActionType : 'js/actions/ActionType.js',
            AppAction : 'js/actions/AppAction.js'
        }
    }
};