前端构建笔记

GGMU353
175 阅读11分钟

基于浏览器的模块化

commonJs requireJs AMD CMD import form/export default

CommonJs

Nodejs 环境所使用的模块系统就是基于CommonJs规范实现的，我们现在所说的CommonJs规范也大多是指Node的模块系统

关键字：module.exports exports

// foo.js

//一个一个 导出
module.exports.age = 1
module.exports.foo = function(){}
exports.a = 'hello'

//整体导出
module.exports = { age: 1, a: 'hello', foo:function(){} }

//整体导出不能用`exports` 用exports不能在导入的时候使用
exports = { age: 1, a: 'hello', foo:function(){} }

这里需要注意 exports 不能被赋值，可以理解为在模块开始前exports = module.exports， 因为赋值之后exports失去了 对module.exports的引用，成为了一个模块内的局部变量

模块导入

关键字：require

const foo = require('./foo.js')
console.log(foo.age) //1

假设以下目录为 src/app/index.js 的文件 调用 require()

模块导入规则：

./moduleA 相对路径开头

在没有指定后缀名的情况下
先去寻找同级目录同级目录：src/app/

  • src/app/moduleA 无后缀名文件 按照javascript解析
  • src/app/moduleA.js js文件 按照javascript解析
  • src/app/moduleA.json json文件 按照json解析
  • src/app/moduleA.node node文件 按照加载的编译插件模块dlopen

同级目录没有 moduleA 文件会去找同级的 moduleA目录：src/app/moduleA

  • src/app/moduleA/package.json 判断该目录是否有package.json文件， 如果有 找到main字段定义的文件返回， 如果 main 字段指向文件不存在 或 main字段不存在 或 package.json文件不存在向下执行
  • src/app/moduleA/index.js
  • src/app/moduleA/index.json
  • src/app/moduleA/index.node

结束

/module/moduleA 绝对路径开头

直接在/module/moduleA目录中寻找 规则同上

react 没有路径开头

没有路径开头则视为导入一个包
会先判断moduleA是否是一个核心模块 如path，http，优先导入核心模块
不是核心模块 会从当前文件的同级目录的node_modules寻找

  • /src/app/node_modules/ 寻找规则同上 以导入react为例 先 node_modules 下 react 文件 -> react.js -> react.json -> react.node ->react目录 -> react package.json main -> index.js -> index.json -> index.node 如果没找到 继续向父目录的node_modules中找
  • /src/node_modules/
  • /node_modules/

直到最后找不到 结束

es6 module

import 规则

  • import { } from 'module'， 导入module.js的命名导出
  • import defaultExport from 'module'， 导入module.js的默认导出
  • import * as name from 'module'， 将module.js的的所有导出合并为name的对象，key为导出的命名，默认导出的key为default
  • import 'module'，副作用，只是运行module，不为了导出内容例如 polyfill，多次调用次语句只能执行一次
  • import('module')，动态导入返回一个 Promise，TC39的stage-3阶段被提出 tc39 import
common.js 和 ES6 Module 区别
  • CommonJs导出的是变量的一份拷贝，ES6 Module导出的是变量的绑定（export default 是特殊的）
  • CommonJs是单个值导出，ES6 Module可以导出多个
  • CommonJs是动态语法可以写在判断里，ES6 Module静态语法只能写在顶层
  • CommonJs的 this 是当前模块，ES6 Module的 this 是 undefined

bundle 类的构建工具

Grunt

Grunt可以帮我们自动化处理需要反复重复的任务，例如压缩（minification）、编译、单元测试、linting 等，还有强大的插件生态。

module.exports = function (grunt) {
  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON("package.json"),
    uglify: {
      options: {
        banner:
          '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
      },
      build: {
        src: "src/<%= pkg.name %>.js",
        dest: "build/<%= pkg.name %>.min.js",
      },
    },
  });

  // 加载包含 "uglify" 任务的插件。
  grunt.loadNpmTasks("grunt-contrib-uglify");

  // 默认被执行的任务列表。
  grunt.registerTask("default", ["uglify"]);
};

Gulp

gulp 基于代码配置和对 Node.js 流的应用使得构建更简单、更直观。可以配置更加复杂的任务。

var browserify = require("browserify");
var source = require("vinyl-source-stream");
var buffer = require("vinyl-buffer");
var uglify = require("gulp-uglify");
var size = require("gulp-size");
var gulp = require("gulp");

