前言

我想这两年，应该是「Webpack」受冲击最明显的时间段。前有「Snowpack」基于浏览器原生ES Module 提出，后有「Vite」站在「Vue3」肩膀上的迅猛发展，真的是后浪推前浪，前浪....

并且，「Vite」主推的实现技术不是一点点新，典型的一点使用「esbuild」来充当「TypeScript」的解释器，这一点是和目前社区内绝大多数打包工具是不同的。

在下一篇文章，我将会介绍什么是「esbuild」，以及其带来的价值。

但是，虽说后浪确实很强，不过起码近两年来看「Webpack」所处的地位是仍然不可撼动的。所以，更好地了解「Webpack」相关的原理，可以加强我们的个人竞争力。

那么，回到今天的正题，我们就来从零实现一个「Webpack」的 Bundler 打包机制。

1 Bundler 打包背景

Bundler 打包背景，即它是什么？Bundler 打包指的是我们可以将模块化的代码通过构建模块依赖图、解析代码、执行代码等一系列手段来将模块化的代码聚合成可执行的代码。

在平常的开发中，我们经常使用的就是 ES Module 的形式进行模块间的引用。那么，为了实现一个 Bundler 打包，我们准备这样一个例子：

目录

|—— src
    |-- person.js
    |-- introduce.js
    |-- index.js    ## 入口
|—— bundler.js      ## bundler 打包机制

代码

// person.js
export const person = 'my name is wjc'
// introduce.js
import { person } from "./person.js";

const introduce = `Hi, ${person}`;
export default introduce;
// index.js
import introduce from "./introduce.js";

console.log(introduce);

除开 bundler.js 打包机制实现文件，另外我们创建了三个文件，它们分别进行了模块间的引用，最终它们会被 Bundler 打包机制解析生成可执行的代码。

接下来，我们就来一步步地实现 Bundler 打包机制。

2 单模块解析

Bundler 的打包实现第一步，我们需要知道每个模块中的代码，然后对模块中的代码进行依赖分析、代码转化，从而保证代码的正常执行。

首先，从入口文件 index.js 开始，获取其文件的内容（代码）：

const fs = require("fs")

const moduleParse = (file = "") => {
  const rawCode = fs.readFileSync(file, 'utf-8')
}

获取到模块的代码后，我们需要知道它依赖了哪些模块？这个时候，我们需要借助两个 babel 的工具：@babel/parser 和 @babel/traverse。前者负责将代码转化为「抽象语法树 AST」，后者可以根据模块的引用构建依赖关系。

@babel/parser 将模块的代码解析成「抽象语法树 AST」：

const rawCode = fs.readFileSync(file, 'utf-8')
const ast = babelParser(rawCode, {
  sourceType: "module"
})

@babel/traverse 根据模块的引用标识 ImportDeclaration 来构建依赖：

const dependencies = {};
traverse(ast, {
  ImportDeclaration({ node }) {
    const dirname = path.dirname(file);
    const absoulteFile = `./${path
      .join(dirname, node.source.value)
      .replace("\\", "/")}`;
    dependencies[node.source.value] = absoulteFile;
  },
});

这里，我们通过 @babel/traverse 来将入口 index.js 依赖的模块放到 dependencies 中:

// dependencies
{ './intro.js' : './src/intro.js' }

但是，此时 ast 中的代码还是初始 ES6 的代码，所以，我们需要借助 @babel/preset-env 来将其转为 ES5 的代码：

const { code } = babel.transformFromAst(ast, null, {
  presets: ["@babel/preset-env"],
});

index.js 转化后的代码：

"use strict";
var _introduce = _interopRequireDefault(require("./introduce.js "));
function _interopRequireDefault(obj) { 
  return obj && obj.__esModule ?
	obj : {
		"default": obj
	};
}
console.log(_introduce["default"]);

到此，我们就完成了对单模块的解析，完整的代码如下：

const moduleParse = (file = "") => {
  const rawCode = fs.readFileSync(file, "utf-8");
  const ast = babelParser.parse(rawCode, {
    sourceType: "module",
  });
  const dependencies = {};
  traverse(ast, {
    ImportDeclaration({ node }) {
      const dirname = path.dirname(file);
      const absoulteFile = `./${path
        .join(dirname, node.source.value)
        .replace("\\", "/")}`;
      dependencies[node.source.value] = absoulteFile;
    },
  });
  const { code } = babel.transformFromAst(ast, null, {
    presets: ["@babel/preset-env"],
  });

  return {
    file,
    dependencies,
    code,
  };
};

接下来，我们就开始模块依赖图的构建。

2 构建模块依赖图

众所周知，「Webpack」的打包过程会构建一个模块依赖图，它的形成无非就是从入口文件出发，通过它的引用模块，进入该模块，继续单模块的解析，不断重复这个过程。大致的逻辑图如下：

所以，在代码层面，我们需要从入口文件出发，先调用 moduleParse() 解析它，然后再遍历获取其对应的依赖 dependencies，以及调用 moduleParse()：

const buildDependenceGraph = (entry) => {
  const entryModule = moduleParse(entry);
  const rawDependenceGraph = [entryModule];
  for (const module of rawDependenceGraph) {
    const { dependencies } = module;
    if (Object.keys(dependencies).length) {
      for (const file in dependencies) {
        rawDependenceGraph.push(moduleParse(dependencies[file]));
      }
    }
  }
  // 优化依赖图
  const dependenceGraph = {};
  rawDependenceGraph.forEach((module) => {
    dependenceGraph[module.file] = {
      dependencies: module.dependencies,
      code: module.code,
    };
  });

  return dependenceGraph;
};

最终，我们构建好的模块依赖图会放到 dependenceGraph。现在，对于我们这个例子，构建好的依赖图会是这样：

{ 
  './src/index.js':
   { 
     dependencies: { './introduce.js': './src/introduce.js' },
     code: '"use strict";\n\nvar...'     
    },
  './src/introduce.js':{ 
    dependencies: { 
      './person.js': './src/person.js' 
    },
    code: '"use strict";\n\nObject.defineProperty(exports,...' 
  },
  './src/person.js':
   { 
     dependencies: {},
     code: '"use strict";\n\nObject.defineProperty(exports,...' 
    } 
}

3 生成可执行代码

构建完模块依赖图后，我们需要根据依赖图将模块的代码转化成可以执行的代码。

由于 @babel/preset-env 处理后的代码用到了两个不存在的变量 require 和 exports。所以，我们需要定义好这两个变量。

require 主要做这两件事：

• 根据模块名，获取对应的代码并执行。

eval(dependenceGraph[module].code)

• 处理模块名，由于引用的时候是相对路径，这里需要转成绝对路径，并且递归执行依赖模块代码

function _require(relativePath) {
  return require(dependenceGraph[module].dependencies[relativePath]);
}

而 export 则用于存储定义的变量，所以我们定义一个对象来存储。完整的生成代码函数 generateCode 定义：

const generateCode = (entry) => {
  const dependenceGraph = JSON.stringify(buildDependenceGraph(entry));
  return `
  (function(dependenceGraph){
    function require(module) {
      function localRequire(relativePath) {
        return require(dependenceGraph[module].dependencies[relativePath]);
      };
      var exports = {};
      (function(require, exports,  code) {
        eval(code);
      })(localRequire, exports, dependenceGraph[module].code);
      return exports;
    }
    require('${entry}');
  })(${dependenceGraph});
  `;
};

4 完整的 bundler 打包机制实现代码

完整的 Bunlder 打包实现代码：

const fs = require("fs");
const path = require("path");
const babelParser = require("@babel/parser");
const traverse = require("@babel/traverse").default;
const babel = require("@babel/core");

const moduleParse = (file = "") => {
  const rawCode = fs.readFileSync(file, "utf-8");
  const ast = babelParser.parse(rawCode, {
    sourceType: "module",
  });
  const dependencies = {};
  traverse(ast, {
    ImportDeclaration({ node }) {
      const dirname = path.dirname(file);
      const absoulteFile = `./${path
        .join(dirname, node.source.value)
        .replace("\\", "/")}`;
      dependencies[node.source.value] = absoulteFile;
    },
  });
  const { code } = babel.transformFromAst(ast, null, {
    presets: ["@babel/preset-env"],
  });

  return {
    file,
    dependencies,
    code,
  };
};

const buildDependenceGraph = (entry) => {
  const entryModule = moduleParse(entry);
  const rawDependenceGraph = [entryModule];
  for (const module of rawDependenceGraph) {
    const { dependencies } = module;
    if (Object.keys(dependencies).length) {
      for (const file in dependencies) {
        rawDependenceGraph.push(moduleParse(dependencies[file]));
      }
    }
  }
  // 优化依赖图
  const dependenceGraph = {};
  rawDependenceGraph.forEach((module) => {
    dependenceGraph[module.file] = {
      dependencies: module.dependencies,
      code: module.code,
    };
  });
  return dependenceGraph;
};

const generateCode = (entry) => {
  const dependenceGraph = JSON.stringify(buildDependenceGraph(entry));
  return `
  (function(dependenceGraph){
    function require(module) {
      function localRequire(relativePath) {
        return require(dependenceGraph[module].dependencies[relativePath]);
      };
      var exports = {};
      (function(require, exports,  code) {
        eval(code);
      })(localRequire, exports, dependenceGraph[module].code);
      return exports;
    }
    require('${entry}');
  })(${dependenceGraph});
  `;
};

const code = generateCode("./src/index.js");

最终，我们拿到的 code 就是 Bundler 打包后生成的可执行代码。接下来，我们可以将它直接复制到浏览器的 devtool 中执行，查看结果。

结语

虽然，这个 Bundler 打包机制的实现，只是简易版的，它只是大致地实现了整个「Webpack」的 Bundler 打包流程，并不是适用于所有用例。但是，在我看来很多东西的学习都应该是从易到难，这样的吸收效率才是最高的。

前言

相信很多关注 Monorepo 生态的同学，应该大都看过这篇文章 monorepo.tools，其中列举了现存的几个主流的 Monorepo 相关的工具：

• Bazel (by Google)
• Lage (by Microsoft)
• Lerna
• Nx (by Nrwl)
• Rush (by Microsoft)
• Turborepo (by Vercel)

相应地，在这篇文章中也对各类工具进行了一一介绍。并且，我相信每个看过这篇文章的同学，都会留下这么个疑问：这么多 Monorepo Tool，我要如何进行选型？

这里，我给出的答案是 PNPM + Turborepo + Changesets。那么，又为什么是这 3 者呢？下面，我将会分别围绕这 3 个技术展开，来一一解答这个选型的原因以及怎么做。

PNPM

PNPM 的动机（Motivation），如它在官方文档介绍的所说：“Saving disk space and boosting installation speed”，节省磁盘空间和提高安装速度。除开这个动机描述的显著优点外，PNPM 内置了对 Monorepo 的支持，并解决了很多令人诟病的问题。

其中，比较经典的就是 Phantom dependencies（幻影依赖）。由于，默认情况下 yarn、npm 安装的依赖都是会被提升。所以，有时候你可能会遇到 Monorepo 项目中的某个包中的 package.json 没有安装这个依赖，结果实际代码中却使用了这个依赖...

虽说，PNPM 可以解决这个问题，但是，默认情况下 PNPM 安装的依赖也是会被提升的。如果，需要 PNPM 禁止依赖提升，我们可以通过在 Monorepo 项目工作区下的 .npmrc 文件中 配置，例如只提升 lodash：

hoist-pattern[]=*lodash*

当然，还有一些其他的问题，有兴趣的同学可以看 ELab 团队写的这篇文章《Monorepo 的这些坑，我们帮你踩过了！》。

那么，在简单解答了为什么用 PNPM 后，下面我们来看一下要怎么用？

Workspace 配置

要使用 PNPM 的 Monorepo 很简单，只需要在 Monorepo 项目的工作区下新建 pnpm-workspace.yaml 文件并配置：

packages:
  - 'packages/**'

接下来，则是记忆常用依赖和多包任务执行相关的命令。由于，我们的技术选型中有 Turborepo，它会负责多包任务的执行。所以，这里只需要记忆常用依赖相关的命令。

常用依赖相关命令

pnpm i

在 PNPM 中，安装依赖可以用 pnpm i 来完成。在 Monorepo 的场景下，默认情况下 pnpm i 会安装所有的依赖（包括 packages/*）。此外，pnpm i 还需要用到 3 个选项（Option）：

• --filter <package>，安装依赖到指定的 package，不声明要安装的依赖包则默认安装 package.json 中的所有依赖
• --prod, P，安装依赖到 dependencies
• --dev, D，安装依赖到 devDependencies

pnpm remove

在 PNPM 中，删除在 package.json 中的某个依赖，可以用 pnpm remove 完成。它的选项（Option）使用和 pnpm i 大同小异。其中，不同地是当我们在工作区想要删除 packages 中所有包的 package.json 中的某个依赖的时候，需要使用 -r，例如移除所有包中的 lodash：

pnpm remove lodash -r

当然，可能还有同学有一些其他的诉求，有兴趣的同学可以移步文档了解，这里不做展开。

Changesets

经常维护开源项目的同学都知道的一点，每次包（Package）的发布，需要修改 package.json 的 version 字段，以及同步更新一下本次发布修改的 CHANGELOG.md。

这么一来，就会凸显一个问题，每次发布都需要手动地去更新 version、更新 CHANGELOG.md，未免有点繁琐。并且，用过 Lerna 的同学，应该都知道 Lerna 内置了对这块的支持。

但是，无论是 PNPM 又或者是下面要说的 Turborepo 都不支持这块，所以 2 者的官方文档都给大家推荐了用于支持这块能力的工具，例如 Changesets、Beachball、Auto 等。

那么，这里我们要介绍的就是 Changesets。下面，我们来看一下在前面建好的 PNPM 的 Monorepo 项目中如何使用 Changesets。首先，需要执行在 Monorepo 项目的工作区下，执行如下 2 个命令：

pnpm i -DW @changesets/cli
pnpm changeset init

前者是安装 Changesets 的 CLI，后者是初始化 .changeset 文件夹以及对应的文件：

.changeset
  ｜-- config.json
  ｜__ README.md

这里，我们来看一下 config.json 文件：

{
  "$schema": "https://unpkg.com/@changesets/[email protected]/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "linked": [],
  "access": "restricted",
  "baseBranch": "master",
  "updateInternalDependencies": "patch",
  "ignore": []
}

除开 $schema 这个不需要修改的字段， config.json 文件中列了 7 个字段，各个字段分别代表的作用为：

• changelog 设置 CHANGELOG.md 生成方式，可以设置 false 不生成，也可以设置为定义生成行为的文件地址或依赖名称，例如 Changsets 提供的 changelog-git。其中，定义生成行为的文件固定代码模版为：

async function getReleaseLine() {}

async function getDependencyReleaseLine() {}

export default {
  getReleaseLine,
  getDependencyReleaseLine
}

• commit 设置是否把执行 changeset add 或 changeset publish 操作时对修改用 Git 提交

• linked 设置共享版本的包，而不是独立版本的包，例如一个组件库中主题和单独的组件的关系，也就是修改 Version 的时候，共享的包需要同步一起更新版本

• access 设置执行 npm publish 的 --access 选项，通常情况下我们是公共的包，所以设置 public 即可（注意，它会被 package.json 中的 access 字段重写）

• baseBranch 设置默认的 Git 分支，例如现在 GitHub 的默认分支应该是 main

• updateInternalDependencies 设置互相依赖的包版本更新机制，它是一个枚举（major|minor|patch），例如设置为 minor 时，只有当依赖的包新了 minor 版本或者才会对应地更新 package.json 的 dependencies 或 devDependencies 中对应依赖的版本

• ignore 设置不需要发布的包，这些会被 Changesets 忽略

在初始化 .changeset 文件夹后，就可以正常使用 changeset 相关的命令，主要是这 3 个命令：

• pnpm chageset 用于生成本次修改的要添加到 CHANGELOG.md 中的描述
• pnpm changeset version 用于生成本次修改后的包的版本
• pnpm changeset publish 用于发布包

此外，如果是在业务场景下，我们通常需要把包发到公司私有的 NPM Registry，而这有很多种配置方式。但是，需要注意的是 Changesets 只支持在每个包中声明 publicConfig.registry 或者配置 process.env.npm_config_registry，对应的代码会是这样：

// https://github.com/changesets/changesets/blob/main/packages/cli/src/commands/publish/npm-utils.ts
function getCorrectRegistry(packageJson?: PackageJSON): string {
  const registry =
    packageJson?.publishConfig?.registry ?? process.env.npm_config_registry;

  return !registry || registry === "https://registry.yarnpkg.com"
    ? "https://registry.npmjs.org"
    : registry;
}

可以看到，如果在前面说的这 2 种情况下获取不到 registry 的话，Changesets 都是按公共的 Registry 去查找或者发布包的。

Turborepo

说起 Turborepo，可能大家会有点陌生。但是，对于 Vercel 我想大家都知道（毕竟 Rich Harris、Sebastian Markbåge 等都加入了），Turbrepo 则是 Vercel 旗下的一个开源项目。Turborepo 是用于为 JavaScript/TypeScript 的 Monorepo 提供一个极快的构建系统，简单地理解就是用 Turborepo 来执行 Monorepo 项目的中构建（或者其他）任务会非常快！

关于 Turborepo 其他优势，其官方文档写的很详尽，有兴趣的同学可以自行了解~

所以，你可以理解成快是选择 Turborepo 负责 Monorepo 项目多包任务执行的原因。而在 Turborepo 中执行多包任务是通过 turbo run <script>。不过，turbo run 和 lerna run 直接使用有所不同，它需要配置 turbo.json 文件，注册每个需要执行的 script 命令。

在 Turborepo 中有个 Pipelines 的概念，它是由 turbo.json 文件中的 pipline 字段的配置描述，它会在执行 turbo run 命令的时候，根据对应的配置进行有序的执行和缓存输出的文件。

举个例子，通常情况下我们一个 Monorepo 项目中的每个包可能会有 dev、build、test、clean 等 4 个命令，那么对应的 turbo.json 的配置会是这样：

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "clean": {
      "dependsOn": ["^clean"]
    },
    "test": {
      "dependsOn": ["build"， "lint"]
    },
    "dev": {
      "cache": false
    }
  }
}

可以看到，pipeline 中的每个 key 则对应着每个需要执行的 turbo run 命令的名称，其中 dependsOn、outputs、cache 等 3 个字段分别作用为：

• dependsOn 表示当前命令所依赖的命令，^ 表示 dependencies 和 devDependencies 的所有依赖都执行完 build，才执行 build
• outputs 表示命令执行输出的文件缓存目录，例如我们常见的 dist、coverage 等
• cache 表示是否缓存，通常我们执行 dev 命令的时候会结合 watch 模式，所以这种情况下关闭掉缓存比较切合实际需求

这样一来，我们就可以使用诸如 turbo run build test 的命令，它则会按 pipeline 的配置依次执行对应的命令。

当然，如果你想每个命令都支持单独执行，可以直接配置为 {} 即可。此外，如果要使用 turbo run 命令，还需要在 package.json 中声明 packageManage 字段为指定的包管理工具及版本，例如 "packageManager": "[email protected]"。

结语

阅读到此处，我想大家应该理解了 PNPM + Turborepo + Changesets 这个技术选型的原因以及要怎么做。当然，这个选型只是我个人的思考所得出的答案，相信也有同学仍然钟情于 Lerna，又或者喜欢 Rush 一把梭，这些观点并无对错，本质上这也是编程的魅力所在，各个轮子都有其存在的价值。

最后，如果文中存在表达不当或错误的地方，欢迎各位同学评论交流～

HTTP

报文

HTTP 报文可以分为请求报文和响应报文。

请求报文：

• 请求行（方法、URI、HTTP版本）
• 请求首部字段
• 通用首部字段
• 实体首部字段
• 其他构成

响应报文：

• 状态行
• 响应首部字段
• 通用首部字段
• 实体首部字段
• 其他构成

URI 和 URL

URI Uniform Resource Identifier（统一资源标识符），用字符串标识某一互联网资源

URL Uniform Resource Locator（统一资源定位符），用于表示资源的地点（即在互联网上所处的位置）

URL 是 URI 的子集

请求方法（9种）

GET

HTTP GET 方法请求指定的资源。使用 GET 的请求应该只用于获取数据。

POST

HTTP POST 方法 发送数据给服务器. 请求主体的类型由 Content-Type 实体首部字段指定.

DELETE

HTTP DELETE 请求方法用于删除指定的资源。

OPTIONS

HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。

PUT

HTTP PUT 请求方法使用请求中的负载创建或者替换目标资源。

PUT 与 POST 方法的区别在于，PUT方法是幂等的：调用一次与连续调用多次是等价的（即没有副作用），而连续调用多次POST方法可能会有副作用，比如将一个订单重复提交多次。

CONNECT

在 HTTP 协议中，CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道（tunnel）。

例如，CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流。

HEAD

HTTP HEAD 方法 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源.

HEAD 方法的响应不应包含响应正文. 即使包含了正文也必须忽略掉. 虽然描述正文信息的 entity headers, 例如 Content-Length 可能会包含在响应中, 但它们并不是用来描述 HEAD 响应本身的, 而是用来描述同样情况下的 GET 请求应该返回的响应.

PATCH

在HTTP协议中，请求方法 PATCH 用于对资源进行部分修改。

在HTTP协议中， PUT 方法已经被用来表示对资源进行整体覆盖， 而 POST 方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法，而与 POST 方法类似，PATCH 方法是非幂等的，这就意味着连续多个的相同请求会产生不同的效果。

另外一个支持 PATCH 方法的隐含迹象是 Accept-Patch 首部的出现，这个首部明确了服务器端可以接受的补丁文件的格式。

TRACE

HTTP TRACE 方法 实现沿通向目标资源的路径的消息环回（loop-back）测试 ，提供了一种实用的 debug 机制。

状态码

在 HTTP 协议中，状态码的作用是当客户端向服务端发送请求时，描述返回的请求结果。通过状态码，用户可以知道服务器是正常处理了请求，还是发生错误。

而状态码是由两个部分组成：3 位数数字、原因短语，例如 200 OK。
在状态码中，三位数字的第一个数字代表了响应的类别，具体的响应类别有以下 5 种：

1XX 任务信息

100 Continue

HTTP 状态码为 100 Continue 时，则表示目前为止请求正常, 客户端应该继续请求, 如果已完成请求则忽略。

101 Switching Protocol

HTTP 状态码为 101 Switching Protocol 时，则表示服务端根据客户端升级协议的请求（Upgrade 请求头），正在切换协议。

2XX 成功

200 OK

HTTP 状态码为 200 OK 时，则表示客户端发送的请求在服务器被正常处理了。相应地在响应报文中，会根据请求方法的不同返回不同的实体内容。例如 GET 方法请求时，对应的请求资源的实体会作为响应返回。

204 No Content

HTTP 状态码为 204 No Content 时，则表示服务器接收的请求已处理，并且在响应报文的实例中没有主体部分，即可以理解为没有返回的内容或信息。

206 Partial Content

HTTP 状态码为 206 Partial Content 时，则表示客户端对服务器发起了范围请求，并且服务器已接收并处理完成该请求，在响应报文中包含由 Content-Range 指定范围的实体内容。

3XX 重定向

301 Moved Permanently

HTTP 状态码为 301 Permanetly 时，表示请求的资源已被分配至新的 URI，以后应使用这个新的 URI 进行相应的请求。

302 Found

HTTP 状态码为 302 Found 时，同样也是表示请求的资源已被分配至新的 URI，所不同于 301 的是，它只是暂时的，即只需要这一次请求新的 URI，即可（需要注意的是 302 禁止 POST 变换成 GET）。

303 See Other

HTTP 状态码为 303 See Other 时，则表示请求的资源存在另一个 URI，应使用 GET 请求方法获得请求相应资源。

304 Not Modified

HTTP 状态码为 304 Not Modified 时，则表示服务器允许访问资源，但是由于客户端请求时未满足条件，而直接返回 304 NotModified，即在响应报文的主体中不包含任何内容。

307 Temporary Redirect

HTTP 状态码为 307 Temporary Redirect 时，与 302 相同的行为，只是它不会禁止从 POST 转为 GET。

4XX 客户端错误

400 Bad Request

HTTP 状态码为 4xx 时，表明客户端是请求资源发生错误的原因所在。

401 Unauthoried

HTTP 状态码为 400 Bad Request 时，表示请求报文中存在语法错误，即客户端需要修改请求，再次发送请求。

403 Forbidden

HTTP 状态码为 403 Forbidden 时，表示客户端发送的请求被服务器拒绝了。

404 Not Found

HTTP 状态码为 404 Not Found 时，表示服务器上找不到客户端所要请求的资源。

5XX 服务器错误

500 Internal Server Error

HTTP 状态码为 500 Internal Server Error 时，表示在请求过程中服务器发生了错误，例如可能是服务器存在 Bug 或其他临时的原因。

503 Service Unavailable

HTTP 状态码为 503 Unavailable 时，表示服务器暂时处于超负载或停机维护，此时无法处理请求。

常见首部字段（四种）

请求首部字段

响应首部字段

实体首部字段

通用首部字段

缓存

强缓缓存

描述：即服务端一方设定的可缓存内容，这个过程不需要沟通，只要这个缓存有效，那么你就可以去读取它。

缺点：其实这样简单的理解定义，就可以看出它的弊端，当服务端缓存的资源变了，可是浏览器缓存的资源还有效，那么这个资源的更新就没有及时同步，这无疑是不友好的。

强缓存有两种：Expires和 Cache-Control。

Expires

看到这个单词，应该都很容易的联想到 Cookie的 Expires，它在 Cookie 中作用就是设置 Cookie 的有效期。同样地，在这里它是 HTTP/1 中用来描述缓存资源有效时间的 HTTP 实体首部字段，它的值为 GMT 时间，由服务端定义好通过响应报文返回给前端。

缺点：由服务端定义好时间，这就会发生服务端和客户端时间不一致的问题。

Cache-Control

Cache-Control 它是 HTTP/1.1 中提出用于缓存的 HTTP 通用首部字段。它则代表资源在一段时间内可以读取缓存，而不用重新请求。而与 Expires 不同，它的值为 max-age = **s，并且它还可以搭配一些指令（8 个）实现一些特定的效果：

• private，表示 HTTP 请求从浏览器发送到最终的服务器这个过程，只有浏览器缓存，中间任何传递节点不能缓存（代理服务器之类的）
• public，表示都可以缓存，无论浏览器、服务器或者代理服务器。
• no-store，表示不需要缓存。
• no-cache，表示不使用强缓存，使用协商缓存。
• max-age，表示缓存有效的最大时间，单位为 s。
• s-maxage，表示代理服务器的缓存有效的最大时间。
• max-stale，表示浏览器可接受的失效缓存的最大失效时间。
• max-refresh，表示浏览器可接受的最短更新时间，不过这个时间是当前的 age 加上 max-refresh。

当 Expires 和 Cache-Control 同时存在时，Cache-Control 的优先级较高

协商缓存

描述：即这个缓存的过程需要通过双方的确认，才能决定缓存资源是否可用，可用则返回状态码 304 Not Modified，不可用则返回状态码 200 OK和更新后的资源。

缺点：因为缓存的最终确定需要浏览器和服务器双方的确定，所以性能较低、耗时较长。

Last-Modified

Last-Modified 是 HTTP/1.0 中用于协商缓存的 HTTP 响应首部字段，它表示该资源的最后修改时间，它会和 If-Modified-Since 一起使用。

这个过程大致是这样的，服务端在响应报文中添加 Last-Modified 首部字段即相应的值（同样是 GMT 时间），然后浏览器在接受响应后，会将资源进行缓存和记录 Last-Modified，在下次请求相同资源的时候添加 If-Modified-Since HTTP 请求首部字段 携带之前记录的 Last-Modified 的值一起发送到服务端，服务端识别到 If-Modified-Since 字段，并与该资源上次修改的时间进行比较，如果相同则返回状态 304 Not-Modified，如果不同则发送状态码 200 OK 以及在报文实体中携带上更新过的资源。

缺点：

• 在浏览器本地可以修改资源，并且此时该资源对应的 Last-Modified 也会随着变化，那么此时就会造成服务端返回状态码 200 OK 情况和返回没有更新的资源（实际上资源并没有变化），即这个请求完全没有意义。
• Last-Modified 无法观察低于秒时的文件的修改，那么这就会造成文件已经更新了，但是服务端却认为它没有更新状态 304 Not-Modified，让浏览器去读缓存，即资源更新不精确。

ETag

ETag 是 HTTP/1.1 中用于协商缓存的 HTTP 响应首部字段，它是由服务端为该资源生成的 Hash，它会和 If-No-Match 一起使用。

它的过程会是这样，服务端在响应报文中添加 ETag 首部字段及对应资源的 Hash，同样地，然后浏览器在接受响应后，会将资源进行缓存和记录 ETag，在下次请求相同资源时通过 If-No-Match HTTP 请求首部字段 携带之前记录的 ETag 的值一起发送到服务端，服务端识别到 ETag 字段，并与该资源此时的 Hash值进行比较，如果相同返回状态码 304 Not-Modified，如果不同则发送状态码 200 OK 以及在报文实体中携带上更新过的资源。

缺点：

• ETag 需要服务端计算资源生成 Hash，这个过程无疑是比较慢的，所以性能较低。

当 ETag 和 If-Modified 同时存在时，ETag 的优先级较高

Cookie

CORS（跨域资源）

HTTPS

HTTPS = HTTP + 加密 + 完整性保护 + 身份认证

HTTP 1.x

HTTP 2.x

HTTP 3.x

从浏览器输入 URL 到页面展示过程发生了什么？

一、Chrome 多进程架构

首先，在开始讲解整个过程前，我们需要认识一下 Chrome 多进程架构。因为，从浏览器输入 URL 到页面渲染的整个过程都是由 Chrome 架构中的各个进程之间的配合完成。

Chrome 的多进程架构：

• 浏览器进程，它负责用户界面（地址栏、菜单等等）、子进程的管理（例如，进程间通信和数据传递）、存储等等
• 渲染进程，它负责将接收到的 HTML 文档和 JavaScript 等转化为用户界面
• 网络进程，它负责网络资源的请求，例如 HTTP请求、WebSocket 模块
• GPU（图形处理器）进程，它负责对 UI 界面的展示
• 插件进程，它负责对插件的管理

二、过程详解

2.1 解析输入

发生这个过程的前提，用户在地址栏中输入了 URL，而地址栏会根据用户输入，做出如下判断：

• 输入的是非 URL 结构的字符串，则会用浏览器默认的搜索引擎搜索该字符串
• 输入的是 URL 结构字符串，则会构建完整的 URL 结构，浏览器进程会将完整的 URL 通过进程间通信，即 IPC，发送给网络进程

2.2 请求过程

在网络进程接收到 URL 后，并不是马上对指定 URL 进行请求。首先，我们需要进行 DNS 解析域名得到对应的 IP，然后通过 ARP 解析 IP 得到对应的 MAC（Media Access Control Address）地址。

域名是我们取代记忆复杂的 IP 的一种解决方案，而 IP 地址才是目标在网络中所被分配的节点。MAC 地址是对应目标网卡所在的固定地址。

1. DNS 解析

而 DNS 解析域名的过程分为以下几个步骤：

• 询问浏览器 DNS 缓存
• 询问本地操作系统 DNS 缓存（即查找本地 host 文件）
• 询问 ISP（Internet Service Provider）互联网服务提供商（例如电信、移动）的 DNS 服务器
• 询问根服务器，这个过程可以进行递归和迭代两种查找的方式，两者都是先询问顶级域名服务器查找

2. 通信过程

首先，建立 TCP 连接，即三次握手过程：

• 客户端发送标有 SYN 的数据包，表示我将要发送请求。
• 服务端发送标有 SYN/ACK 的数据包，表示我已经收到通知，告知客户端发送请求。
• 客户端发送标有 ACK 的数据包，表示我要开始发送请求，准备被接受。

然后，利用 TCP 通道进行数据传输：

• 服务端接收到数据包，并发送确认数据包已收到的消息到客户端，不断重复这个过程
• 客户端在发送一个数据包后，未接收到服务端的确定消息，则重新发送该数据包，即 TCP 的重发机制
• 当接收完所有的数据包后，接收端会按照 TCP 头中的需要进行排序，形成完整的数据

最后，断开 TCP 连接，即四次握手过程：

• 客户端发送请求，申请断开连接，进入等待阶段，此时不会发送数据，但是会继续接收数据。
• 服务端接收请求后，告知客户端已明白，此时服务端进入等待状态，不会再接收数据，但是会继续发送数据。
• 客户端收到后，进入下一阶段等待。
• 服务端发送完剩余的数据后，告知客户端可以断开连接，此时服务端不会发送和接收数据。
• 客户端收到后，告知服务端我开始断开连接。
• 服务端收到后，开始断开连接。

而这整个过程的客户端则是网络进程。并且，在数据传输的过程还可能会发生的重定向的情况，即当网络进程接收到状态码为 3xx 的响应报文，则会根据响应报文首部字段中的 Location 字段的值进行重新向，即会重新发起请求

3. 数据处理

当网络进程接收到的响应报文状态码，进行相应的操作。例如状态码为 200 OK 时，会解析响应报文中的 Content-Type 首部字段，例如我们这个过程 Content-Type 会出现 application/javascript、text/css、text/html，即对应 Javascript 文件、CSS 文件、HTML 文件。

详细的 MIME 类型讲解可以看 MDN

2.3 创建渲染进程

当前需要渲染 HTML 时，则需要创建渲染进程，用于后期渲染 HTML。而对于渲染进程，如果是同一站点是可以共享一个渲染进程，例如 a.abc.com 和 c.abc.com 可以共享一个渲染渲染进程。否则，需要重新创建渲染进程

需要注意的是，同站指的是顶级域名和二级域名相等

2.4 开始渲染

在创建完渲染进程后，网络进程会将接收到的 HTML、JavaScript 等数据传递给渲染进程。而在渲染进程接收完数据后，此时用户界面上会发生这几件事：

• 更新地址栏的安全状态
• 更新地址栏的 URL
• 前进后退此时 enable，显示正在加载状态
• 更新网页

2.5 渲染过程

大家都知道页面渲染的过程也是面试中单独会考的点，并且时常会由这个点延申出另一个问题，即如何避免回流和重绘。

渲染过程，是整个从理器输入 URL 到页面渲染过程的最后一步。而页面渲染的过程可以分为 9 个步骤：

• 解析 HTML 生成 DOM 树
• 解析 CSS 生成 CSSOM
• 加载或执行 JavaScript
• 生成渲染树（Render Tree）
• 布局
• 分层
• 生成绘制列表
• 光栅化
• 显示

2.5.1 构建 DOM 树

由于网络进程传输给渲染进程的是 HTML 字符串，所以，渲染进程需要将 HTML 字符串转化成 DOM 树。例如：

需要注意的是这个 DOM 树不同于 Chrome-devtool 中 Element 选项卡的 DOM 树，它是存在内存中的，用于提供 JavaScript 对 DOM 的操作。

2.5.2 构建 CSSOM

构建 CSSOM 的过程，即通过解析 CSS 文件、style 标签、行内 style 等，生成 CSSOM。而这个过程会做这几件事：

• 规范 CSS，即将 color: blue 转化成 color: rgb() 形式，可以理解成类似 ES6 转 ES5 的过程
• 计算元素样式，例如 CSS 样式会继承父级的样式，如 font-size、color 之类的。

CSS Object Model 是一组允许用 JavaScript 操纵 CSS 的 API。详细 API 讲解可以看 MDN

2.5.3 加载 JavaScript

通常情况下，在构建 DOM 树或 CSSOM 的同时，如果也要加载 JavaScript，则会造成前者的构建的暂停。当然，我们可以通过 defer 或 sync 来实现异步加载 JavaScript。虽然 defer 和 sync 都可以实现异步加载 JavaScript，但是前者是在加载后，等待 CSSOM 和 DOM 树构建完后才执行 JavaScript，而后者是在异步加载完马上执行，即使用 sync 的方式仍然会造成阻塞。

而 JavaScript 执行的过程，即编译和运行 JavaScript 的过程。由于 JavaScript 是解释型的语言。所以这个过程会是这样的：

• 针对每句代码进行分行处理，即 Token 化
• 根据 Token，生成 AST（Abstract Sytanx Tree) 抽象语法树和创建上下文
• 解释器解析和执行 AST，生成字节码。
• 编译器针对需要反复执行的代码，生成对应的机器码，提高运行效率

2.5.4 生成渲染树（Render Tree）

在有了 DOM 树和 CSSOM 之后，需要将两者结合生成渲染树 Render Tree，并且这个过程会去除掉那些 display: node 的节点。此时，渲染树就具备元素和元素的样式信息。

2.5.5 布局

根据 Render Tree 渲染树，对树中每个节点进行计算，确定每个节点在页面中的宽度、高度和位置。

需要注意的是，第一次确定节点的大小和位置的过程称为布局，而第二次才被称为回流

2.5.6 分层

由于层叠上下文的存在，渲染引擎会为具备层叠上下文的元素创建对应的图层，而诸多图层的叠加就形成了我们看到的一些页面效果。例如，一些 3D 的效果、动画就是基于图层而形成的。

值得一提的是，对于内容溢出存在滚轮的情况也会进行分层

2.5.7 生成绘制列表

对于存在图层的页面部分，需要进行有序的绘制，而对于这个过程，渲染引擎会将一个个图层的绘制拆分成绘制指令，并按照图层绘制顺序形成一个绘制列表。

2.5.8 光栅化

有了绘制列表后，渲染引擎中的合成线程会根据当前视口的大小将图层进行分块处理，然后合成线程会对视口附近的图块生成位图，即光栅化。而渲染进程也维护了一个栅格化的线程池，专门用于将图块转为位图。

栅格化的过程通常会使用 GPU 加速，例如使用 wil-change、opacity，就会通过 GPU 加速显示

2.5.9 显示

当所有的图块都经过栅格化处理后，渲染引擎中的合成线程会生成绘制图块的指令，提交给浏览器进程。然后浏览器进程将页面绘制到内存中。最后将内存绘制结果显示在用户界面上。

而这个整个从生成绘制列表、光栅化、显示的过程，就是我们常说的重绘的过程

前言

不可否认，如今 TypeScript 已成为一个前端工程师的所需要具备的基本技能。严谨的类型检测，一方面是提高了程序的可维护性和健壮性，另一方面也在潜移默化地提高我们的编程思维，即逻辑性。

那么，今天我将会通过结合实际开发场景和 Vue 3.0 源码中的部分类型定义来简单聊聊 TypeScript 中的高级类型。

interface

interface 被用于对所有具有结构的数据进行类型检测。例如，
在实际开发当中，我们会定义一些对象或数组来描述一些视图结构。

定义对象

常见的有对表格的列的定义：

const columns = [
  {key: "username", title: "用户名"},
  {key: "age", title: "年龄"},
  {key: "gender", title: "性别"}
]

而这个时候，我们就可以通过定义一个名为 column 的接口：

interface column {
  key: string,
  title: string
}

// 使用
const columns: column[] = [
  {key: "username", title: "用户名"},
  {key: "age", title: "年龄"},
  {key: "gender", title: "性别"}
]

定义函数

我们平常开发中使用的 axios，它的调用方式会有很多种，例如 axios.request()、axios.get()、axios.put()。它本质上是定义了这么一个接口来约束 axios 具备这些方法，它看起来会是这样：

export interface Axios {
  request(config: AxiosRequestConfig): AxiosPromise
  get(url: string, config?: AxiosRequestConfig): AxiosPromise
  delete(url: string, config?: AxiosRequestConfig): AxiosPromise
  head(url: string, config?: AxiosRequestConfig): AxiosPromise
  options(url: string, config?: AxiosRequestConfig): AxiosPromise
  post(url: string, data?: any, config?: AxiosRequestConfig): AxiosPromise
  put(url: string, data?: any, config?: AxiosRequestConfig): AxiosPromise
  patch(url: string, data?: any, config?: AxiosRequestConfig): AxiosPromise
}

继承

可复用性是我们平常在写程序时需要经常思考的地方，例如组件的封装、工具函数的提取、函数设计模式的使用等等。而对于接口也同样如此，它可以通过继承来复用一些已经定义好的 interface 或 class。

这里我们以 Vue 3.0 为例，它在 compiler 阶段，将 AST Element 节点 Node 分为了多种 Node，例如 ForNode、IFNode、IfBranchNode 等等。而这些特殊的 Node 都是继承了 Node：

Node 的 inteface 接口定义：

export interface Node {
  type: NodeTypes
  loc: SourceLocation
}

IFNode 的 interface 接口定义：

export interface IfNode extends Node {
  type: NodeTypes.IF
  branches: IfBranchNode[]
  codegenNode?: IfConditionalExpression
}

可以看到 Node 的接口定义是非常纯净的，它描述了 Node 所需要具备最基本的属性：type 节点类型、loc 节点在 template 中的起始位置信息。而 IFNode 则是在 Node 的基础上扩展了 branches 和 codegenNode 属性，以及重写了 Node 的 type 属性为 NodeTypes.IF。

这里简单介绍一下 IFNode 的两个属性：

• branches 表示它对应的 else 或 else if 的节点，它可能是一个或多个，所以它是一个数组。
• codegenNode 则是 Vue 3.0 的 AST Element 的一大特点，它描述了该节点的一些属性，例如 isBlock、patchFlag、dynamicProps 等等，这些会和 runtime 的时候靶向更新和靶向更新密切相关。

近段时间，我也在写一篇关于 Vue 3.0 如何实现 runtime + compile 优雅地实现靶向更新和静态提升的文章，应该会在下周末竣工。

小结

对于 interface 的介绍和使用，我们这里点到即止。当然，它还有很多高级的使用例如结合泛型、定义函数类型等等。有兴趣的同学可以自行去了解这方面的实战。

交叉类型和联合类型

交叉类型

交叉类型故名思意，有着交叉之效。我们可以通过交叉类型来实现多个类型的合并。例如，在 Vue3 中，compile 阶段除了会进行 baseParse 之外，还会进行 transform，这样最后的 AST 才会进行 generate 生成可执行的代码。所以，compile 阶段它就会对应多个 options，即它也是一个交叉类型：

export type CompilerOptions = ParserOptions & TransformOptions & CodegenOptions

而这个 CompilerOptions 类型别名会用于 baseCompiler 阶段：

export function baseCompile(
  template: string | RootNode,
  options: CompilerOptions = {}
): CodegenResult {}

而为什么是多个 options 的交叉，是因为 baseCompiler 只是最基础的 compiler，上面还有更高级的 compiler-dom、compiler-ssr 等等。

联合类型

同样地，联合类型其有着合的效果。即有时候，你希望一个变量的类型是 String
或者是 number 的时候，你就可以使用联合类型来约束这个变量。例如：

let numberOrString: number | string
numberOrString = 1
numberOrString = '1'

并且，在实际的开发中使用联合类型，我们通常会遇到这样的提示，例如：

interface student {
  name: string
  age: number
}
interface teacher {
  name: string
  age: number
  class: string
}
let person: student | tearcher = {} as any

person.class = "信息161"
// property 'person' does not exit on type `student`

这个时候，我们可以利用类型断言，告诉 TypeScript 我们知道 person 是什么：

(person as teacher).class = "信息161"

小结

对于交叉类型和联合类型，应该是属于我们平常开发中会使用频繁的部分。并且，从它们的概念上，不难理解，它们本质上就是数学中的并集和交集，只不过在基本类型上有着不同的表现而已。

类型保护与区分类型

类型保护

在讲联合类型的时候，我们说了它本质上是交集，这也导致了我们不能直接使用交集之外的属性或方法。所以，我们得通过在不同情况下使用类型断言来告知 TypeScript 它是什么，从而使用交集之外的属性。

但是，频繁地使用类型断言无疑降低了代码的可读性。而针对这一问题，TypeScript 提供了类型保护的机制来减少类型断言，它是一个主谓宾句，例如仍然是上面的例子，我们可以实现这样的类型保护：

function isTeacher(person: Tearcher | Student): person is Teacher {
   return (<Tearcher>person).class !== undefined
}

然后通过 isTeacher 这个函数来判断当前类型，再进行相应地属性访问：

if (isTeacher(person)) {
  // 这里访问 teacher 独有的属性
  person.class = "信息162"
} else {
  person.name = "wjc"
}

typeof 与 instanceof

有了类型保护，这个时候我们就会遇到这样的问题：如果我的联合类型中存在多个类型，那么岂不是得定义多个类似 isTeacher 这样的借助类型保护的函数？幸运的是，在 TypeScript 使用 typeof 或 instanceof 可以自动实现类型保护和区分。

typeof

在 TypeScript 中对基础类型使用 typeof 时，会自动进行类型保护，例如：

function isNumberOrString(param: string | number) {
    if (typeof param === 'string') {
        return param.split('')
    } else {
        return param++
    }
}

instanceof

不同于 typeof 只能对基础类型进行类型保护，instanceof 可以实现对所有类型的类型保护。它是通过构造函数来实现类型保护。

interface Person {
    name: string
    age: string
  }
  class Teacher implements Person {
    name: string
    age: string
    constructor(name: string, age: string) {
        this.name = name
        this.age = age
    }
    teach() {
      console.log("i am a teacher.")
    }
  }
  class Student implements Person {
    name: string
    age: string
    constructor(name: string, age: string) {
        this.name = name
        this.age = age
    }
    study() {
      console.log("i am a student.")
    }
  }
  const person: Student | Teacher = null as any

 if (person instanceof Teacher) {
     person.teach()
 } else {
     person.study()
 }

小结

对于 typeof 或 instanceof 其实在 JavaScript 中也是老生常谈的知识点，因为传统的类型检测我们会更偏向使用 Object.String.prototype.toString() 来实现。但是，反而在 TypeScript 中，它们两者反而混的如鱼得水。

类型别名

类型别名，我想大家脑海中第一时间想到的就是 Webpack 中的 alias 为路径配置别名。但是，TypeScript 中的类型别名与它只是形同，但是意不同。通俗点讲，就是通过它可以给类型起一个名称：

type age = number
const getAge = () => age

// 等同于
interface Age {
  getAge():number
}

字面量类型

字面量类型是指我们可以通过使用类型别名和联合类型来实现枚举类型，例如：

type method = get | GET | post | POST | PUT | put | DELETE | delete

索引类型与映射类型

对于索引类型和映射类型，这里我们通过 loadash 中常用的一个函数 pluck 来讲解：

在 JavaScript 中实现：

function pluck(object, names) {
  return names.map(name => object[name])
}

在 TypeScript 中实现：

function puck<T, K extends keyof T>(object: T, names: K[]): T[K][] {
  return names.map(name => object[name])
}

这里我们为 puck 函数定义了两个泛型变量 T 和 K，其中 K 是继承于 T 中所有属性名的类型，所以形参中 names 被约束为 T 中属性的数组，这个过程被称为类型索引。而对于 puck 函数的返回值 T[K][] ，则代表返回的值是一个数组，并且数组值被约束为 T 中属性值为 K 的值，这个过程被称为索引访问。

理解这两种概念可能会有点晦涩，但是对于每一者都分开去理解过程会比较有逻辑性。

结语

虽然，TypeScript 已成为一项前端工程师的必备技能。但是，相信很多小伙伴还是用的 Javascript 比较多。所以，可能会存在困扰，我该如何提高 TypeScript 编程能力？其实，这个问题很简单，开源的时代，今天我们很多问题都可以通过阅读一些开源的项目源码来解决。这里，我推荐大家可以尝试着去阅读 Vue3.0 的源码，相信通过阅读，你的 TypeScript 编程能力会有质的飞跃。

写作不易，如果你觉得有收获的话，可以帅气三连击！！！

参考

• 《TypeScirpt 实战指南》
• TypeScript 官方文档
• vuejs/vue-next

引言

对于变量提升这个问题，我想从事前端的同学都或多或少认为我懂这个。曾经，我也是这样认为的，我懂变量提升，并且可以从变量在 Chrome 中的内存分配讲起，以及中间发生了什么。

但是，在一次面试中，我遇到了几个一起面前端的同学（当然技术水平参差不齐，并不是很高），在和他们聊这次笔试中的变量提升的问题时，发现大家都支支吾吾的，很多讲的都是值的覆盖。

当时的面试题是这样的：

function fn(a) {
    console.log(a)
    var a = 2
    function a() {}
    console.log(a)
}
fn(1)

这个题目，最终会输出function a(){} 和 2。那么，为什么是这个答案，这个过程发生了什么很重要。所以，今天我们就来彻底刨析一下变量提升的过程。

一、变量在内存中的分配

在分析整个过程前，我们先来回顾一下 JavaScript 中变量在内存中的分配。

大家都知道的是，对于原始类型会存储在栈空间中，对于引用类型会将引用存储在栈空间中，将数据存储在堆空间中。

其实这个过程还牵扯到函数上下文的创建，而每一个函数上下文中又会创建一个变量环境、词法环境。有兴趣的同学可以去看李斌老师的浏览器工作原理与实践

所以，我们来看一个简单的栗子，分析一下它在内存中的分配：
栗子：

var a = 1
var b = 2
var student = {name: 'wjc', age: 22}

它内存中的分配：

二、运行前的简单编译

众所周知，JavaScript 是一门动态类型的语言，即它是在运行时确定变量的类型，不同于静态类型语言的先编译再运行的过程。但是，事实是 V8 引擎在解析运行 JavaScript 之前是会进行一次简单的编译，也就是我们通常所说的初始化过程。

这个初始化过程，会做这几件事：

• 区分执行代码和变量声明代码
• 变量声明代码划分为赋值代码和初始化代码
• 初始化代码有两种情况，一是对变量（原生类型、对象类型）初始化为 undefined；二是对函数的初始化，即直接指向函数在堆空间中的内存

那么，我们就来看一个简单的栗子：

console.log(a)
sayHi()
var a = 2
function sayHi() {
    console.log('Hi')
}

那么按照我们上面所说，这段代码的赋值只有 var a = 2，函数声明只有进行编译阶段的代码会是这样的：

// 编译代码
var a = undefined
var sayHi = function () {
    console.log('Hi')
}

此时，它在内存中的分布：

然后，在执行阶段的代码会是这样：

// 执行代码
console.log(a)
sayHi()
a = 2

所以，也就是当我们真正执行的时候会走执行代码，所以很显然会输出：

undefined
Hi

而当走完所有执行代码后，此时内存是这样的：

我想通过这个栗子，大家应该大致搞懂变量提升的过程。但是，仍然存在一个较为特殊的情况，就是当函数形参存在时的变量提升，也就是我们文章开头提及的面试题。

三、函数形参的编译执行

首先，我们需要对函数调用做一个简单的理解，在我们平常调用函数的时候，真正会经历两个步骤：

• 如果此时存在形参，则进行函数形参的编译和执行过程
• 然后进入函数体，进行函数体内部的编译和执行

可以看到这里我们提到了当函数存在形参时，会先进行函数形参的编译和执行过程。

这里我们就来分析文章开头这个栗子：

function fn(a) {
    console.log(a)
    var a = 2
    function a() {}
    console.log(a)
}
fn(1)

首先，此时是存在函数形参的，那么函数形参的编译和执行会是这样：

var a = undefined
a = 1

然后，才会进行函数体的编译和执行：

// 编译
a = function a() {} // 重点！！！
// 执行
console.log(a)
a = 2
console.log(a)

可以看到的是，如果函数体内的变量名和形参的变量名重复时，则不会进行普通变量的编译赋值 undefined 的过程。但是，如果存在该变量是函数时，那么则会进行函数变量的编译赋值，即直接指向函数在堆空间中的地址。

所以，我们这个栗子在编译后，可以看作是这样的：

function fn() {
    var a = undefined
    a = 1
    a = function a() {}
    console.log(a)
    a = 2
    console.log(2)
}

很显然，它会输出会输出function a(){} 和 2

结语

不知大家在深度理解过变量提升过程后，是否有和我一样的感受就是学习编程的本质是追溯本源。现今，虽然我们可以用 ES6 的 let 或 const 来声明变量来避免 var 的种种缺陷。但是，如果因为这样而不去思考 var 为什么会存在这些缺陷。我想这是非常遗憾的。

前言

对于 macOS App 开发者来说，我们通常情况下可能会选择在网络上分发 App。但是，站在使用者的角度，如果下载的 App 没有经过 Apple Notary Service 公证（Notarizate）过，这在安装的时候系统则会提示“无法打开 xxx App，因为无法验证开发者”：

那么，这个时候的解决方法就是修改系统偏好——>安全性与隐私的设置，选择仍要打开该 App：

虽然，这样可以让使用者安装 App，但是，这并不是真正在解决这个问题的本质。从根上解决应该是让我们要分发到网络上的 App 通过 Apple Notary Service 公证（Notarizate），这样一来他人下载安装我们应用的时候则不会出现无法打开的提示，而是：

所以，今天本文也将围绕「macOS App 公证」展开如何通过手动或者自动化（Shell、工具）实现公证（Notarizate）过程。

1. 手动公证

首先，我们先了解下如何手动公证？手动公证过程可以通过 Xcode 提供的 GUI 界面操作完成。同样地，首先我们需要构建 .xarchive 文件：

构建完后，Xcode 会弹出窗口让你选择 Distribute App 或 Validate App，这里我们选择前者：

接着，不同于之前分发 App Store，我们需要选择 Developer ID，它表示的是在 App Store 之外分发 App：

然后，我们需要选择 Upload ——> Development Team -> Manually manage signing，此时需要选择 Develop ID 对应的 Distribution 证书和 Provisioning Profile：

最后，则选择 Next ——> Upload，然后则会将我们的 App 上传到 Apple Notary Service 进行公证，通过则会提示我们可以分发 App。

如果，了解过 App Store 分发相关的同学应该熟悉这个手动操作的过程，因为使用 Xcode 公证 App 的过程和 App Store 分发大同小异。所以，在通过简单了解使用 Xcode 手动实现公证过程后，接下来，我们来认识下如何自动化实现公证的过程？

2. 自动化公证

自动化公证则指的是我们通过代码实现前面介绍到的使用 GUI 手动公证的过程。那么，这里我列出了 4 种现在社区中实现的可以对 macOS App 自动化公证的方式：

• altool --notarize-app 使用的旧的 Apple Notary Service，适用于 Xcode 12 以及更早的版本，但是需要注意的是Apple 将会在 2023 年秋季停止对它的支持
• notarytool 使用的新的 Apple Notary Service，只适用于 Xcode 13 及以上的版本，相比较 altool --notarize-app 快了 10 倍
• electron-notarize 用 JavaScript 实现的用于公证的工具，支持 notarytool 和 altool --notarize-app 等 2 种公证方式
• fastlane 用 Ruby 实现的一个可以便捷地帮你完成证书管理、代码签名和发布等相关的工具，适用于 iOS、macOS 和 Android 应用

当然，更进一步的话我们可以把这个自动化公证也加入到 CI/CD 过程中，有兴趣的同学可以自行了解相关实现。所以，接着下面将会对这 4 个的使用做对应的展开介绍，首先是 altool --notarize-app。

2.1 altool --notarize-app

altool 是一个内置于 Xcode 中的命令行工具，用于验证 App 的二进制文件并将其上传至 App Store 或者对 App 进行公证（Notarize）。而 altool --notarize-app 也是最早大家使用的实现自动化公证应用的方式，这在社区中也可以看到大量基于它的实践。

altool --notarize-app 则主要是将应用上传到 Apple Notary Service，但是并不会告知你公证成功与否，所以通常需要结合 altool --notarization-info 命令一起使用（核对公证成功与否），整个公证的过程会是这样：

可以看到，首先我们需要使用 altool --notarize-app 将应用上传公证，然后获取本次公证的 UUID：

xcrun altool --notarize-app \
# .app 的压缩包或 .dmg
--file ./Output/Apps/FEKit.zip \
--primary-bundle-id "com.xxxx.xxxx" \
# Apple ID
--username "xxxxx" \
# 应用专用密码，这可以在 https://appleid.apple.com/account/manage 申请
--password "xxxxx" \

然后，终端中则会输出本次公证上传操作的信息和 RequestUUID，前者用于表示本次操作执行是否成功，后者可以用于 altool --notarization-info 命令查询本次公证过程的信息：

No errors uploading 'Output/Apps/FEKit.zip'.
RequestUUID = xxxxxxx-xxx-xxxx-xxxx-xxxxx

进行完公证上传操作后，Apple Notary Service 则会对本次公证执行相关的操作，而这需要一定的时间，所以我们需要（定时）轮询执行 altool --notarization-info 命令实时地获取公证成功失败与否的信息：

# 加载 Apple ID（$user）和 App 专用密码（$pwd）
source "./Build/app_store_user_pwd.sh"

# 标识公证执行过程成功失败与否，失败 1，0 成功
success=1
i=0
while true; do
    let i+=1
    echo "Checking notarize progress...$i"
    # 获取 altool --notarization-info 执行的输出信息
    process=$(xrun altool --notarization-info $uuid --username $user --password $pwd 2>&1)
    echo "${progress}"
    # 如果上次命令执行结果 $? 不等于 0（表示失败），或者命令输出信息中包含 Invalid
    if [ $? -ne 0 ] || [[ "${progress}" =~ "Invalid"]] then
        echo "Error with notarization. Exiting"
        break
    if
    # 如果命令输出信息中包含 success 表示成功
    if [[ "${progress}" =~ "success"]]; then
        success=0
        break
    else
        echo "Not completed yet. Sleeping for 30 seconds.\n"
    fi
    sleep 30
done

if [ $success -eq 0 ]; then
    echo "Notarize successed."
if

其中，$uuid 则是执行 altool --notarize-app 命令后获取的返回结果：

echo xcrun altool --notarize-app \
--file xxxx \
--primary-bundle-id "com.xxxx.xxxx" \
--username $user \
--password $pwd \
2>&1 | grep RequestUUID |  awk '{print $3}'

这里我们来看下大家比较陌生的 2>&1、grep RequestUUID、awk '{print $3}' 等 3 个命令的作用：

• 2>&1 是为了将标准错误 stderr 输出重定向到标准输出 stdout
• grep RequestUUID 匹配标准输出中所有包含 RequestUUID 的行
• awk '{print $3}' 打印出第 3 列的结果，在 RequestUUID = xxxxxxx-xxx-xxxx-xxxx-xxxxx 就是 RequestUUID 的值 xxxxxxx-xxx-xxxx-xxxx-xxxxx
• | 管道，用于将上个命令的输出通过管道输入到下一个命令

2.2 notarytool

相比较 altool --notarization-info 而言，notarytool 使用起来心智负担少一些，并且快于前者很多，我们只需要记忆一些 Option，使用一行命令 xcrun notarytool 则可以实现上传公证和过程信息获取的过程：

xcrun notarytool submit ./Output/Apps/FEKit.zip \
# Apple ID
--apple-id $user \
--team-id $teamId \
# 应用专用密码
--password $pwd \
-v \
-f "json"

其中，--team-id 指的是用户 ID（由数字和字母组成），这可以在本地 KeyChain 的证书中查看（或者 Apple 证书后台），-v 是 --verbose 的缩写，指的是输出公证过程的信息，-f "json" 则是表示最终结果以 JSON 的格式输出，例如：

{
  "path":"\/Users\/wujingchang\/Documents\/project\/demo\/FEKit\/Output\/Apps\/FEKit.zip",
  "message":"Successfully uploaded file",
  "id":"xxxxxxxxxxxxxxxxxxxx"
}

需要注意的是这里使用的是 Appple ID 和应用专用密码的方式做与公证服务的请求认证 Authentication，此外你还可以通过以下 3 种 Option 来进行认证：

• --keychain-profile <keychain-profile>，使用 xcrun notarytool store-credentials 预先在本地钥匙串中新建一个应用程序密码，例如叫 AC_PASSWORD，那么在使用 notarytool submit 命令的时候则可以直接使用 --keychain-profile AC_PASSWORD 代替之前的 --apple-id $user --team-id $teamId --password $pwd
• --keychain <keychain>，不同于前者 --keychain-profile 这里是输入的 AC_PASSWORD 文件所在的位置
• --key <key-id> --key-id <key-id> --issuer <issuer>，这使用的是 App Store Connect API keys 的方式进行认证，本质上是生成一个和 App Store Connect 约定好的 JWT，然后每次请求的时候携带上它，从而通过认证

2.3 electron-notarize

electron-notarize 则是一个用 JavaScript 实现的公证工具，它的原理则是使用的 child_process 执行前面我们提及的 altool --notarization-info 和 notarytool 这 2 个命令。

electron-notarize 具名导出了 notarize 函数，我们只需要使用它以及指定的 Option 则可以完成公证的过程，这里我们来看下其函数的实现（伪代码）：

// src/index.ts
export async function notarize({ appPath, ...otherOptions }: NotarizeOptions) {
  if (otherOptions.tool === 'notarytool') {
    // ...
    await notarizeAndWaitForNotaryTool({
      appPath,
      ...otherOptions,
    });
  } else {
    // ....
    const { uuid } = await startLegacyNotarize({
      appPath,
      ...otherOptions,
    });
    // ...
    await delay(10000);
    // 获取公证过程信息
    await waitForLegacyNotarize({ uuid, ...otherOptions });
  }

  await stapleApp({ appPath });
}

可以看到，notarize 函数会根据 Option 中传入的 tool 为 notarytool 或 legacy 来执行不同的命令来完成公证，这里前者是 notarytool 后者则是 altool --notarization-info。所以，如果我们要用 notarytool 的方式进行公证会是这样：

import { notarize } from "electron-notarize"

await notarize({
  appPath: "./Output/Apps/FEKit.zip",
  // Apple ID
  appleId: "xxxxxx",
  // 应用专用密码
  appleIdPassword: "xxxxxxxx",
  teamId: "xxxxxxxxxxx",
  tool: "notarytool"
})

其中，如果你不希望密码直接明文暴露在代码中的话，electron-notarize 也支持了前面我们说的 --keychain、--keychain-profile 等 3 个 Option，你可以根据自己的需要选择对应的认证方式。

2.4 fastlane

fastlane 是一个可以便捷地帮你完成证书管理、代码签名和发布等相关的工具，适用于 iOS、macOS 和 Android 应用。那么，我们也就可以使用 fastlane 来完成 macOS App 的公证。

首先，肯定是安装 fastlane，关于这方面的介绍官方文档讲解的很是详尽，这里就不重复论述。而当你安装好 fastlane，则可以在应用项目的根目录执行 fastlane init 来初始化它相关的配置，在初始化的过程会让你选择使用 fastlane 的方式，这里我们选择手动配置即可。

然后，它会在项目根目录下创建一个 fastlane/Fastfile 目录和文件，后续我们在执行 fastlane xxx 命令的时候则会根据该文件的代码实现执行具体的操作，默认生成的 Fastfile 文件的配置会是这样：

default_platform(:ios)

platform :ios do
  desc "Description of what the lane does"
  lane :custome_lane do
    # add actions here: https://docs.fastlane.tools/actions
  end
end

其中，default_platform 用于定义一个默认的平台 Platform，例如当我们有 2 个平台（iOS 和 macOS）的时候，它的的配置需要这样：

default_platform(:ios)

platform :ios do
  desc "Description of what the lane does"
  lane :custome_lane do
    # add actions here: https://docs.fastlane.tools/actions
  end
end
platform :mac do
  desc "Description of what the lane does"
  lane :custome_lane do
    # add actions here: https://docs.fastlane.tools/actions
  end
end

此时，如果我们执行 fastlane custome_lane，由于这里平台默认为 ios，所以则会执行 platorm:ios 下的 custome_lane，反之执行 fastlane mac custome_lane，则是 platform :mac 下的 custome_lane。那么，对于前面我们这个例子而言只需要 platform:mac：

default_platform(:ios)

platform :mac do
  desc "Description of what the lane does"
  lane :custome_lane do
    # add actions here: https://docs.fastlane.tools/actions
  end
end

接着，则可以在 platform:mac 写我们需要实现的自动化分发 App Store 相关的代码。fastlane 便捷之处在于它实现了很多开箱即用的 Action，这里我们需要使用 notarize 这个 Action，它可以用于完成 macOS App 的公证：

default_platform(:mac)

platform :mac do
  desc "Notarizes a macOS app"
  lane :notarize_app do
    notarize(
      package: "./Output/Apps/FEKit.zip",
      use_notarytool: "xcrun notarytool",
      bundle_id: "com.xxxx.xxxx",
      username: "xxxxxxxxxxxxxx",
      verbose: true,
    )
  end
end

其中，在使用 notarize 的时候需要注意的是，这里只是声明了你 App Store 的用户名 username，而专用密码需要预先在系统环境变量中添加 FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD（其他认证方式，有兴趣的同学可以自行了解），然后 fastlane 在执行 notarize_app Action 时会去读取该环境变量，从而进行并完成后续的公证过程。

结语

看到这里，我想可能会有同学会问：“这几种实现公证的工具，选择哪个比较好？”，这里比较建议的是选择 fastlane，因为，除开前面提及它的使用方式非常便捷的优点，它具备的能力也很多，不仅仅可以做 App 公证，还可以做 App Store 分发、证书和版本管理等，所以，选择 fastlane 将来也可以支持我们别的诉求，何乐不为呢？

最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue ～

前言

在 Vue2 中，有一个老生常谈的话题，如何避免 data 中一个复杂对象（自身或属性对象）被默认被创建为响应式（Non-reactive Object）的过程？ 举个例子，有一个 Vue2 的组件的 data：

<script>
export default {
  data() {
    return {
      list: [
        {
          title: 'item1'
          msg: 'I am item1',
          extData: {
            type: 1
          }
        },
        ...
      ]
    }
  }
}
</script>

这里我们希望 list.extData 不被创建为响应式的对象，相信很多同学都知道，我们可以通过 Object.defineProperty 设置对象 list.extData 的 configurable 属性为 false 来实现。

而在 Vue2 中，我们可以这么做，但是回到 Vue3，同样的问题又要怎么解决呢？ 我想这应该是很多同学此时心中持有的疑问。所以，下面让我们一起来由浅至深地去解开这个问题。

1 认识 Reactivity Object 基础

首先，我们先来看一下 Reactivity Object 响应式对象，它是基于使用 Proxy 创建一个原始对象的代理对象和使用 Reflect 来代理 JavaScript 操作方法，从而完成依赖的收集和派发更新的过程。

然后，我们可以根据需要通过使用 Vue3 提供的 ref、compute、reactive、readonly 等 API 来创建对应的响应式对象。

这里，我们来简单看个例子：

import { reactive } from '@vue/reactivity'
const list = reactive([
  {
    title: 'item1'
    msg: 'I am item1',
    extData: {
      type: 1
    }
  }
])

可以看到，我们用 reactive 创建了一个响应式数据 list。并且，在默认情况下 list 中的每一项中的属性值为对象的都会被处理成响应式的，在这个例子就是 extData，我们可以使用 Vue3 提供的 isReactive 函数来验证一下：

console.log(`extData is reactive: ${isReactive(list[0].extData)}`)
// 输出 true

控制台输出：

可以看到 extData 对应的对象确实是被处理成了响应式的。假设，list 是一个很长的数组，并且也不需要 list 中每一项的 extData 属性的对象成为响应式的。那么这个默然创建响应式的对象过程，则会产生我们不期望有的性能上的开销（Overhead）。

既然，是我们不希望的行为，我们就要想办法解决。所以，下面就让我们从源码层面来得出如何解决这个问题。

2 源码中对 Non-reactivity Object 的处理

首先，我们可以建立一个简单的认知，那就是对于 Non-reactivity Object 的处理肯定是是发生在创建响应式对象之前，我想这一点也很好理解。在源码中，创建响应式对象的过程则都是由 packages/reactivity/src/reactive.ts 文件中一个名为 createReactiveObject 的函数实现的。

2.1 createReactiveObject

这里，我们先来看一下 createReactiveObject 函数的签名：

// core/packages/reactivity/reactive.ts
function createReactiveObject(
  target: Target,
  isReadonly: boolean,
  baseHandlers: ProxyHandler<any>,
  collectionHandlers: ProxyHandler<any>,
  proxyMap: WeakMap<Target, any>
) {}

可以看到 createReactiveObject 函数总共会接收 5 个参数，我们分别来认识这 5 个函数形参的意义：

• target 表示需要创建成响应式对象的原始对象
• isReadonly 表示创建后的响应式对象是要设置为只读
• baseHandlers 表示创建 Proxy 所需要的基础 handler，主要有 get、set、deleteProperty、has 和 ownKeys 等
• collectionHandlers 表示集合类型（Map、Set 等）所需要的 handler，它们会重写 add、delete、forEach 等原型方法，避免原型方法的调用中访问的是原始对象，导致失去响应的问题发生
• proxyMap 表示已创建的响应式对象和原始对象的 WeekMap 映射，用于避免重复创建基于某个原始对象的响应式对象

然后，在 createReactiveObject 函数中则会做一系列前置的判断处理，例如判断 target 是否是对象、target 是否已经创建过响应式对象（下面统称为 Proxy 实例）等，接着最后才会创建 Proxy 实例。

那么，显然 Non-reactivity Object 的处理也是发生 createReactiveObject 函数的前置判断处理这个阶段的，其对应的实现会是这样（伪代码）：

// core/packages/reactivity/src/reactive.ts
function createReactiveObject(...) {
  // ...
  const targetType = getTargetType(target)
  if (targetType === TargetType.INVALID) {
    return target
  }
  // ...
}

可以看到，只要使用 getTargetType 函数获取传入的 target 类型 targetType 等于 TargetType.INVALID 的时候，则会直接返回原对象 target，也就是不会做后续的响应式对象创建的过程。

那么，这个时候我想大家都会有 2 个疑问：

• getTargetType 函数做了什么？
• TargetType.INVALID 表示什么，这个枚举的意义？

下面，让我们分别来一一解开这 2 个疑问。

2.2 getTargetType 和 targetType

同样地，让我们先来看一下 getTargetType 函数的实现：

// core/packages/reactivity/src/reactive.ts
function getTargetType(value: Target) {
  return value[ReactiveFlags.SKIP] || !Object.isExtensible(value)
    ? TargetType.INVALID
    : targetTypeMap(toRawType(value))
}

其中 getTargetType 主要做了这 3 件事：

• 判断 target 上存在 ReactiveFlags.SKIP 属性，它是一个字符串枚举，值为 __v_ship，存在则返回 TargetType.INVALID
• 判断 target 是否可扩展 Object.isExtensible 返回 true 或 false，为 true 则返回 TargetType.INVALID
• 在不满足上面 2 者的情况时，返回 targetTypeMap(toRawType(value))

从 1、2 点可以得出，只要你在传入的 target 上设置了 __v_ship 属性、或者使用 Object.preventExtensions、Object.freeze、Object.seal 等方式设置了 target 不可扩展，那么则不会创建 target 对应的响应式对象，即直接返回 TargetType.INVALID（TargetType 是一个数字枚举，后面会介绍到）。

在我们上面的这个例子就是设置 extData：

{
  type: 1,
  __v_ship: true
}

或者：

Object.freeze({
  type: 1
})

那么，在第 1、2 点都不满足的情况下，则会返回 targetTypeMap(toRawType(value))，其中 toRawType 函数则是基于 Object.prototype.toString.call 的封装，它最终会返回具体的数据类型，例如对象则会返回 Object：

// core/packages/shared/src/index.ts
const toRawType = (value: unknown): string => {
  // 等于 Object.prototype.toString.call(value).slice(8, -1)
  return toTypeString(value).slice(8, -1)
}

然后，接着是 targetTypeMap 函数：

// core/packages/reactivity/src/reactive.ts
function targetTypeMap(rawType: string) {
  switch (rawType) {
    case 'Object':
    case 'Array':
      return TargetType.COMMON
    case 'Map':
    case 'Set':
    case 'WeakMap':
    case 'WeakSet':
      return TargetType.COLLECTION
    default:
      return TargetType.INVALID
  }
}

可以看到，targetTypeMap 函数实际上是对我们所认识的数据类型做了 3 个分类：

• TargetType.COMMON 表示对象 Object、 数组Array
• TargetType.COLLECTION 表示集合类型，Map、Set、WeakMap、WeakSet
• TargetType.INVALID 表示不合法的类型，不是对象、数组、集合

其中，TargetType 对应的枚举实现：

const enum TargetType {
  INVALID = 0,
  COMMON = 1,
  COLLECTION = 2
}

那么，回到我们上面的这个例子，由于 list.extData 在 toRawType 函数中返回的是数组 Array，所以 targetTypeMap 函数返回的类型则会是 TargetType.COMMON（不等于 TargetType.INVALID），也就是最终会为它创建响应式对象。

因此，在这里我们可以得出一个结论，如果我们需要跳过创建响应式对象的过程，则必须让 target 满足 value[ReactiveFlags.SKIP] || !Object.isExtensible(value) 或者命中 targetTypeMap 函数中的 default 逻辑。

结语

阅读到这里，我想大家都明白了如何在创建一个复杂对象的响应式对象的时候，跳过对象中一些嵌套对象的创建响应式的过程。并且，这个小技巧在某些场景下，不可否认的是一个很好的优化手段，所以提前做好必要的认知也是很重要的。

最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue ～

前言

近期，Vue3 提了一个 Ref Sugar 的 RFC，即 ref 语法糖，目前还处理实验性的（Experimental）阶段。在 RFC 的动机（Motivation）中，Evan You 介绍到在 Composition API 引入后，一个主要未解决的问题是 refs 和 reactive 对象的使用。而到处使用 .value 可能会很麻烦，如果在没使用类型系统的情况下，也会很容易错过：

let count = ref(1)

function add() {
	count.value++
}

所以，一些用户会更倾向于只使用 reactive，这样就不用处理使用 refs 的 .value 问题。而 ref 语法糖的作用是让我们在使用 ref 创建响应式的变量时，可以直接获取和更改变量本身，而不是使用 .value 来获取和更改对应的值。简单的说，站在使用层面可以告别使用 refs 时的 .value 问题：

let count = $ref(1)

function add() {
	count++
}

那么，ref 语法糖目前要怎么在项目中使用？它又是怎么实现的？这是我第一眼看到这个 RFC 建立的疑问，相信这也是很多同学持有的疑问。所以，下面让我们来一一揭晓。

1 Ref 语法糖在项目中的使用

由于 ref 语法糖目前还处于实验性的（Experimental）阶段，所以在 Vue3 中不会默认支持 ref 语法糖。那么，这里我们以使用 Vite + Vue3 项目开发为例，看一下如何开启对 ref 语法糖的支持。

在使用 Vite + Vue3 项目开发时，是由 @vitejs/plugin-vue 插件来实现对 .vue 文件的代码转换（Transform）、热更新（HMR）等。所以，我们需要在 vite.config.js 中给 @vitejs/plugin-vue 插件的选项（Options）传入 refTransform: true：

// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue({
    refTransform: true
  })]
})

那么，这样一来 @vitejs/plugin-vue 插件内部会根据传入的选项中 refTransform 的值判断是否需要对 ref 语法糖进行特定的代码转换。由于，这里我们设置的是 true，显然它是会对 ref 语法糖执行特定的代码转换。

接着，我们就可以在 .vue 文件中使用 ref 语法糖，这里我们看一个简单的例子：

<template>
	<div>{{count}}</div>
	<button @click="add">click me</button>
</template>

<script setup>
let count = $ref(1)

function add() {
	count++
}
</script>

对应渲染到页面上：

可以看到，我们可以使用 ref 语法糖的方式创建响应式的变量，而不用思考使用的时候要加 .value 的问题。此外，ref 语法糖还支持其他的写法，个人比较推荐的是这里介绍的 $ref 的方式，有兴趣的同学可以去 RFC 上了解其他的写法。

那么，在了解完 ref 语法糖在项目中的使用后，我们算是解答了第一个疑问（怎么在项目中使用）。下面，我们来解答第二个疑问，它又是怎么实现的，也就是在源码中做了哪些处理？

2 Ref 语法糖的实现

首先，我们通过 Vue Playground 来直观地感受一下，前面使用 ref 语法糖的例子中的 <script setup> 块（Block）在编译后的结果：

import { ref as _ref } from 'vue'

const __sfc__ = {
  setup(__props) {
  let count = _ref(1)

  function add() {
    count.value++
  }
}

可以看到，虽然我们在使用 ref 语法糖的时候不需要处理 .value，但是它经过编译后仍然是使用的 .value。那么，这个过程肯定不难免要做很多编译相关的代码转换处理。因为，我们需要找到使用 $ref 的声明语句和变量，给前者重写为 _ref，给后者添加 .value。

而在前面，我们也提及 @vitejs/plugin-vue 插件会对 .vue 文件进行代码的转换，这个过程则是使用的 Vue3 提供的 @vue/compiler-sfc 包（Package），它分别提供了对 <script>、<template>、<style> 等块的编译相关的函数。

那么，显然这里我们需要关注的是 <script> 块编译相关的函数，这对应的是 @vue/compiler-sfc 中的 compileScript() 函数。

2.1 compileScript() 函数

compileScript() 函数定义在 vue-next 的 packages/compiler-sfc/src/compileScript.ts 文件中，它主要负责对 <script> 或 <script setup> 块内容的编译处理，它会接收 2 个参数：

• sfc 包含 .vue 文件的代码被解析后的内容，包含 script、scriptSetup、source 等属性
• options 包含一些可选和必须的属性，例如组件对应的 scopeId 会作为 options.id、前面提及的 refTransform 等

compileScript() 函数的定义（伪代码）：

// packages/compiler-sfc/src/compileScript.ts
export function compileScript(
  sfc: SFCDescriptor,
  options: SFCScriptCompileOptions
): SFCScriptBlock {
  // ...
  return {
    ...script,
    content,
    map,
    bindings,
    scriptAst: scriptAst.body
  }
} 

对于 ref 语法糖而言，compileScript() 函数首先会获取选项（Option）中 refTransform 的值，并赋值给 enableRefTransform：

const enableRefTransform = !!options.refTransform

enableRefTransform 则会用于之后判断是否要调用 ref 语法糖相关的转换函数。那么，前面我们也提及要使用 ref 语法糖，需要先给 @vite/plugin-vue 插件选项的 refTransform 属性设置为 true，它会被传入 compileScript() 函数的 options，也就是这里的 options.refTransform。

接着，会从 sfc 中解构出 scriptSetup、source、filename 等属性。其中，会先用源文件的代码字符串 source 创建一个 MagicString 实例 s，它主要会用于后续代码转换时对源代码字符串进行替换、添加等操作，然后会调用 parse() 函数来解析 <script setup> 的内容，即 scriptSetup.content，从而生成对应的抽象语法树 scriptSetupAst：

let { script, scriptSetup, source, filename } = sfc
const s = new MagicString(source)
const startOffset = scriptSetup.loc.start.offset
const scriptSetupAst = parse(
  scriptSetup.content,
  {
    plugins: [
      ...plugins,
      'topLevelAwait'
    ],
    sourceType: 'module'
  },
  startOffset
)

而 parse() 函数内部则是使用的 @babel/parser 提供的 parser 方法进行代码的解析并生成对应的 AST。对于上面我们这个例子，生成的 AST 会是这样：

{
  body: [ {...}, {...} ],
  directives: [],
  end: 50,
  interpreter: null,
  loc: {
    start: {...}, 
    end: {...}, 
    filename: undefined, 
    identifierName: undefined
  },
  sourceType: 'module',
  start: 0,
  type: 'Program'
}

注意，这里省略了 body、start、end 中的内容

然后，会根据前面定义的 enableRefTransform 和调用 shouldTransformRef() 函数的返回值（true 或 false）来判断是否进行 ref 语法糖的代码转换。如果，需要进行相应的转换，则会调用 transformRefAST() 函数来根据 AST 来进行相应的代码转换操作：

if (enableRefTransform && shouldTransformRef(scriptSetup.content)) {
  const { rootVars, importedHelpers } = transformRefAST(
    scriptSetupAst,
    s,
    startOffset,
    refBindings
  )
}

在前面，我们已经介绍过了 enableRefTransform。这里我们来看一下 shouldTransformRef() 函数，它主要是通过正则匹配代码内容 scriptSetup.content 来判断是否使用了 ref 语法糖：

// packages/ref-transform/src/refTransform.ts
const transformCheckRE = /[^\w]\$(?:\$|ref|computed|shallowRef)?\(/

export function shouldTransform(src: string): boolean {
  return transformCheckRE.test(src)
}

所以，当你指定了 refTransform 为 true，但是你代码中实际并没有使用到 ref 语法糖，则在编译 <script> 或 <script setup> 的过程中也不会执行和 ref 语法糖相关的代码转换操作，这也是 Vue3 考虑比较细致的地方，避免了不必要的代码转换操作带来性能上的开销。

那么，对于我们这个例子而言（使用了 ref 语法糖），则会命中上面的 transformRefAST() 函数。而 transformRefAST() 函数则对应的是 packages/ref-transform/src/refTransform.ts 中的 transformAST() 函数。

所以，下面我们来看一下 transformAST() 函数是如何根据 AST 来对 ref 语法糖相关代码进行转换操作的。

2.2 transformAST() 函数

在 transformAST() 函数中主要是会遍历传入的原代码对应的 AST，然后通过操作源代码字符串生成的 MagicString 实例 s 来对源代码进行特定的转换，例如重写 $ref 为 _ref、添加 .value 等。

transformAST() 函数的定义（伪代码）：

// packages/ref-transform/src/refTransform.ts
export function transformAST(
  ast: Program,
  s: MagicString,
  offset = 0,
  knownRootVars?: string[]
): {
  // ...
  walkScope(ast)
  (walk as any)(ast, {
    enter(node: Node, parent?: Node) {
      if (
        node.type === 'Identifier' &&
        isReferencedIdentifier(node, parent!, parentStack) &&
        !excludedIds.has(node)
      ) {
        let i = scopeStack.length
        while (i--) {
          if (checkRefId(scopeStack[i], node, parent!, parentStack)) {
            return
          }
        }
      }
    }
  })
  
  return {
    rootVars: Object.keys(rootScope).filter(key => rootScope[key]),
    importedHelpers: [...importedHelpers]
  }
}

可以看到 transformAST() 会先调用 walkScope() 来处理根作用域（root scope），然后调用 walk() 函数逐层地处理 AST 节点，而这里的 walk() 函数则是使用的 Rich Haris 写的 estree-walker。

下面，我们来分别看一下 walkScope() 和 walk() 函数做了什么。

walkScope() 函数

首先，这里我们先来看一下前面使用 ref 语法糖的声明语句 let count = $ref(1) 对应的 AST 结构：

可以看到 let 的 AST 节点类型 type 会是 VariableDeclaration，其余的代码部分对应的 AST 节点则会被放在 declarations 中。其中，变量 count 的 AST 节点会被作为 declarations.id ，而 $ref(1) 的 AST 节点会被作为 declarations.init。

那么，回到 walkScope() 函数，它会根据 AST 节点的类型 type 进行特定的处理，对于我们这个例子 let 对应的 AST 节点 type 为 VariableDeclaration 会命中这样的逻辑：

function walkScope(node: Program | BlockStatement) {
  for (const stmt of node.body) {
    if (stmt.type === 'VariableDeclaration') {
      for (const decl of stmt.declarations) {
        let toVarCall
        if (
          decl.init &&
          decl.init.type === 'CallExpression' &&
          decl.init.callee.type === 'Identifier' &&
          (toVarCall = isToVarCall(decl.init.callee.name))
        ) {
          processRefDeclaration(
            toVarCall,
            decl.init as CallExpression,
            decl.id,
            stmt
          )
        }
      }
    }
  }
}

这里的 stmt 则是 let 对应的 AST 节点，然后会遍历 stmt.declarations，其中 decl.init.callee.name 指的是 $ref，接着是调用 isToVarCall() 函数并赋值给 toVarCall。

isToVarCall() 函数的定义：

// packages/ref-transform/src/refTransform.ts
const TO_VAR_SYMBOL = '$'
const shorthands = ['ref', 'computed', 'shallowRef']
function isToVarCall(callee: string): string | false {
  if (callee === TO_VAR_SYMBOL) {
    return TO_VAR_SYMBOL
  }
  if (callee[0] === TO_VAR_SYMBOL && shorthands.includes(callee.slice(1))) {
    return callee
  }
  return false
}

在前面我们也提及 ref 语法糖可以支持其他写法，由于我们使用的是 $ref 的方式，所以这里会命中 callee[0] === TO_VAR_SYMBOL && shorthands.includes(callee.slice(1)) 的逻辑，即 toVarCall 会被赋值为 $ref。

然后，会调用 processRefDeclaration() 函数，它会根据传入的 decl.init 提供的位置信息来对源代码对应的 MagicString 实例 s 进行操作，即将 $ref 重写为 ref：

// packages/ref-transform/src/refTransform.ts
function processRefDeclaration(
    method: string,
    call: CallExpression,
    id: VariableDeclarator['id'],
    statement: VariableDeclaration
) {
  // ...
  if (id.type === 'Identifier') {
    registerRefBinding(id)
    s.overwrite(
      call.start! + offset,
      call.start! + method.length + offset,
      helper(method.slice(1))
    )
  } 
  // ...
}

位置信息指的是该 AST 节点在源代码中的位置，通常会用 start、end 表示，例如这里的 let count = $ref(1)，那么 count 对应的 AST 节点的 start 会是 4、end 会是 9。

因为，此时传入的 id 对应的是 count 的 AST 节点，它会是这样：

{
  type: "Identifier",
  start: 4,
  end: 9,
  name: "count"
}

所以，这会命中上面的 id.type === 'Identifier' 的逻辑。首先，会调用 registerRefBinding() 函数，它实际上是调用的是 registerBinding()，而 registerBinding 会在当前作用域 currentScope 上绑定该变量 id.name 并设置为 true ，它表示这是一个用 ref 语法糖创建的变量，这会用于后续判断是否给某个变量添加 .value：

const registerRefBinding = (id: Identifier) => registerBinding(id, true)
function registerBinding(id: Identifier, isRef = false) {
  excludedIds.add(id)
  if (currentScope) {
    currentScope[id.name] = isRef
  } else {
    error(
      'registerBinding called without active scope, something is wrong.',
      id
    )
  }
}

可以看到，在 registerBinding() 中还会给 excludedIds 中添加该 AST 节点，而 excludeIds 它是一个 WeekMap，它会用于后续跳过不需要进行 ref 语法糖处理的类型为 Identifier 的 AST 节点。

然后，会调用 s.overwrite() 函数来将 $ref 重写为 _ref，它会接收 3 个参数，分别是重写的起始位置、结束位置以及要重写为的字符串。而 call 则对应着 $ref(1) 的 AST 节点，它会是这样：

{
  type: "Identifier",
  start: 12,
  end: 19,
  callee: {...}
  arguments: {...},
  optional: false
}

并且，我想大家应该注意到了在计算重写的起始位置的时候用到了 offset，它代表着此时操作的字符串在源字符串中的偏移位置，例如该字符串在源字符串中的开始，那么偏移量则会是 0。

而 helper() 函数则会返回字符串 _ref，并且在这个过程会将 ref 添加到 importedHelpers 中，这会在 compileScript() 时用于生成对应的 import 语句：

function helper(msg: string) {
  importedHelpers.add(msg)
  return `_${msg}`
}

那么，到这里就完成了对 $ref 到 _ref 的重写，也就是此时我们代码的会是这样：

let count = _ref(1)

function add() {
	count++
}

接着，则是通过 walk() 函数来将 count++ 转换成 count.value++。下面，我们来看一下 walk() 函数。

walk() 函数

前面，我们提及 walk() 函数使用的是 Rich Haris 写的 estree-walker，它是一个用于遍历符合 ESTree 规范的 AST 包（Package）。

walk() 函数使用起来会是这样：

import { walk } from 'estree-walker'

walk(ast, {
  enter(node, parent, prop, index) {
    // ...
  },
  leave(node, parent, prop, index) {
    // ...
  }
});

可以看到，walk() 函数中可以传入 options，其中 enter() 在每次访问 AST 节点的时候会被调用，leave() 则是在离开 AST 节点的时候被调用。

那么，回到前面提到的这个例子，walk() 函数主要做了这 2 件事：

1.维护 scopeStack、parentStack 和 currentScope

scopeStack 用于存放此时 AST 节点所处的作用域链，初始情况下栈顶为根作用域 rootScope；parentStack 用于存放遍历 AST 节点过程中的祖先 AST 节点（栈顶的 AST 节点是当前 AST 节点的父亲 AST 节点）；currentScope 指向当前的作用域，初始情况下等于根作用域 rootScope：

const scopeStack: Scope[] = [rootScope]
const parentStack: Node[] = []
let currentScope: Scope = rootScope

所以，在 enter() 的阶段会判断此时 AST 节点类型是否为函数、块，是则入栈 scopeStack：

parent && parentStack.push(parent)
if (isFunctionType(node)) {
  scopeStack.push((currentScope = {}))
  // ...
  return
}
if (node.type === 'BlockStatement' && !isFunctionType(parent!)) {
  scopeStack.push((currentScope = {}))
  // ...
  return
}

然后，在 leave() 的阶段判断此时 AST 节点类型是否为函数、块，是则出栈 scopeStack，并且更新 currentScope 为出栈后的 scopeStack 的栈顶元素：

parent && parentStack.pop()
if (
  (node.type === 'BlockStatement' && !isFunctionType(parent!)) ||
  isFunctionType(node)
) {
  scopeStack.pop()
  currentScope = scopeStack[scopeStack.length - 1] || null
}

2.处理 Identifier 类型的 AST 节点

由于，在我们的例子中 ref 语法糖创建 count 变量的 AST 节点类型是 Identifier，所以这会在 enter() 阶段命中这样的逻辑：

if (
    node.type === 'Identifier' &&
    isReferencedIdentifier(node, parent!, parentStack) &&
    !excludedIds.has(node)
  ) {
    let i = scopeStack.length
    while (i--) {
      if (checkRefId(scopeStack[i], node, parent!, parentStack)) {
        return
      }
    }
  }

在 if 的判断中，对于 excludedIds 我们在前面已经介绍过了，而 isReferencedIdentifier() 则是通过 parenStack 来判断当前类型为 Identifier 的 AST 节点 node 是否是一个引用了这之前的某个 AST 节点。

然后，再通过访问 scopeStack 来沿着作用域链来判断是否某个作用域中有 id.name（变量名 count）属性以及属性值为 true，这代表它是一个使用 ref 语法糖创建的变量，最后则会通过操作 s（s.appendLeft）来给该变量添加 .value：

function checkRefId(
    scope: Scope,
    id: Identifier,
    parent: Node,
    parentStack: Node[]
): boolean {
  if (id.name in scope) {
    if (scope[id.name]) {
      // ...
      s.appendLeft(id.end! + offset, '.value')
    }
    return true
  }
  return false
}

结语

通过了解 ref 语法糖的实现，我想大家应该会对语法糖这个术语会有不一样的理解，它的本质是在编译阶段通过遍历 AST 来操作特定的代码转换操作。并且，这个实现过程的一些工具包（Package）的配合使用也是非常巧妙的，例如 MagicString 操作源代码字符串、estree-walker 遍历 AST 节点等。

最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue ～

前言

又回到了经典的一句话：“先知其然，而后使其然”。相信很多同学都知道了 esbuild，其以飞快的构建速度闻名于众。并且，esbuild 作者 Evan Wallace 也在官网的 FAQ专门介绍了为什么 esbuild 会这么快？（有兴趣的同学可以自行了解 https://esbuild.github.io/faq/）

那么，回到今天本文，将会从 esbuild 源码的目录结构入手，围绕以下 2 点和大家一起走进 esbuild 底层的世界：

• 初识 Esbuild 构建的入口
• Esbuild 构建的入口做了什么

1 初识 Esbuild 构建的入口

在 Go 中，是以 package （包）来划分模块，每个 Go 的应用程序都需要包含一个入口 package main，即 main.go 文件。那么，显然 esbuild 本身也是一个 Go 应用，即它的入口文件同样也是 main.go 文件。

而对于 esbuild，它的目录结构：

|—— cmd
|—— docs
|—— images
|—— internal
|—— lib
|—— npm
|—— pkg
|—— require
|—— scripts
.gitignore
go.mod
go.sum
Makefile
README.md
version.txt

似乎一眼望去，并没有我们想要的 main.go 文件，那么我们要怎么找到整个应用的入口？

学过 C 的同学，应该知道 Make 这个构建工具，它可以用于执行我们定义好的一系列命令，来实现某个构建目标。并且，不难发现的是上面的目录结构中有一个 Makefile 文件，它则是用来注册 Make 命令的。

而在 Makefile 文件中注册规则的基础语法会是这样：

<target> : <prerequisites> 
[tab]  <commands>

这里，我们来分别认识一下各个参数的含义：

• target 构建的目标，即使用 Make 命令的目标，例如 make 某个目标名
• prerequisites 前置条件，通常是一些文件对应的路径，一旦这些文件发生变动，在执行 Make 命令时，就会进行重新构建，反之不会
• tab 固定的语法格式要求，命令 commands 的开始必须为一个 tab 键
• commands 命令，即执行 Make 命令构建某个目标时，对应会执行的命令

那么，下面我们来看一下 esbuild 中 Makefile 文件中的内容：

ESBUILD_VERSION = $(shell cat version.txt)

# Strip debug info
GO_FLAGS += "-ldflags=-s -w"

# Avoid embedding the build path in the executable for more reproducible builds
GO_FLAGS += -trimpath

esbuild: cmd/esbuild/version.go cmd/esbuild/*.go pkg/*/*.go internal/*/*.go go.mod
	CGO_ENABLED=0 go build $(GO_FLAGS) ./cmd/esbuild

test:
	make -j6 test-common

# These tests are for development
test-common: test-go vet-go no-filepath verify-source-map end-to-end-tests js-api-tests plugin-tests register-test node-unref-tests

# These tests are for release (the extra tests are not included in "test" because they are pretty slow)
test-all:
	make -j6 test-common test-deno ts-type-tests test-wasm-node test-wasm-browser lib-typecheck
....

注意：这里只是列出了 Makefile 文件中的部分规则，有兴趣的同学可以自行查看其他规则～

可以看到，在 Makefile 文件中注册了很多规则。而我们经常使用的 esbuild 命令，则对应着这里的 esbuild 目标。

根据上面对 Makefile 的介绍以及结合这里的内容，我们可以知道的是 esbuild 命令的核心是由 cmd/esbuild/version.go cmd/esbuild/*.go 和 pkg/*/*.go、internal/*/*.go go.mod 这三部分相关的文件实现的。

那么，通常执行 make esbuild 命令，其本质上是执行命令：

CGO_ENABLED=0 go build $(GO_FLAGS) ./cmd/esbuild

下面，我们来分别看一下这个命令做了什么（含义）：

CGO_ENABLED=0

CGO_ENABLED 是 Go 的环境（env）信息之一，我们可以用 go env 命令查看 Go 支持的所有环境信息。

而这里将 CGO_ENABLED 设为 0 是为了禁用 cgo，因为默认情况下，CGO_ENABLED 为 1，也就是开启 cgo 的，但是 cgo 是会导入一些包含 C 代码的文件，那么也就是说最后编译的结果会包含一些外部动态链接，而不是纯静态链接。

cgo 可以让你在 .go 文件中使用 C 的语法，这里不做详细的展开介绍，有兴趣的同学可以自行了解

那么，这个时候大家可能会思考外部动态链接和静态链接之间的区别是什么？为什么需要纯静态链接的编译结果？

这是因为外部动态链接会打破你最后编译出的程序对平台的适应性。因为，外部动态链接存在一定的不确定因素，简单的说也许你现在构建出来的应用是可以用的，但是在某天外部动态链接的内容发生了变化，那么很可能会对你的程序运行造成影响。

go build $(GO_FLAGS) ./cmd/esbuild

go build $(GO_FLAGS) ./cmd/esbuild 的核心是 go build 命令，它是用于编译源码文件、代码包、依赖包等操作，例如我们这里是对 ./cmd/esbuild/main.go 文件执行编译操作。

到这里，我们就已经知道了 esbuild 构建的入口是 cmd/esbuild/main.go 文件了。那么，接下来就让我们看一下构建的入口都做了哪些事情？

2 Esbuild 构建的入口做了什么？

虽然，Esbuild 构建的入口 cmd/esbuild/main.go 文件的代码总共才 268 行左右。但是，为了方便大家理解，这里我将拆分为以下 3 点来分步骤讲解：

• 基础依赖的 package 导入
• --help 的文字提示函数的定义
• main 函数具体都做了哪些

2.1 基础依赖的 package 导入

首先，是基础依赖的 package 导入，总共导入了 8 个 package：

import (
	"fmt"
	"os"
	"runtime/debug"
	"strings"
	"time"

	"github.com/evanw/esbuild/internal/api_helpers"
	"github.com/evanw/esbuild/internal/logger"
	"github.com/evanw/esbuild/pkg/cli"
)

这 8 个 package 分别对应的作用：

• fmt 用于格式化输出 I/O 的函数
• os 提供系统相关的接口
• runtime/debug 提供程序在运行时进行调试的功能
• strings 用于操作 UTF-8 编码的字符串的简单函数
• time 用于测量和展示时间
• github.com/evanw/esbuild/internal/api_helpers 用于检测计时器是否正在使用
• github.com/evanw/esbuild/internal/logger 用于格式化日志输出
• github.com/evanw/esbuild/pkg/cli 提供 esbuild 的命令行接口

2.2 --help 的文字提示函数的定义

任何一个工具都会有一个 --help 的选项（option），用于告知用户能使用的具体命令。所以，esbuild 的 --help 文字提示函数的定义也具备同样的作用，对应的代码（伪代码）：

var helpText = func(colors logger.Colors) string {
	return `
` + colors.Bold + `Usage:` + colors.Reset + `
  esbuild [options] [entry points]

` + colors.Bold + `Documentation:` + colors.Reset + `
  ` + colors.Underline + `https://esbuild.github.io/` + colors.Reset + `

` + colors.Bold
  ...
}

这里会用到我们上面提到的 logger 这个 package 的 Colors 结构体，它主要用于美化在终端输出的内容，例如加粗（Bold）、颜色（Red、Green）：

type Colors struct {
	Reset     string
	Bold      string
	Dim       string
	Underline string

	Red   string
	Green string
	Blue  string

	Cyan    string
	Magenta string
	Yellow  string
}

而使用 Colors 结构体创建的变量会是这样：

var TerminalColors = Colors{
	Reset:     "\033[0m",
	Bold:      "\033[1m",
	Dim:       "\033[37m",
	Underline: "\033[4m",

	Red:   "\033[31m",
	Green: "\033[32m",
	Blue:  "\033[34m",

	Cyan:    "\033[36m",
	Magenta: "\033[35m",
	Yellow:  "\033[33m",
}

2.3 main 函数主要都做了哪些

在前面，我们也提及了每个 Go 的应用程序都必须要有一个 main package，即 main.go 文件来作为应用的入口。而在 main.go 文件内也必须声明 main 函数，来作为 package 的入口函数。

那么，作为 esbuild 的入口文件的 main 函数，主要是做这 2 件事：

1. 获取输入的选项（option），并进行处理

使用我们上面提到的 os 这个 package 获取终端输入的选项，即 os.Args[1:]。其中 [1:] 表示获取数组从索引为 1 到最后的所有元素构成的数组。

然后，会循环 osArgs 数组，每次会 switch 判断具体的 case，对不同的选项，进行相应的处理。例如 --version 选项，会输出当前 esbuild 的版本号以及退出：

fmt.Printf("%s\n", esbuildVersion)
os.Exit(0)

这整个过程对应的代码会是这样：

osArgs := os.Args[1:]
argsEnd := 0
for _, arg := range osArgs {
  switch {
  case arg == "-h", arg == "-help", arg == "--help", arg == "/?":
    logger.PrintText(os.Stdout, logger.LevelSilent, os.Args, helpText)
    os.Exit(0)

  // Special-case the version flag here
  case arg == "--version":
    fmt.Printf("%s\n", esbuildVersion)
    os.Exit(0)
    ...
  default:
    osArgs[argsEnd] = arg
    argsEnd++
  }
}

并且，值得一提的是这里会重新构造 osArgs 数组，由于选项是可以一次性输入多个的，
但是 osArgs 会在后续的启动构建的时候作为参数传入，所以这里处理过的选项会在数组中去掉。

2. 调用 cli.Run()，启动构建

对于使用者来说，我们切实关注的是使用 esbuild 来打包某个应用，例如使用 esbuild xxx.js --bundle 命令。而这个过程由 main 函数最后的自执行函数完成。

该函数的核心是调用 cli.Run() 来启动构建过程，并且传入上面已经处理过的选项。

func() {
  ...
  exitCode = cli.Run(osArgs)
}()

并且，在正式开启构建之前，会根据继续处理前面的选项相关的逻辑，具体会涉及到 CPU 跟踪、堆栈的跟踪等，这里不作展开介绍，有兴趣的同学自行了解。

结语

好了，到这里我们就大致过了一遍 esbuild 构建的入口文件相关源码。站在没接触过 Go 的同学角度看可能稍微有点晦涩，并且有些分支逻辑，文中并没有展开分析，这会在后续的文章中继续展开。但是，总体上来看，打开一个新的窗户看到了不一样的风景，这不就是我们作为工程师所希望经历的嘛 😎。最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue~

前言

在前面「macOS App 自动化分发 App Store 探索与实践」和 「一文带你读懂何为 macOS App 公证，以及如何自动化实现」 2 篇文章中，分别给大家介绍了 macOS 分发自动化实现相关的内容。其中，我们总是会提及证书、App IDs 和 Provisioning Profile 等相关内容，并且证书和 Profiles 在不同的分发渠道（网络或 App Store）都有所区分。

虽然，直接通过 Apple Developer 的账户（Account）后台可以查看前面提及的内容。但是，由于这个的前提是要求我们注册 Apple Developer Program（付费 688），所以，存在一定的使用之前的成本（费用），那么或多或少就有同学对此存在一定的盲区，以及在了解后也会遇到协作和管理的问题。

那么，今天本文也将会从证书、App IDs、Provisioning Profile 作为开始，带大家一起从理论基础出发，再到如何使用工具（fastlane match）实现自动化管理。

1 证书、App IDs、Provisioning Profile

在 Apple Developer 的账户（Account）后台，有专门用于查看 Certificates, Identifiers & Profiles 的页面，你可以在这里管理你的证书 Certificates、App IDs（Identifiers）和 Provisioning Profile：

下面，我们分别来看下这 3 者。那么，首先是 App IDs（Identifiers）。

1.1 App IDs（Identifiers）

App IDs（Identifiers），它是 Identifiers 的一种，用于使得你的 App、App Extension 或 App Clip 能够访问可用服务，以及可以在 Provisioning Profile 中标识你的 App。

也就是说，App IDs 是一个应用的唯一标识，是必须要创建的，它的命名遵循 reverse-domain 的风格，例如 com.domainname.appname。并且，我们可以通过查看 macOS 上 App 的包内容（应用程序->右键-> info.plist），例如 macOS 上的微信的 App IDs 会是 com.tencent.xinWeChat。

1.2 证书 Certificates

然后，接着是证书 Certificates，证书分为这 2 类：

• 软件 Software，包括用于应用（iOS、macOS 和 watchOS 等）代码签名、Apple Store 分发（Distribution）、安装包（Installer package）签名等证书
  
• 服务 Services，包括苹果推送服务（ Apple Push Notification service ）、苹果支付处理证书（Aple Pay Payment Processing Certificate）等证书
  

并且，值得一提的是证书的创建使用的是一种 创建证书签名请求 的方式，这种方式遵循的非对称加密（RSA），它会在本地创建一对公用密钥和专用密钥（以下统称私钥 Private Key），其中，公钥用于加密证书，私钥是保存在创建者本地的钥匙串 KeyChain 中。

那么，如果你想将证书分享给别人使用，但是由于非对称加密的限制（证书是加密的），我们还需要提供解密证书对应的私钥，所以，通常情况下我们是在钥匙串中导出个人信息交换（.p12）文件，它会包含证书本身和解密它需要的私钥：

此外，关于各个证书的详细作用有兴趣的同学可以自行了解。这里，我们来看下软件 Software 证书中 macOS 开发和分发相关的 4 个证书：

• Mac Development，用于 macOS 应用开发版本的代码签名处理，例如，如果你有一个 FEKit.app 文件没有经过应用的签名，则可以使用 codesign 命令进行签名：

codesign -s "Development" ./FEKit.app

• Developer ID Application，用于 macOS 应用正式版本的代码签名处理：

codesign -s "Developer ID Application: Jingchang wu（xxxxxxxxxx）" ./FEKit.app

• Mac Installer Distribution，用于对安装包（Install Package）进行代码签名以提交到 App Store

• Mac App Distribution，用于对应用程序进行代码签名，以及配置分发 Provisioning Profile 用于提交到 App Store

1.3 Provisioning Profile

最后，则是 Provisioning（配置）Profile，Provisioning Profile 分为这 2 类：

• 开发 Development，用于配置可以安装开发版本应用的设备有哪些，也就是在创建 Development 下的某类 Provisioning Profile 文件的时候需要填入测试设备的硬件 UUID（关于本机->系统报告）

• 分发 Distribution，用于配置应用分发相关，例如提交 AppStore、使用 Apple Services 等

那么，对于 macOS 而言，我们则需要创建 **macOS App Development（配置开发版本应用的测试设备）、
Mac App Store（提交 AppStore）和 Developer ID（在网络上分发）**等 3 个 Provisioning Profile。

2 fastlane match 自动化管理

通常，我们一个项目会有多个开发者 Developer，那如何在多个开发者之间共享同一份 Mac Development、Developer ID Application 等证书或 Provisioning Profile 文件，就成为了一个比较琐碎的问题。

所以，fastlane 提供了一个名为 sync_code_signing 的 Action 用于解决上面提及的这个问题，它的 alias 是 match，也就是我们可以通过 fastlane match xxx 之类的命令来完成证书和 Provisioning Profile 文件的维护（创建、更新）和拉取（同步到开发者本地），而这些操作则是使用的 Apple Store Connect API 提供的接口实现的。

其中，由于 fastlane 需要指定的可以用于存储证书和 Provisioning Profile 文件的地方，你可以使用 Git Repo、Google Cloud 和 Amazon S3 其中的 1 种作为存储的选择，这里我们选择用 GitLab 的 Repo。

那么，首先是在你的项目中执行 fastlane match init 命令，它会提示你要选择的存储方式：

这里我们选择 Git，然后需要输入 Repo 的地址，最后它会在当前项目路径的 ./fastlane 文件目录中创建 Matchfile 文件：

git_url("https://gitlab.com/xxxxx/xxxxxxxxxx.git")

storage_mode("git")

type("development") # The default type, can be: appstore, adhoc, enterprise or development

# app_identifier(["tools.fastlane.app", "tools.fastlane.app2"])
# username("[email protected]") # Your Apple Developer Portal username

可以看到，默认设置了 git_url 为前面输入的 Git Repo 的地址（以下统称 Match Repo），然后 storage_mode 设置的为 git，并且默认会设置 type 为 development，这意味着在执行 fastlane match development --readonly 命令的时候会获取所有 development 相关的证书和 Provisioning Profile 文件（如果没有则会重新创建）。

由于，很多情况下我们使用 fastlane match <type> 相关的命令的时候，我们可能已经创建好了各类的证书和 Provisioning Profile 文件。所以，不能直接使用 fastlane match <type> 的命令，这样会给你撤销之前已创建好的这些文件并创建一个新的。

因此，我们需要使用 fastlane match import 命令来将本地的证书（.cer）、个人信息交换（.p12）和 Provisioning Profile 文件手动导入到 Match Repo 中，例如我们需要把 Developer ID Application 相关的证书、p12、Provisioning Profile 文件导入：

1.首先，修改下之前的 Matchfile 文件的内容：

# 注意，默认为 master 分支
git_url("https://gitlab.com/xxxxx/xxxxxxxxxx.git")

storage_mode("git")
# 指定证书、.p12、Provisioning Profile 的类型
type("developer_id")
# 指定我们的 App IDs
app_identifier("com.xxx.xxxx")

2.接着，将本地的上面提及的文件在钥匙串中分别导出到文件系统中。

3.最后，使用 fastlane match import 命令，此时会让你输入各个文件所在的位置，然后需要输入密码用于证书的加密，也就是说其他人从 Match Repo 拉取的时候需要输入对应的密码用于解密，接着则还会让你输入 Apple Developer Program 账户来对这些文件进行验证，如果你不期望验证可以使用 --skip_certificate_matching true Option 来跳过这个步骤。

在完成上述文件的导入后，在 Match Repo 中可以看到新增了 /certs/developer_id_application/ 和 /profiles/developer_id/ 等 2 个目录结构，后续我们导入别的的证书（.cer）、个人信息交换（.p12）和 Provisioning Profile 文件则会一并添加到 /certs 或 /profiles 目录下：

certs
  |———— developer_id_application
        |__ xxxxx.cert
        |__ xxxxx.p12
profiles
  |———— developer_id
        |__ xxxxxxxxxxxxxxxxxxx.provisionprofile

然后，如果有同学在开发过程中需要使用到 Developer ID Application 相关的证书、私钥（.p12）和 Provisioning Profile 文件，则可以通过 fastlane match developer_id --readonly 命令获取这些文件到本地的钥匙串中，其中 --readonly 只拉取 Match Repo 中存在的 developer_id 相关文件，不会自动创建一个新的。

结语

通过阅读，对于之前一直没有接触过这方面知识的同学，我想已经对证书、App IDs 和 Provisioning Profile 等相关内容都或多或少有了一定的了解。并且，通过简单地了解 fastlane match 提供的能力，也可以让团队在这方面的协作效率和维护管理都得到了提高。此外，值得一提的是 fastlane match 提供了很多参数，来支持更多个性化的操作，例如过期自动创建、撤销指定类型的证书等，所以有兴趣的同学也推荐在文档中继续了解一番。

最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue ～

前言

距离尤大大在微博宣布「vite」的出现，不知不觉间已经过了一段时间了。

当时，「vite」只是支持对 .vue 文件的即时编译和 import 的 rewrite，相应地「Plugin」也没有几个。并且，最初在「GitHub」上「vite」的 slogan 是这样的：

—— No-bundle Dev Server for Vue 3 Single-File Components.

可以看到，起初介绍「vite」是一个不需要打包的开发阶段的服务器。但是，现在再回首，这句 slogan 已经消失了，而「vite」也已经处于 「beta」 阶段。并且，不仅仅是一个开发阶段的服务器这么简单。相应地也实现了很多「Feature」，例如：Web Assembly、JSX
、CSS Pre-processors、Dev Server Proxy 等等。

有兴趣了解这些「Feature」的同学，可以移步GitHub自行阅读

这两个月的时间，「vite」发展的劲头是非（xue）常（bu）猛（dong）的。并且，也出现了很多关于「vite」的文章，可以说是：“ 如雨后春笋般，络绎不绝 ”。

那么，作为一名「Vue」爱好者，我同样对「vite」充满了好奇。所以，回到本次文章，我会先浅析 webpack-dev-server的「HMR」，然后再循序渐进地讲解「vite」在「HMR」这个过程做了什么。

Webpack 的 HMR 过程

提及「HMR」，不可避免地是会想起现在我们家喻户晓的 webpack-dev-server 中的「HMR」。所以，我们先来了解一番webpack-dev-server的「HMR」。

首先，我们先对「HMR」建立一个基础的认知。「HMR」 全称即 Hot Module Replacement。相比较「live load」，它具有以下优点：

• 可以实现局部更新，避免多余的资源请求，提高开发效率
• 在更新的时候可以保存应用原有状态
• 在代码修改和页面更新方面，实现所见即所得

而在 webpack-dev-server 中实现「HMR」的核心就是 HotModuleReplacementPlugin ，它是「Webpack」内置的「Plugin」。在我们平常开发中，之所以改一个文件，例如 .vue 文件，会触发「HMR」，是因为在 vue-loader 中已经内置了使用 HotModuleReplacementPlugin 的逻辑。它看起来会是这样

1. Helloworld.vue

<template>
  <div>hello world</div>
</template>
<script lang="ts">
  import { Vue, Component } from 'vue-property-decorator'
  @Component
  export default class Helloworld extends Vue() {}
</script>

2. main.js（手动实现「HMR」效果）

import Vue from 'vue'
import HelloWorld from '_c/HelloWorld'

if (module.hot) {
  module.hot.accept('_c/HelloWorld', ()=>{
    // 拉取更新过的 HelloWorld.vue 文件
  })
}

new Vue({
  el: '#app',
  template: '<HelloWorld/>'
  component: { HelloWorld }
})

那么，这个就是 webpack-dev-server 实现「HMR」的本质吗？显然不是，上面说的只是，如果你要通过 webpack-dev-server 实现「HMR」，你可以这么写来实现。

如果究其底层实现，是有两个关键的点：

1.与本地服务器建立「socket」连接，注册 hash 和 ok 两个事件，发生文件修改时，给客户端推送 hash 事件。客户端根据 hash 事件中返回的参数来拉取更新后的文件。

2.HotModuleReplacementPlugin 会在文件修改后，生成两个文件，用于被客户端拉取使用。例如：

hash.hot-update.json

{
	"c": {
		"chunkname": true
	},
	"h": "d69324ef62c3872485a2"
}

chunkname.d69324ef62c3872485a2.hot-update.js，这里的 chunkname 即上面 c 中对于 key。

webpackHotUpdate("main",{
   "./src/test.js":
  (function(module, __webpack_exports__, __webpack_require__) {
    "use strict";
    eval(....)
  })
})

当然，在这之前还会涉及到对原模块代码的注入，让它具备拉取文件的能力。而这其中实现的细节就不去扣了，要不然有点喧兵夺主的感觉。

基于 native ES Module 的 devServer

基于 native ES Module 的 devServer 是「vite」实现「HMR」的重要一环。总体来说，它会做这么两件事：

• 初始化本地服务器
• 加载并执行对应的 Plugin，例如 sourceMapPlugin、moduleRewritePlugin、htmlRewritePlugin 等等。

所以，本质上，devServer 做的最重要的一件事就是加载执行 Plugin。目前，「vite」总共具备了 11 种 Plugin。

这里大致列举几点 Plugin 会做：

• 拦截请求，处理「ES Module」语法相关的代码，转化为浏览器可识别的「ES Module」语法，例如第三方模块的 import 转化为 /@module/vue.js
• 对 .ts、.vue 进行即时的编译以及 sass 或 less 的预编译
• 建立模块间的导入导出关系，即 importeeMap和客户端建立 socket 连接，用于实现「HMR」

这里就列举 devServer 几个常见的 Plugin 需要做的事，至于其他像 wasmPlugin、webWorkerPlugin 之类的 Plugin 会做些什么，有兴趣的同学可以自行去了解。

然后，我们再从代码地角度看看它是怎么实现我们上述所说的:

1.首先，我们执行 vite 命令.实际上是运行 cli.js 这个文件，这里我摘取了其中核心的逻辑：

(async () => {
  const { help, h, mode, m, version, v } = argv
  ...
  const envMode = mode || m || defaultMode
  const options = await resolveOptions(envMode)
  // 开发环境下，我们会命中 runServer
  if (!options.command || options.command === 'serve') {
    runServe(options)
  } else if (options.command === 'build') {
    runBuild(options)
  } else if (options.command === 'optimize') {
    runOptimize(options)
  } else {
    console.error(chalk.red(`unknown command: ${options.command}`))
    process.exit(1)
  }
})()
async function runServe(options: UserConfig) {
  // 在 createServer() 的时候会对 HRM、serverConfig 之类的进行初始化
  const server = require('./server').createServer(options)
  ...
}

可以看到，在自执行函数中，我们会命中 runServer() 的逻辑，而它的核心是调用 server.js 文件中的 createServer()。

createServer 方法：

export function createServer(config: ServerConfig): Server {
  const {
    ...,
    enableEsbuild = true
  } = config

  const app = new Koa<State, Context>()
  const server = resolveServer(config, app.callback())
  const watcher = chokidar.watch(root, {
    ignored: [/\bnode_modules\b/, /\b\.git\b/]
  }) as HMRWatcher
  const resolver = createResolver(root, resolvers, alias)

  const context: ServerPluginContext = {
    ...
    watcher
    ...
  }

  app.use((ctx, next) => {
    Object.assign(ctx, context)
    ctx.read = cachedRead.bind(null, ctx)
    return next()
  })

  const resolvedPlugins = [
    ...,
    moduleRewritePlugin,
    hmrPlugin,
    ...
  ]
  // 核心逻辑执行 hmrPlugin
  resolvedPlugins.forEach((m) => m && m(context))

  const listen = server.listen.bind(server)
  server.listen = (async (port: number, ...args: any[]) => {
    ...
    }) as any

  return server
}

createServer 方法做了这么几件事：

• 创建一个 koa 实例
• 创建监听除了 node_modules 之外的文件的 watcher，并传入 context 中
• 将 context 上下文传入并调用每一个 Plugin

到这里，「vite」的 devServer 的创建过程就已经完成。那么，接下来我们去领略一番属于「vite」的「HMR」过程！

vite 的 HMR 过程

在「vite」中「HMR」的实现是以 serverPluginHmr 这个 Plugin 为核心实现。这里我们以 .vue 文件的修改触发的「HMR」为例，这个过程会涉及三个 Plugin：serverPluginHtml、serverPluginHmr、serverPluginVue，这个过程看起来会是这样：

serverPluginHtml

从前面的流程图可以看到，首先是 serverPluginHtml 这个 Plugin 向 index.html 中注入了获取 hmr 模块的代码：

export const htmlRewritePlugin: ServerPlugin = ({
  root,
  app,
  watcher,
  resolver,
  config
}) => {
  const devInjectionCode =
    `\n<script type="module">\n` +
    `import "${hmrClientPublicPath}"\n` +
    `window.process = { env: { NODE_ENV: ${JSON.stringify(
      config.mode || 'development'
    )} }}\n` +
    `</script>\n`

  const scriptRE = /(<script\b[^>]*>)([\s\S]*?)<\/script>/gm
  const srcRE = /\bsrc=(?:"([^"]+)"|'([^']+)'|([^'"\s]+)\b)/

  async function rewriteHtml(importer: string, html: string) {
    ...
    html = html!.replace(scriptRE, (matched, openTag, script) => {
      ...
      return injectScriptToHtml(html, devInjectionCode)
  }

  app.use(async (ctx, next) => {
    await next()
    ...

    if (ctx.response.is('html') && ctx.body) {
      const importer = ctx.path
      const html = await readBody(ctx.body)
      if (rewriteHtmlPluginCache.has(html)) {
        ...
      } else {
        if (!html) return
        // 在这里给 index.html 文件注入代码块
        ctx.body = await rewriteHtml(importer, html)
        rewriteHtmlPluginCache.set(html, ctx.body)
      }
      return
    }
  })

}

所以，当我们访问一个 「vite」 启动的项目的时候，我们会在「network」中看到服务器返回给我们的 index.html 中的代码会多了这么一段代码：

<script type="module">
import "/vite/hmr"
window.process = { env: { NODE_ENV: "development" }}
</script>

而这一段代码，也是确保我们后续正常触发「HMR」的关键点。因为，在这里浏览器会向服务器发送请求获取 vite/hmr 模块，然后，在 serverPluginHmr 中会拦截 ctx.path===‘/vite/hmr’ 的请求，建立 socket 连接。那么，接下来我们看看 serverPluginHmr 是进行这些过程的。

serverPluginHmr

上面我们说了 serverPluginHmr 它会劫持导入 /vite/hmr 的请求，然后返回 client.js 文件。所以，我们分点来细致化地分析这个过程：

1.读取 cliten.js 文件，劫持导入 /vite/hmr 的请求

 export const hmrClientFilePath = path.resolve(
   __dirname,
   '../../client/client.js'
 )
 export const hmrClientPublicPath = `/vite/hmr`
 const hmrClient = fs
    .readFileSync(hmrClientFilePath, 'utf-8')
    .replace(`__SW_ENABLED__`, String(!!config.serviceWorker))

  app.use(async (ctx, next) => {
    if (ctx.path === hmrClientPublicPath) {
      ctx.type = 'js'
      ctx.status = 200
      ctx.body = hmrClient.replace(`__PORT__`, ctx.port.toString())
    } else {
      ...
    }
  })

这里通过 readFileSync() 读取 client.js 文件，然后分别 replace 读取到的文件内容（字符串），一个是用于判断是否支持 serviceWorker，另一个用于建立 socket 连接时的端口设置。

2.定义 send 方法，并赋值给 watcher.send，用于其他 Plugin 在热更新时向浏览器推送更新信息：

const send = (watcher.send = (payload: HMRPayload) => {
    const stringified = JSON.stringify(payload, null, 2)
    debugHmr(`update: ${stringified}`)

    wss.clients.forEach((client) => {
      // OPEN 表示已经建立连接
      if (client.readyState === WebSocket.OPEN) {
        client.send(stringified)
      }
    })
  })

3.client.js，它会做这两件事：

• 建立和服务器的 socket 连接，监听 message 事件，拿到服务器推送的 data，例如我们只修改 .vue 文件，它的 data 类型定义会是这样：

export interface UpdatePayload {
  type: 'js-update' | 'vue-reload' | 'vue-rerender' | 'style-update'
  path: string
  changeSrcPath: string
  timestamp: number
}

• 对不同的 data.type 执行不同的逻辑，目前存在 type 有：vue-reload、vue-rerender、style-update、style-remove、js-update、custom、full-reload。本次我们只分析 vue-rerender 的逻辑，其实现的核心代码如下：

const socketProtocol = location.protocol === 'https:' ? 'wss' : 'ws'
const socketUrl = `${socketProtocol}://${location.hostname}:${__PORT__}`
const socket = new WebSocket(socketUrl, 'vite-hmr')
// 监听 message 事件，拿到服务端推送的 data
socket.addEventListener('message', async ({ data }) => {
  const payload = JSON.parse(data) as HMRPayload | MultiUpdatePayload
  if (payload.type === 'multi') {
    payload.updates.forEach(handleMessage)
  } else {
    // 通常情况下会命中这个逻辑
    handleMessage(payload)
  }
})
async function handleMessage(payload: HMRPayload) {
  const { path, changeSrcPath, timestamp } = payload as UpdatePayload
  ...
  switch (payload.type) {
    ...
    case 'vue-rerender':
      const templatePath = `${path}?type=template`
      ...
      import(`${templatePath}&t=${timestamp}`).then((m) => {
        __VUE_HMR_RUNTIME__.rerender(path, m.render)
        console.log(`[vite] ${path} template updated.`)
      })
      break
    ...
  }
}

其实，这个过程还用到了 serviceWorker 做一些处理，但是看了下提交记录是 wip，所以这里就没有分析这个逻辑，有兴趣的同学可以自己了解。

serverPluginVue

前面，我们讲了 serverPluginHtml 和 serverPluginHmr 在 HMR 过程会做的一些前期准备。然后，我们这次分析的修改 .vue 文件触发的「HMR」逻辑，它的开始是在
serverPluginVue。

首先，它会解析 .vue 文件，做一些 compiler 处理，然后通过 watcher 监听 .vue 文件的修改:

watcher.on('change', (file) => {
  if (file.endsWith('.vue')) {
    handleVueReload(file)
  }
})

可以看到在 change 事件的回调中调用了 handleVueReload()，针对我们这个 case，它会是这样：

const handleVueReload = (watcher.handleVueReload = async (
    filePath: string,
    timestamp: number = Date.now(),
    content?: string
  ) => {
    const publicPath = resolver.fileToRequest(filePath)
    const cacheEntry = vueCache.get(filePath)
    const { send } = watcher
    ...
    let needRerender = false
    ...
    if (!isEqualBlock(descriptor.template, prevDescriptor.template)) {
      needRerender = true
    }
    ...
    if (needRerender) {
      send({
        type: 'vue-rerender',
        path: publicPath,
        changeSrcPath: publicPath,
        timestamp
      })
    }
  })

handleVueReload() 它会针对 .vue 文件中，不同情况走不同的逻辑。这里，我们只是修改了 .vue 文件，给它加了一行代码，那么此时就会命中 isEqualBlock() 为 false 的逻辑，所以 needRerender 为 true，最终通过 send() 方法向浏览器推送 type 为 vue-rerender 以及携带修改的文件路径的信息。然后，我们前面 client.js 中监听 message 的地方就会拿到对应的 data，再通过 import 发起获取该模块的请求。

小结

到这里，整个「vite」实现「HMR」的逻辑已经分析结束了。当然，这次只是针对 .vue 文件的修改来分析整个 HMR 的逻辑，相应地还有 .js、.css 的文件的修改触发的 HMR 的逻辑，但是，可以说的是只要理解这个过程是如何进行的，那么每一个 case 的分析，也只是依葫芦画瓢。

并且，其实在「HMR」的过程中还有一些辅助变量和概念，例如 hrmBoundaries、import chain、child importer 等等，它们都是用于帮助更好地进行 HMR 处理。所以，这里我就没有提及这些。有兴趣的同学可以自己去看源码中的讲解这些辅助变量和概念的意义。

结语

其实，在当初尤大大发微博的时候，我就想着写一篇关于「vite」源码分析的文章。这两个月，我也经历一些起起伏伏，所以，一直到现在才开始交上这份答卷。但是，现在再看「vite」源码，已经不是仅仅 devServer 这么简单了，所以这次只分析了「HMR」这个点的实现，其他方面后续有时间应该会继续写其他方面，例如 rewrite、bundle、compiler 等等

前言

首先，我们来回忆一下「CSS 作用域」这一概念，它的本质是通过让每一个选择器成为一个「unique」的存在，这样就自然而然地形成了作用域。

而提到「Vue」中「作用域 CSS」，我想大家应该立即想到以 scoped 的方式形成的带有作用域的 css。但是，值得一提的是，在「Vue」中还支持了一种「作用域 CSS」，即「CSS Module」。

提及 「CSS Module」，想必大家会有点陌生，相信有很多同学在平常开发中都是用 scoped 来实现「Vue」组件中的「作用域CSS」。所以，今天我们就来详细认知一下这两者。

一、scoped 作用域

「scoped 作用域」是「Vue」通过「postcss」来实现对每一个在 scoped 标签中定义的选择器的特殊作用域标识，例如：

<template>
  <div id="app">
    <div class="out-box">
    </div>
  </div>
</template>

<style lang="scss" scoped>
#app {
  .out-box {
    width: 200px;
    height: 200px;
    background-color: #faa;
  }
}
</style>

标识后展示在页面上的：

<div data-v-7ba5bd90 id="app">
    <div data-v-7ba5bd90 class="out-box">
    </div>
</div>

<style>
#app .out-box[data-v-7ba5bd90] {
    width: 200px;
    height: 200px;
    background-color: #faa;
}
</style>

可以看到，本质上是在原有的「选择器」的基础上通过「postcss」加上了一串 attr。

并且，在我们平常开发中，很常见的场景就是我们在使用一些已有的组件或第三方组件时，我们需要对原有组件的样式进行一些微小的改动。那么，这个时候就需要使用穿透来实现样式的改动，例如：

<style>
div >>> .out-box {
    background-color: #aaf;
}
</style>

这里需要注意的是 >>> 只是一种穿透方式，并不是所有场景下都是可以用 >>> 实现。例如，「iView」需要使用 /deep/ 的方式，「ElementUI」需要使用 ::v-deep 的方式。

二、CSS Module 作用域

相比较「scoped 作用域」，「CSS Modeul 作用域」它所具备的能力更强，所以内容也相对较多。

什么是 CSS Module

「CSS Module」指的是可以将一个定义好的「CSS」文件以变量的形式导入，然后通过使用这个变量对「HTML」中的元素进行样式的修饰，例如：

a.css

.box {
    width: 100%;
    height: 100%;
    background-color: #afa;
}

b.js

import style from './a.css'

const boxElem = document.createElement('div');
boxElem.className = style.box

然后，渲染到页面的时候，它对应的 HTML 看起来会是这样：

<div class="a-box_jlpNx"></div>

可以看出，此时的「类选择器」同样是随机生成的，这也是「CSS Module」形成作用域的所在。

值得一提的是，「CSS Module」还具备其他的能力，例如可以定义全局的「选择器」，写起来会是这样：

:global(.title) {
  color: green;
}

接下来的使用和局部的一样。至于，其他用法，有兴趣的同学可以去 GitHub 上自行阅读

CSS Module 在 Vue 中的应用

回到本文所说的，在「Vue」中也对「CSS Module」做了相应的支持，当我们在 style 标签上添加 module 属性时，「Vue」 会在当前「组件实例」上注入一个计算属性 $style，然后我们可以通过 $style 来使用我们定义好的「选择器」，例如：

HelloWorld.vue

<template>
  <div>
    <div :class="$style['inner-box']"></div>
  </div>
</template>

<style lang="scss" module>
.inner-box {
  width: 100px;
  height: 100px;
  background-color: #aaf;
}
</style>

然后，它渲染到页面时，对于的 HTML 会是这样：

<div class="HelloWorld_inner-box_jlpNx"></div>

那么，这个时候，又回到和「scoped 作用域」一样的问题，使用了「CSS Module」来定义组件的样式，那么我在使用它的时候，如何进行覆盖？

标准的答案，对于「CSS Module」并没有覆盖的说法，有的只是为一个组件设置不同的主题。

但是，如果真的需要弄，那只能通过对该模块对应的 style 标签中定义你需要的样式，然后根据传入组件的 props 来动态绑定 class

那么，为组件设置主题，我们需要在设计组件的时候，对这个组件预留 props ，并将该 props 添加到 $style 中，然后在这个组件中的相应元素中使用，例如：

Box.vue 组件

<template>
  <div>
    <div :class="$style[themeColor]"></div>
  </div>
</template>

<script>
export default {
  props: {
    themeColor: {
        type: String,
        default: 'line'
    }
  }
};
</script>

<style lang="scss" module>
.line {
  width: 100px;
  height: 100px;
  background-color: #aaf;
}
.card {
  background-color: #aaf;
}
</style>

然后，我们在使用该组件的时候通过 props 传入 line 或者 card，从而实现切换组件不同的背景色。

三、两种方式的优劣势

「scoped 作用域」:

• 对组件没有硬性要求
• 不易于管理组件样式，需要借助第三方变量定义支持
• 易于覆盖组件样式，即通过穿透来实现对样式的覆盖

「CSS Module 作用域」:

• 适合于高度沉淀下的组件使用
• 易于管理组件样式，即可以通过 style 管理组件中的选择器
• 组件样式无法通过外部直接覆盖

这里所说的管理，是指通过JavaScript便捷地控制组件样式。

结语

其实，对比「scoped」和「CSS Module」两者，各有千秋。至于，要用哪一着得看具体需求，建议大项目中可以使用「CSS Module」，小项目的话用用「scoped」应该绰绰有余。

前言

相信很多同学都自定了自己的 GitHub Profile，但是作为这个世界上最富有想象力的一个群体，我们总在不断地推成出新（造轮子）。

那么，对于 GitHub Profile 也是一样，这里我们直接看今天要实现的一个 GitHub Profile，贪吃蛇游戏：

这个 GitHub Profile 的想法来自 Platane ，它是根据 GitHub 的 Contributions 图来生成贪吃蛇游戏，最终会以 Gif 或 SVG 的形式展示。那么，下面我们就来亲自体验一番给自己的 GitHub Profile 设置贪吃蛇游戏！

设置 Git Action

Git Action 主要是根据你在当前仓库下的 .github/workflows 目录下的 .yml 文件生成对应的 Workflow。

那么，这里我们在任意一个仓库的 .github/workflows 目录下新建 .yml 文件，然后添加如下配置：

name: generate-snake

on:
  schedule:
    # 每 6 小时，执行一次
    - cron: "0 */6 * * *"
  workflow_dispatch:

jobs:
  generate-snake:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: Platane/snk@master
        with:
          # 你的 GitHub 的名称
          github_user_name: WJCHumble
          # 生成的 .gif 图存储的位置
          gif_out_path: dist/github-snake.gif
          # 生成的 .gif 图存储的位置
          svg_out_path: dist/github-snake.svg
      - uses: crazy-max/[email protected]
        with:
          target_branch: output
          build_dir: dist
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

接着，你就可以在该仓库的 Action 面板中，看到新建好的名为 generate-snake 的 Workflow：

启动 Git Action

由于我们在 .yml 配置了 workflow_dispatch 事件，所以我们可以直接通过点击面板中的 Run workflow 按钮来启动 Workflow：

等待 Workflow 运行结束后，我们就可以在该仓库的 output 分支中看到创建好的 dist 目录下会有 github-snake.gif 和 github-snake.svg 这 2 个文件。

这里是我最后生成的：

添加到你的 GitHub Profile

每个人的 GitHub Profile 就是以自己 GitHub Name 命名的仓库的 README.md。

那么，我们需要做的是在前面的 dist 目录下右键复制 Gif 图的地址，然后再添加到 GitHub Profile 的 README.md 中。

Gif 图的地址看起来会是这样：

https://github.com/WJCHumble/WJCHumble/blob/output/github-snake.gif?raw=true