gulp.task("build", function () {
  var bundler = browserify("./index.js");

  return bundler
    .bundle()
    .pipe(source("index.js"))
    .pipe(buffer())
    .pipe(uglify())
    .pipe(size())
    .pipe(gulp.dest("dist/"));
});

WebPack

Grunt/Gulp/browserify 都是偏向于工具，而 webpack将以上功能都集成到一起，相比于工具它的功能大而全。 webpack主要的三个模块就是

  • 核心流程
  • loader
  • plugins

webpack依赖于Tapable做事件分发，内部有大量的hooks钩子，在Compiler和compilation 核心流程中通过钩子分发事件，在plugins中注册钩子，实际代码全都由不同的内置 plugins 来执行，而 loader 在中间负责转换代码接受一个源码处理后返回处理结果content string -> result string。

  1. 通过命令行和 webpack.config.js 来获取参数
  2. 创建compiler对象，初始化plugins
  3. 开始编译阶段，addEntry添加入口资源
  4. addModule 创建模块
  5. runLoaders 执行 loader
  6. 依赖收集，js 通过acorn解析为 AST，然后查找依赖，并重复 4 步
  7. 构建完依赖树后，进入生成阶段，调用compilation.seal
  8. 经过一系列的optimize优化依赖，生成 chunks，写入文件

webpack 缺点

  • 配置复杂
  • 大型项目构建慢

配置复杂这一块一直是webpack被吐槽的一点，主要还是过重的插件系统，复杂的插件配置，插件文档也不清晰，更新过快插件没跟上或者文档没跟上等问题。

比如现在 webpack 已经到 5 了网上一搜全都是 webpack3 的文章，往往是新增一个功能，按照文档配置完后，诶有报错，网上一顿查，这里拷贝一段，那里拷贝一段，又来几个报错，又经过一顿搞后终于可以运行。

后来针对这个问题，衍生出了前端脚手架，react出了create-react-app，vue出了vue-cli，脚手架内置了webpack开发中的常用配置，达到了 0 配置，开发者无需关心 webpack 的复杂配置。

rollup

基于ES module``rollup编译ES6模块，提出了Tree-shaking，根据ES module静态语法特性，删除未被实际使用的代码，支持导出多种规范语法，并且导出的代码非常简洁，如果看过 vue 的dist 目录代码就知道导出的 vue 代码完全不影响阅读。

rollup的插件系统支持：babel、CommonJs、terser、typescript等功能。

相比于browserify的CommonJs，rollup专注于ES module。
相比于webpack大而全的前端工程化，rollup专注于纯javascript，大多被用作打包tool工具或library库。

react、vue 等库都使用rollup打包项目，并且下面说到的vite也依赖rollup用作生产环境打包 js

Tree-shaking
export const a = 1;
export const b = 2;

import { a } from "./num";

console.log(a);

最终打包下来const b = 2 会被删掉，这依赖ES module的静态语法，在编译阶段就可以确定模块的导入导出有哪些变量。 CommonJs 因为是基于运行时的模块导入，其导出的是一个整体，并且require(variable)内容可以为变量，所以在ast编译阶段没办法识别为被使用的依赖。

webpack4中也开始支持tree-shaking，但是因为历史原因，有太多的基于CommonJS代码，需要额外的配置。

parcel

上面提到过webpack的两个缺点，而parcel的诞生就是为了解决这两个缺点，parcel 主打极速零配置。 parcel 使用 worker 进程去启用多核编译，并且使用文件缓存。

parcel 支持 0 配置，内置了 html、babel、typescript、less、sass、vue等功能，无需配置，并且不同于webpack只能将 js 文件作为入口，在 parcel 中万物皆资源，所以 html 文件 css 文件都可以作为入口来打包。

所以不需要webpack的复杂配置，只需要一个parcel index.html命令就可以直接起一个自带热更新的server来开发vue/react项目。 parcel 也有它的缺点：

  • 0 配置的代价，0 配置是好，但是如果想要配置一些复杂的配置就很麻烦。
  • 生态，相比于webpack比较小众，如果遇到错误查找解决方案比较麻烦。
  1. commander 获取命令
  2. 启动 server 服务，启动 watch监听文件，启动 WebSocket 服务用于 hmr，启动多线程
  3. 如果是第一次启动，针对入口文件开始编译
  4. 根据扩展名生成对应asset资源，例如jsAsset、cssAsset、vueAsset，如果parcel识别 less 文件后项目内如果没有 less 库会自动安装
  5. 读取缓存，如果有缓存跳到第 7 步
  6. 多线程编译文件，调用 asset 内方法parse -> ast -> 收集依赖 -> transform(转换代码) -> generate(生成代码)，在这个过程中收集到依赖，编译完结果写入缓存
  7. 编译依赖文件，重复第 4 步开始
  8. createBundleTree 创建依赖树，替换 hash 等，package打包生成最终代码
  9. 当watch文件发生变化，重复第 4 步，并将结果 7 通过WebSocket发送到浏览器，进行热更新。