至于为什么是复制 Gif 图的地址，而不是上传到自己的图床？

因为，我们前面设置的 Workflow 是每 6 个小时会执行一次，也就是这个 Gif 图也会随之更新，即同步你的 GitHub Contributions 生成贪吃蛇游戏。

结语

此外，Platane 还提供了在线地址可以输入指定的 GitHub Name 来获取其对应的 GitHub Contributions 生成贪吃蛇游戏的图片，有兴趣的同学可以体验一番。

最后，如果文中存在表达不当或错误的地方，欢迎各位同学提 Issue～

前言

随着 Vite 2.0 的发布，其底层的设计也不断地被大家所认知。其中，大家十分津津乐道的就是采用 esbuild 来做 Dev 环境下的代码转换（快到飞起 😲）。

与此同时，这也给 esbuild 带来了很多曝光。并且，esbuild 生态也陆续出现了一些新的插件（Plugin），例如 esbuild-plugin-alias、esbuild-plugin-webpack-bridge 等。

那么，回到正题，今天我将和大家一起从 esbuild 插件基础知识出发，手把手教学如何实现一个 esbuild 插件 🚀！

1 认识 esbuild 插件基础

在 esbuild 中，插件被设计为一个函数，该函数需要返回一个对象（Object），对象中包含 name 和 setup 等 2 个属性：

const myPlugin = options => {
  return {
    name: "my",
    setup(build) {
      // ....
    }
  }
}

其中，name 的值是一个字符串，它表示你的插件名称
。 setup 的值是一个函数，它会被传入一个参数 build（对象）。

build 对象上会暴露整个构建过程中非常重要的 2 个函数：onResolve 和 onLoad，它们都需要传入 Options（选项）和 CallBack（回调）等 2 个参数。

其中，Options 是一个对象，它包含 filter（必须）和 namespace 等 2 个属性:

interface OnResolveOptions {
  filter: RegExp;
  namespace?: string;
}

而 CallBack 是一个函数，即回调函数。插件实现的关键则是在 onResolve 和 onLoad 中定义的回调函数内部做一些特殊的处理。

那么，接下来我们先来认识一下 Options 的 2 个属性：namespace 和 filter（划重点，它们非常重要 😲）

1.1 namespace

默认情况下，esbuild 是在文件系统上的文件（File Modules）相对应的 namespace 中运行的，即此时 namespace 的值为 file。

esbuild 的插件可以创建 Virtual Modules，而 Virtual Modules 则会使用 namespace 来和 File Modules 做区分。

注意，每个 namespace 都是特定于该插件的。

并且，这个时候，我想可能有同学会问：什么是 Virtual Modules 😲？