browserify、webpack、rollup、parcel这些工具的思想都是递归循环依赖，然后组装成依赖树，优化完依赖树后生成代码。
但是这样做的缺点就是慢，需要遍历完所有依赖，即使 parcel 利用了多核，webpack 也支持多线程，在打包大型项目的时候依然慢可能会用上几分钟，存在性能瓶颈。

基于浏览器 ES 模块的构建工具

所以基于浏览器原生 ESM 的运行时打包工具出现：

4110034938-74797e267da26ac0_fix732 (1).png 561717042-601f63c1c0f88_fix732.png 仅打包屏幕中用到的资源，而不用打包整个项目，开发时的体验相比于 bundle类的工具只能用极速来形容。
（实际生产环境打包依然会构建依赖方式打包）

snowpack 和 vite

因为 snowpack 和 vite 比较类似，都是bundleless所以一起拿来说

bundleless类运行时打包工具的启动速度是毫秒级的，因为不需要打包任何内容，只需要起两个server，一个用于页面加载，另一个用于HMR的WebSocket，当浏览器发出原生的ES module请求，server收到请求只需编译当前文件后返回给浏览器不需要管依赖。

bundleless工具在生产环境打包的时候依然bundle构建所以依赖视图的方式，vite 是利用 rollup 打包生产环境的 js 的。

原理拿 vite 举例：

vite在启动服务器后，会预先以所有 html 为入口，使用 esbuild 编译一遍，把所有的 node_modules 下的依赖编译并缓存起来，例如vue缓存为单个文件。

当打开在浏览器中输入链接，渲染index.html文件的时候，利用浏览器自带的ES module来请求文件。

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

vite 收到一个src/main.js的 http 文件请求，使用esbuild开始编译main.js，这里不进行main.js里面的依赖编译。

import { createApp } from "vue";
import App from "./App.vue";

createApp(App).mount("#app");

浏览器获取到并编译main.js后，再次发出 2 个请求，一个是 vue 的请求，因为前面已经说了 vue 被预先缓存下来，直接返回缓存给浏览器，另一个是App.vue文件，这个需要@vitejs/plugin-vue来编译，编译完成后返回结果给浏览器（@vitejs/plugin-vue会在脚手架创建模板的时候自动配置）。

因为是基于浏览器的ES module，所以编译过程中需要把一些 CommonJs、UMD 的模块都转成 ESM。

Vite 同时利用 HTTP 头来加速整个页面的重新加载（再次让浏览器为我们做更多事情）：源码模块的请求会根据 304 Not Modified 进行协商缓存，而依赖模块请求则会通过 Cache-Control: max-age=31536000,immutable 进行强缓存，因此一旦被缓存它们将不需要再次请求，即使缓存失效只要服务没有被杀死，编译结果依然保存在程序内存中也会很快返回。

上面多次提到了esbuild，esbuild使用 go 语言编写，所以在 i/o 和运算运行速度上比解释性语言 NodeJs 快得多，esbuild 号称速度是 node 写的其他工具的 10~100 倍。

ES module 依赖运行时编译的概念 + esbuild + 缓存 让 vite 的速度远远甩开其他构建工具。

turbopack

Turbopack 是基于 SWC 的 JavaScript 和 TypeScript 优化的增量打包工具和构建系统，采用 Rust 编写,其实 Turbopack 正是出自 Webpack 作者 Tobias Koppers 之手，这是他去年加入 Vercel 之后所主导的核心项目。Tobias 深度参与了 Turbopack 的开发。

turbo引擎把一些函数标记为remembered，当这些函数被调用时，turbo引擎缓存这些函数被调用的内容以及返回的内容。当某些文件变化时，只需要把变化的文件重新打包并更新缓存即可，没有变化的文件，直接从缓存中读取已经构建过的内容即可。

turbopack 将执行的每一条脚本称之为任务，它会对每一个任务的结果进行缓存

当进行build任务时，先到缓存中读取被构建的文件的缓存，如果找不到就进行构建，构建完毕把结果写入缓存

原文链接：segmentfault.com/a/119000004…

avatar
文章
阅读
粉丝