简单地理解，Virtual Modules 是指在文件系统中不存在的模块，往往需要我们构造出 Virtual Modules 对应的模块内容。

1.2 filter

filter 作为 Options 上必须的属性，它的值是一个正则。它主要用于匹配指定规则的导入（import）路径的模块，避免执行不需要的回调，从而提高整体打包性能。

那么，在认识完 namespace 和 filter 后。下面我们来分别认识一下 onResolve 和 onLoad 中的回调函数。

1.3 onResolve 的回调函数

onResolve 函数的回调函数会在 esbuild 构建每个模块的导入路径（可匹配的）时执行。

onResolve 函数的回调函数需要返回一个对象，其中会包含 path、namespace、external 等属性。

通常，该回调函数会用于自定义 esbuild 处理 path 的方式，例如：

• 重写原本的路径，例如重定向到其他路径

• 将该路径所对应的模块标记为 external，即不会对改文件进行构建操作（原样输出）

1.4 onLoad 的回调函数

onLoad 函数的回调函数会在 esbuild 解析模块之前调用，主要是用于处理并返回模块的内容，并告知 esbuild 要如何解析它们。并且，需要注意的是 onLoad 的回调函数不会处理被标记为 external 的模块。

onLoad 函数的回调函数需要返回一个对象，该对象总共有 9 个属性。这里我们来认识一下较为常见 3 个属性：

• contents 处理过的模块内容
• loader 告知 esbuild 要如何解释该内容（默认为 js)。例如，返回的模块内容是 CSS，则声明 loader 为 css
• resolveDir 是在将导入路径解析为文件系统上实际路径时，要使用的文件系统目录

那么，到这里我们就已经简单认识完有关 esbuild 插件的基础知识了 😎。
所以，下面我们从实际应用场景出发，动手实现一个 esbuild 插件。

2 动手实现一个 esbuild 插件

这里我们来实现一个删除代码中 console 语句的 esbuild 插件。因为，这个过程需要识别和删除 console 对应的 AST 节点。所以，需要使用 babel 提供的 3 个工具包：

• @babel/parser 的 parse 函数解析代码生成 AST（抽象语法树）
• @babel/traverse 遍历 AST，访问需要进行操作的 AST 节点
• @babel/core 的 transformFromAst 函数将 AST 转化为代码

那么，首先是创建整个插件的整体结构，如插件名称、setup 函数：

module.exports = options => {
  return {
    name: "auto-delete-console",
    setup(build) {
    }
  }
}

其次，由于我们这个插件主要是对代码内容进行操作。所以，需要使用 onLoad 函数，并且要声明 filter 为 /\.js$/，即只匹配 JavaScript 文件：

module.exports = options => {
  return {
    name: "auto-delete-console",
    setup(build) {
      build.onLoad({ filter: /\.js$/ }, (args) => {
      }
    }
  }
}