分类： js

有关 JavaScript 的技术文章和行业分析文章。

分类
js

聊聊 NPM 里的版本号和依赖

好像一直没有写过版本号和依赖相关的内容，偶尔会有同学问，所以写一篇总结一下。

0. Semver

我们目前使用的版本规范通常基于 Semver，语义化版本。官方网站：语义化版本 2.0.0 | Semantic Versioning (semver.org)。按照其规则，版本号的结构应该是：

主（大）版本号.次（小）版本号.修正（补丁版本）号。

其中，

  • 主版本号一般包含架构和 API 的变化。如果 API 出现重大变化，使得依赖它的软件要重构，那么就要体现在大版本号里。不过现在的代码仓库很少有破坏式重构，API 一般能够在至少 2、3 个大版本里保持稳定。所以主版本号变化一般出现在大型重构时，仓库内部的代码架构和组织形式出现重大变化，或者基于不同系统，就需要升级主版本了。
  • 次版本号一般表达功能变化。架构没有变化，原有 API 也基本维持不变，只是新增了功能。这个时候就会上调次版本号。
  • 修订号一般表示修复 bug。

0.1 年代版本号

另一种流行的版本号规范是年代版本号，比如 Ubuntu，每年会发布两个版本，目前是 21.04，10月份会发布 21.10。偶数年的 .04 版本会最终成为 LTS，长期维护版本；奇数年的版本和 .10 版本则只维护半年，里面包含各种最新的软件组件，方便喜欢尝新的用户。

前端常见的软件和库，包括 node.js、Angular、Electron 也用这种方式确定版本号。

1. 依赖中指定版本号

我们在项目中可能会使用大量开源代码，这些开源代码通常都会使用包管理工具（比如 NPM，node package manager）安装和管理。

在 package.json 里，我们可以使用几个运算符告诉 NPM 我们希望怎么使用这些依赖：

  • 不写，repo: '1.0.0'。要求使用 1.0.0 版本的 repo，必须完全一致。
  • ~，repo: ~1.0.0。要求大版本为 1，小版本为 0，修订版本不限制，比 0 高就可以。
  • ^，repo: ^1.0.0。要求大版本为 1，小版本高于 0 就可以。

一般来说，使用 npm i repo 安装的依赖，默认规则是 ^；使用 npm i repo@version 安装的依赖，默认规则是写死。

2. 升级依赖

这个世界上不存在没有 Bug 的代码，也没有功能完善的代码。使用开源仓库，我们就要考虑升级依赖。一方面可以使用新功能，一方面可以解决 bug。

通常来说，直接使用 npm update 就能升级项目依赖，NPM 会按照（1）里设定的规则更新依赖。

3. 升级依赖的大版本

只使用 npm update 无法升级大版本。原因如上文所述，大版本可能包含破坏性的 API 更新，很容易导致 dev/build 失败，作为工具无法妥善处理，必须交给开发者手动完成。

很多同学因此不愿意升级大版本。但我建议大家还是要找机会做升级，尤其工具链，比如 webpack、babel。这些工具很多时候有时效性，长期不升级会导致各种问题。而且，升级工具链本身这也是我们偿还技术债务的好机会。

其实升级工具链的大版本并不复杂，大多数半天就搞定了；如果没有用到偏门功能，甚至可能直接升级就能跑。——通常来说，开源软件的作者面对使用频率高的功能，会比较保守；没人用的功能改动就会大刀阔斧一些。

升级依赖需要指定大版本，比如从 webpack 4 升级到 webpack 5，可以使用 npm i webpack@5，这样会安装大版本是 v5 的最新版本。这里有个小建议，公司的生产级别的项目，最好不要着急升级，等到 X.2 X.3 这样基本稳定的次版本发布后再升级，可以避免踩很多坑。

一般来说，开源仓库的官方也会提供迁移指南，比如 webpack v4 to v5。只要你有 v4 的配置经验，照着指南操作，大多数时候都能顺利完成。

4. 解决 npm audit 问题

开源仓库的安全问题日趋严重，GitHub 和 NPM 都会帮我们检查依赖，并且根据已知的安全问题列表发出警告。所以在安装依赖时，我们经常能看到类似下面这种警告信息：

found 5 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

这个时候，我们应该执行 npm audit 查看所有的审计结果，可能得到如下的报告：

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular expression denial of service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ glob-parent                                                  │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=5.1.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @vue/cli-service [dev]                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ @vue/cli-service > webpack-dev-server > chokidar >           │
│               │ glob-parent                                                  │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1751                            │
└───────────────┴──────────────────────────────────────────────────────────────┘

这个报告说明有问题的包是 glob-parent，它由 webpack-dev-server 引入，又因为 @vue/cli-service 而最终成为项目的依赖。很明显，它是 @vue/cli 的组成部分，是前端工具链的一环。那么通常来说，它的危害层级很低，多半不会影响到项目整体安全性。

如果是 node.js 项目，就要小心了，服务器和后端都是安全重灾区，后果可能会很严重。这个时候，你可以往上翻，找到这些报告的最前面，如果可以修复，NPM 会告诉你应该运行什么命令更新问题依赖。如果不能修复，就要自己想办法了。

比如，你可以移除出问题的依赖，不过多半不可行。或者，我比较常用的方案是，在 GitHub 上找到依赖仓库，自己 fork 一份，然后升级其中的依赖，然后发布一个我个人的版本，接下来就用我自己的版本。等到官方修复后，再用回官方版本。

5. 总结

最后按惯例总结一下。依赖是我们软件产品的重要组成部分，它们的版本事关重大，必须给予足够的关注。至少，每个月要检查一次依赖的安全审计问题，如有需要，就升级依赖。

我们自己写代码的时候，也要遵守 Semver 的规定，适时上调版本号，让版本号能表示代码的发展情况。

分类
js

用 express.js 实现流式输出 HTTP 响应

0. 前言

我们先来总结一下客户端与服务器端的数据交互方式：

  1. ajax，即 XMLHttpRequest，最常见的数据交互方式，适用于较轻量级的一次性请求，比如用户登录、CRUD 等。
  2. SSE，服务器端事件，适用于有大量服务器端推送、且不需要从客户端发送数据的需求，比如盯股票行情
  3. WebSocket，适用于上下行数据都很多、都很频繁的情况，比如在线聊天、网络游戏等

单从技术角度来看，大概是这几个。根据需求变化，我也可以组合出更多方案。比如，类似 Showman 生成视频这种需求，耗时很长，对服务器资源占用很高，就比较适合：

  1. 发起请求，产生一条任务记录，进入队列
  2. 服务器上运行独立的进程，从队列中取任务出来执行，并记录日志
  3. 客户端不断检查任务进度

1. 需求

今天的需求，介于轻量一次性，与需要服务器长时间执行之间，即 FastTest 中的发布功能。这里，我们有以下需求：

  1. 管理员点击 Publish 按钮，开始发布静态网站
  2. 服务器需要先保存数据，然后调用 webpack 发布所有语言版本
  3. 只有少数管理员会使用此功能，服务器压力不大
  4. 管理员希望能了解发布进度，及每一步的状态

所以，提交任务后等待服务器慢慢跑就不合适；等待请求完成一次性看到所有结果也不合适；最合适的，就是基于长链接，不断获取返回信息，并在前端实时看到进度。也即是：流式输出 HTTP 响应。

2. 实现

2.1 后端

后端实现我选择 node.js + express.js，在后端领域，这两个我比较熟悉。express.js 是在 node.js 网络模块上进行封装得来，使用起来很简单，也支持原生 node.js 方法。

首先我们创建一个服务器：

const express = require('express');
const app = express();
const port = 3100;

app.listen(port, () => {
  console.log('FastTest Admin API at: ', port);
});

然后，我们在需要流式返回响应的接口里设置相应头 Content-type: application/octet-stream。接下来，只要我们不断向输出流写入内容就可以了。哦，对了，结束的时候，我们还要关闭输出流。

app.post('/data', async(req, res, next) => {
  res.setHeader('Content-type', 'application/octet-stream');
  
  // 第一次返回
  res.write('Local data saved. Start to build dist。files.\n');

  // 数次返回
  for (const item of items) {
    await doSomething(item);
    res.write(`${item} done successfully.\n`);
  }

  // 最后，全部完成
  res.write('All done.');
  // 关闭输出流
  res.end();
});

2.2 axios

axios 是很流行的 ajax 库，它进行了 Promise 封装，用起来很方便。这里我们要用 onDownloadProgress（即 axios 对 XMLHttpRequest.progress 的封装）获取下载进度，它会在每次服务器返回响应字符串的时候更新，我们只需要截取上次响应之后，这次响应新增的内容，即可。

function publish(data, onDownloadProgress) {
  return axios.post('/data', data, {
    onDownloadProgress,
  });
}

async function doPublish() {
  if (isLoading.value) {
    return;
  }

  isPublishing.value = true;
  message.value = status.value = null;

  try {
    const { cases, lang } = store.state;
    let offset = 0;
    await publish({ cases, lang }, ({ target: xhr }) => {
      // responseText 包含了从一开始到此刻的全部响应内容，所以我们需要从上次结束的位置截取，获得新增的内容
      const { responseText } = xhr;
      const chunk = responseText.substring(offset);
      // 记录这一次的结束位置
      offset = responseText.length;
      currentStatus.value = chunk;
    });
    status.value = true;
    currentStatus.value = '';
    message.value = 'Published successfully.';
  } catch (e) {
    message.value = 'Failed to publish. ' + e.message;
  }
  isPublishing.value = false;
}

2.3 Vue3

相对来说，Vue3 的部分最容易。这里我用了 animate.css 的 flash 效果，让信息更显眼。除此之外，就是简单的赋值。

<template lang="pug">
.alert.alert-info.mb-0.me-2.py-1.px-3.animated.flash.infinite.slower(
  v-if="currentStatus",
) {{currentStatus}}
</template>

3. 效果演示

流式输出效果演示

4. 部署

一般来说，我们很少会直接用 node.js 当服务器，多半会启动 node.js 服务，然后用 nginx 反向代理给用户访问。这里需要注意，nginx 默认会将响应内容存入缓冲区，然后批量返回给客户端。这会导致流式输出无效，变成常规的执行完毕后一次性输出。

所以我们必须修改 nginx 的配置：

# 仅展示有关配置
location /data {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://localhost:3100;
        # 关闭代理缓冲区，所有响应实时输出
        proxy_buffering off;
}

5. 总结 & 扩展阅读

前些天我帮朋友做了个小项目，叫 FastTest。项目很简单，不过我主动扩展了技术选型，使用了非常多的技术，都是浅显入门的程度，非常适合用来做基础入门学习。本文也是从这个项目中提炼出来的。建议大家有空的时候看看，拉到本地，跑起来试试看效果。

文中的几段代码，分别位于：

项目的详细介绍请见：超全面全栈入门项目：fastest

扩展阅读

分类
js

检查超宽元素的脚本

有时候我们制作页面，搞着搞着发现超宽，出现横向滚动条。于是我们就要想办法调整样式，但是往往超宽的只有那么一两个元素，并不是很好找，所以我就写了下面一个脚本，在页面里跑一下就能找到超宽的元素，然后针对性调整一下样式就可以了：

// 这里的 375 主要针对基于 iPhone 6 开发移动端页面时
function traverse(parent) {
  let target;
  for (const elem of parent.children) {
    const rect = elem.getBoundingClientRect();
    const {left, width} = rect;
    if (left + width > 375) {
      target = elem;
      break;
    }
    target = traverse(elem);
    if (target) {
      return target;
    }
  }
  if (target) {
    return target;
  }
}

使用的时候，打开页面的开发者工具，将这段代码复制到 console 里面，然后执行 traverse(document.body) 就可以找到超宽的元素，然后想办法调整它即可。

当然我们也可以继续用这个函数探索可疑元素，找到更具体的超宽元素；或者找到其它超宽元素。这些就留给大家自行探索吧。

分类
js

Webpack 不支持 `import.meta`，利用 ESM 在浏览器里使用 yargs

我和龙猫

前些天遇到一个需求：解析 curl 请求，并转换成 ajax 请求由浏览器发出去。

我觉得这个需求听起来不算稀罕，理论上应该有现成的库。于是在 npm 找了一下，发现 curlconverter 似乎可以满足需求。但是使用的时候报错：Module parse failed: Unexpected token。

这个错误很奇怪，看起来像是 loader 没配好。打开报错的文件位置，怎么看语法都没问题。尝试修改 webpack 配置，也未果。因为项目是 vue-cli 创建的，在如何查看最终配置上也浪费很多时间。

最后继续诉诸 Google，关键词换来换去，终于在搜索 mjs Module parse failed: Unexpected token 时找到这个 issue：https://github.com/arnog/mathlive/issues/525，继而找到 https://github.com/webpack/webpack/issues/6719，终于确定，这是 webpack 的问题。

因为 webpack 不支持 import.meta，所以会把 import.meta 当成语法错报告。我觉得这个行为很扯，因为 loader 配错也会报这个，所以对于第一次接触到这个问题的开发者（比如我）而言，会浪费大量时间在那些初级错误的搜索结果里。

接下来解决问题。

curlconverter 虽然不能直接使用，但仔细阅读它的代码，其中 https://github.com/NickCarneiro/curlconverter/blob/master/util.js 解析 curl 命令的功能实现应该问题不大，我只要想办法把 yargs 加载进来即可。而 yargs 支持浏览器 ESM 加载，所以我在页面里添加了 <script type="module" src="./yargs.js">，使用如下代码：

// 虽然 yargs 已经到 16.2，但是 16.0.4 之后的版本都有问题
import Yargs from 'https://unpkg.com/yargs@16.0.3/browser.mjs';

// 加载完成 yargs 之后，把它挂载到 window 上
window.Yargs = Yargs;

将 yargs 挂到 window 上，成为外部库。然后在 vue.config.js 里配置 externals：

module.exports = {
  chainWebpack: config => {
    config.externals.yargs = 'commonjs Yargs';
  }
}

接下来，将前面说的 utils.js 复制到本地并修改其中 parseCurlCommand 的实现，最终完成了需求。

总结一下：

  1. 使用 yargs 解析命令行请求比较方便，远比自己写方便
  2. yargs 无法配合 webpack，据说可以配合 rollup 或者 snowpack，在我的 vue-cli 项目中，需要使用一些特殊的手段加载
  3. curlconverter 也很好用，可惜不能直接用
分类
js

在任意上下文执行代码，`new Function` vs `eval()`

0. 需求及方向

我厂的 Navigator 扩展遇到一个需求：

  1. 动态生成一段 JS 在浏览器里运行
  2. 能重复生成、重复运行
  3. 能生成一段新代码，继续在上一次的环境里运行

其中（3）是新需求，（1）（2）已经比较完善地实现了。主要方案是使用 <script type="module">，这样加载的 JS 会自动执行，并且与全局环境相隔离，不会污染全局环境——这样就可以重复执行。

（3）的难点在于，上一段 JS 已经执行过了，环境也自然释放了，我要么把上一阶段 JS 的执行结果保存下来，要么把执行环境保存下来。前者需要对 Navlang 编译器做大幅度的修改；后者则有很大的实施难度。

经过研究和思考，我选择 保存环境 为攻关方向。即在上次执行结束前，在 window 上注册一个钩子函数，然后在后续追加执行的时候调用它，把后面的代码以函数的形式传进去，以便在上一次留下的环境里继续执行。

1. 问题：访问环境里的变量

添加钩子函数并不难，这样就行：

// 在上一段代码最后添加钩子函数
window.doNext = function (func) {
  func();
}

// 在新一段代码执行函数
window.doNext(function () {
  // 新生成的函数
});

这样做虽然看起来是在上一次的上下文环境中执行新的函数，但由于 JS 的闭包和作用域链特性，实际执行时，新函数并不能访问到上一次上下文的数据。换言之，目的并没有实现。

2. new Function() vs eval()

然后回到标题。所以我们必须在上一次的环境里重新构建函数，这并不困难，其实开发浏览器扩展时，因为要协调四、五个运行环境，所以把函数序列化传输，再重新构建执行非常常见。于是我直接操起 new Function()，然后失败了。

查阅 MDN，原来 new Function() 构造的函数，它的上下文会绑定在全局对象上（相当于 .call(null)），所以自然无法访问到上一次环境里的变量。

再看 eval() 的文档，似乎可行，于是换用之，果然有效。至此，问题解决。

3. 代码范例

function navlangExecuteFunction(func) {
  // 使用模版字符串构建异步函数
  eval(`(async function doNext() {
    // 捕获中间可能出现的问题
    try {
      // 执行真正的函数
      await (${func})();
      // 为兼容 node.js，mock 一个 process 来处理执行结束
      process.exit();
    } catch (e) {
       if (!e.message.startsWith('Exit code:')) {
         console.error(e);
         process.exit(1);
       }
    }
  })()`);
}
window.navlangExecuteFunction = navlangExecuteFunction;
const serializeFunction = (f) => {
  const serialized = f.toString();
  // Safari serializes async arrow functions with an invalid function keyword.
  // This needs to be removed in order for the function to be interpretable.
  const safariPrefix = 'async function ';
  if (serialized.startsWith(safariPrefix)) {
    const arrowIndex = serialized.indexOf('=>');
    const bracketIndex = serialized.indexOf('{');
    if (arrowIndex > -1 && (bracketIndex === -1 || arrowIndex < bracketIndex)) {
      return async ${serialized.slice(safariPrefix.length)};
    }
  }
  return serialized;
};

let nextStep = async function () {
  // 要执行的部分
}
nextStep = serializeFunction(nextStep);
navlangExecuteFunction(nextStep);

4. 可能带来的问题

MDN 明确建议大家 不要用 eval。理由如下：

  1. 不安全。因为 eval() 会在当前环境执行代码，意味着攻击者可能窃取任何当前环境的数据。
  2. 性能差。现代 JS 引擎会对代码进行大量优化，包括转成机器码等。eval() 会破坏这个过程，使得运行性能大大降低。

不过在我的场景下，这两个问题并不严重。一方面，被执行的追加代码都是由 Navlang 编译器生成，而不是任意第三方，它的安全性不会比其它的代码安全性低。另一方面，这个功能是帮助用户开发调试 Navlang 的，我们可以认为它大概率不会跑在性能敏感的环境里。

另外，对我厂的 Navigator 产品而言，这样的方案还会让 GC 变得比较难执行。不过一样从 便利开发 的角度出发，我觉得性价比完全 OK。

5. 总结

这个需求比较特殊，涉及到 JS 函数的很多性质，包括运行时优化的知识，还是蛮值得大家琢磨的。

另外就是所谓“尽信书不如无书”。eval() 的确存在一些问题，不能轻易使用，但是当需求摆在面前，经过充分的分析确认之后，我们该用还是要用。

分类
nodejs

使用 Node.js 驱动 FFMPEG 录屏

FFMPEG 功能非常强大，不仅能转换视频格式、压缩视频、添加字幕等，还能录制屏幕内容。使用 FFMPEG 录屏的方法很简单：

# Linux
ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 output.mp4 

# macOS
ffmpeg -f avfoundation -list_devices true -i "" 

# Windows
ffmpeg -f gdigrab -framerate 30 -offset_x 10 -offset_y 20 -video_size 640x480 -show_region 1 -i desktop output.mkv

更详细的介绍可以参考官方文档，这里不做太多摘抄。

使用 Node.js child_process 可以调用外部程序执行操作，详细的用法可以参考官方文档。大概来说，分为：

  1. exec/execFile 调用程序，当执行完成，一次性获得结果
  2. spawn 调用程序，过程中流式获得输出

我的录屏对时间点有非常高的要求，力求准确。所以我只能选择 spawn，然后通过检查日志输出得到准确的录制开始时间。

所以，我的代码大概如此：

class FfmpegRecorder {
  // 其它函数略去
  startRecording(args) {
    this.isFileReady = new Promise((resolve, reject) => {
      this._isFileReadyResolve = resolve;
      this._isFileReadyReject = reject;
    });
    this.recording = spawn(this.ffmpeg, args);
    
    this.recording.stdout.on('data', this.onStdData);
    this.recording.stderr.on('data', this.onStdErr);
  }
  stopRecording() {
    this.recording.kill('SIGINT');
    const path = resolve(process.cwd(), 'a.mp4');
    return path;
  }

  onStdData(data) {
    data = data.toString();
    this.stdout += data;
    if (this.stdout.indexOf('Output #0, mp4, to \'a.mp4\'') !== -1) {
      this._isFileReadyResolve();
      this._isFileReadyReject = null;
    }
  }
  onStdErr(data) {
    data = data.toString();
    this.stderr += data;
    if (this.stderr.indexOf('Output #0, mp4, to \'a.mp4\'') !== -1) {
      this._isFileReadyResolve();
      this._isFileReadyReject = null;
    }
  }
}

根据我在命令行里直接跑 ffmpeg 的结果，它会先初始化，然后开始录屏。录屏开始时，会输出 Output #0, mp4, to xxx.mp4 这样的日志，所以我就会反复检查 stdout 和 stderr，直到关键日志出现，然后告诉外面的程序开始录制了。

这里比较奇怪的是，日志输出应该是正常的，走 stdout 通道，结果只能从 stderr 通道获取。我为防万一，两边都留下了同样的代码。可能我对 Linux 理解不够，将来再研究一下为什么会这样吧。

上面的代码忽略了 onError 和 onExit 部分，有兴趣的同学请等我开源（公司代码）。

在 Linux，stopRecording()，即 kill('SIGINT')（相当于按下 Ctrl+C）之后，FFMPEG 会终止录屏，并且生成可以播放的视频文件。但是在 Windows，只会留下一个无法播放的文件。

通过观察命令行直接运行 ffmpeg 的结果和 node.js 保存的结果，我发现缺失了结束录制后处理视频文件的部分。实际上 FFMPEG 录屏时只会记录视频内容，录制结束后才会生成影片的meta 信息，而播放器必须读取后者才可以正常播放。所以我猜测在 Windows 下 kill('SIGINT') 会直接彻底杀死进程，而不仅仅是发送一个信号给 FFMPEG，并让它完成后续的工作。

做出判断后，我尝试用按下 q 的方式通知 FFMPEG 停止工作，并等待 5s。果然成功，于是我构建了新类，继承前面的 FfmpegRecorder，大概代码如下：

const endTag = /kb\/s:\d+.\d{2}/m;

class WindowsRecorder extend FfmpegRecorder {
  stopRecording() {
    // 向 child process 输入 `q`
    this.recording.stdin.setEncoding('utf8');
    this.recording.stdin.write('q');
    const p = new Promise((resolve, reject) => {
      this._stopResolve = resolve;
      this._stopReject = reject;
    });
    // 设置一个超时保护 15s
    setTimeout(() => {
      this._stopReject();
    }, 15E3);
    return p;
  }
  onStdData(data) {
    super.onStdData(data);
    if (this._stopResolve && endTag.test(this.stdout)) {
      const path = resolve(process.cwd(), 'a.mp4');
      this._stopResolve(path);
    }
  }
  onStdErr(data) {
    super.onStdErr(data);
    if (this._stopResolve && endTag.test(this.stderr)) {
      const path = resolve(process.cwd(), 'a.mp4');
      this._stopResolve(path);
    }
  }
}

为了功能完善，我没有选择等待固定的时间，而是继续检查日志，直到发现 endTag 标记。另外，我也留下了 15s 超时保护，避免某些暂时没遇到的问题破坏功能。

至此，功能基本稳定完成。

分类
js

函数，栈，try…catch，以及异步

前两天《记一个 `try…catch` 异步函数的坑》发出后，有同学表示对最后一句不解：

异步函数的调用可能并不在当前栈，也无法被 try…catch 在当前栈捕获到错误。

要解释清楚，一两行是不够的，于是写这篇文章展开解释一下。（这篇文章是基础向。）

函数与栈

首先来看这样一段代码：

function a() {
  // ...
}

function b() {
  // 代码1 
  a();
  // 代码2
}

function c() {
  // 代码3
  b()
  // 代码4
}

c();

它会怎么执行呢？简单来说是这样：

  1. 构建一个栈
  2. 将 c 推入栈，开始执行 代码3
  3. 将 b 推入栈，开始执行 代码1
  4. 将 a 推入栈，开始执行
  5. a 执行完，出栈
  6. 开始执行 代码 2
  7. b 执行完，出栈
  8. 开始执行 代码 4
  9. c 执行完，出栈

栈是一个先入后出的数据结构，你可以把它当成一个桶，先放进去的东西会被后放进去的东西压在下面，需要先把上层的东西，也就是后放进去的东西拿出来才能拿到先放进去的东西。

发生错误

如果代码执行中发生错误，就会在错误处中断，并逐个出栈。此时我们不仅能看到错误本身，还能看到错误发生处的完整栈信息，对 debug 很有帮助。

try...catch

异步函数出现之前，try...catch 只能捕获当前栈的错误。比如，同样是上面那段代码，稍微改动一下：

// 之前定义 a b c 的代码不变

function d() {
  throw new Error('oh my god');
}

try {
  c();
} catch (e) {
  console.error(e);
}

d();

这段代码里，c() 执行时如果有错误，可以被 try...catch 捕获到；但是 d() 位于另一个栈（或同一个栈的另一个堆叠），就无法捕获。

异步 callback & Promise

Promise 成为规范被纳入标准之前，我们处理异步操作时需要使用回调（callback）。比如侦听事件：

try {
  $('.btn').on('click', function (e) {
    console.log('hello');
  });
} catch (e) {
  console.error(e);
}

请注意：这里添加侦听函数的代码，也就是 $().on() 的部分，是在当前栈执行的；而用户点击后执行的操作，即 console.log('hello') 的部分，是在将来某个事件调用栈里执行的。所以，如果后面的函数里有问题，那么如上面所示的代码是无法捕获到错误的。

Promise 也一样。比如下面这段代码：

new Promise((resolve) => {
  // 执行完后回调
  func0(resolve);
})
  .then(() => {
    return func1();
  })
  .then(() => {
    return func2();
  });

这里的 func0，func1，func2 三个函数都是在不同调用栈里执行的，所以如果你在最外面 try...catch，无法捕获到错误。

这样会给我们编写代码带来一些困难。比如，有时候我们需要同时发起好几个网络请求，有些会成功有些会失败。我们并不知道每个失败请求对应的构造函数是怎么执行的，只能依靠请求内容进行判断，就比较麻烦。

这个问题，在异步函数中得到了解决。

异步函数 async function

这个变化主要是 await 带来的。

如前篇文章所说，在不使用 await 的情况下，try...catch 只会捕获当前调用栈的错误。对于异步函数来说，它在当前栈会返回 Promise 实例，然后就顺利结束，不会抛出任何错误。所以 try...catch 也无法捕获任何错误。

但是添加 await 之后，情况就不同了。这个时候，try...catch 会捕获整个 Promise 里所有的错误，即使函数位于不同调用栈，也可以正确捕获并且显示在一起，方便调试。

分类
js

记一个 `try…catch` 异步函数的坑

前几天遇到一个问题：想捕获异步函数的错误，但是捕获不到。我的代码大概是这样：

try {
  (async () => {
    // 一大堆异步函数
  })();
} catch (e) {
  if (e.message.startsWith('my error:') {
    // 我的错误，提示一下即可
  } else {
    // 某种不知名错误，继续抛出
    throw new Error(e.message);
  }
}

不知道读者是否发现问题，我当时是左看右看没看出来。后来只好写最小用例缩小问题范围，终于找到问题所在：异步函数前面缺少 await。于是想通了，上面的代码其实被引擎解释成：

  1. try 一个函数
  2. 这个函数的返回值是一个 Promise
  3. Promise 是正常对象，所以 try 成功
  4. 至于 Promise 里的函数是否失败，不关 try 的事，所以自然捕获不到

所以正确的写法是：

// 外面先套一层，不然不能用 await
(async () => {
  try {
    // 再加上 `await`
    await (async () => {
      // 异步函数体
    })();
  } catch (e) {
    // ....
  }
})();

这个 await 至关重要。这是异步函数的一大特性，即 try...catch 可以捕获整个异步操作前后所有栈的异常，而不仅仅是当前函数的异常。同时我们也要注意，异步函数的调用可能并不在当前栈，也无法被 try...catch 在当前栈捕获到错误。

分类
js

使用 File System Access API 在浏览器里操作本地文件

如《Webpack 5 发布，Chrome 86 开始支持本地文件系统》一文所述，Chrome 86 开始，浏览器正式支持操作本地文件。接下来结合最近的使用，分享下用法。

0. 准备工作：理清概念

首先，我们要先搞清楚一些概念。实际上，让浏览器操作本地文件是开发者一直在努力并且不停在探索的方向，所以历史上有很多方案，存在很多类似但其实并不一样的 API，大家在学习的时候一定要搞清楚，不要弄混。

最早登场的是 File API，代表功能是 FileReader（参考：《使用 Promise 封装 FileReader》）。这个 API 最大的进步在于，我们可以在浏览器里读取和操作二进制文件，然后通过 <a download="file.ext"> 下载到本地。如此，浏览器作为工具平台的价值大大提高。

接下来，激进的 Google Chrome 提出并实现了 File System API。这个 API 试图在浏览器里创建一个独立的文件环境，让开发者可以在里面任意操作文件和目录，如果能做好，那么是一个非常好的抽象。可惜步子不仅大、而且偏，最终失败。我总结原因有二：

  • 一方面“独立的文件环境”，即无法操作系统本地文件，那么其实没什么价值……
  • 另外，当时浏览器的其它限制没有突破——没有包管理、没有 babel、甚至没有 Promise，IE 仍然大量存在，开发难度极大。

所以最终这套方案死得悄无声息。《HTML5的File API应用》，这篇博客可能是为数不多的中文分享。

接下来是 Chrome Extension、Chrome App、Chrome OS 里的 File （System） API。这几个产品都是 Google 私有，不用考虑其他浏览器厂商，所以可以放开手脚随便搞。这里大家需要注意的是，因为 Google 的产品策略一向是说关就关，所以大家要留心常看文档，别学了一半 API 没了，比如：Extension 的 chrome.fileSystem 就已经弃用了。

最后，也就是今天的主角，File System Access API。这套方案应该是未来的主角。它提供了比较稳妥的本地文件交互模式，即保证了实用价值，又保障了用户的数据安全，明显是前辈 File System API 的继任者。

它的设计思路也不复杂：

  1. 要求用户手动选择文件或者目录，以获取文件或目录的控制权限
  2. 选择文件或目录后，获取到 FileHandle，后续的操作经由它来进行
  3. FileHandle 是 serializable 对象，所以可以通过序列化和反序列化实现跨 session 的存储（即刷新后还能用）

好，下面看代码。

1. 读取本地文件

这段代码可以比较完整的演示 window.showOpenFilePicker API 的用法：

// 使用 `try...catch` 可以捕获用户取消选择时抛出的错误，如果你对错误不在意，不捕获也行
try {
  const [handle] = await showOpenFilePicker({
    multiple: false, // 只选择一个文件
    types: [
      {
        description: 'Navlang Files',
        accept: {
          'text/x-navlang': '.nav',
        },
      },
    ],
    excludeAcceptAllOption: true,
  });
} catch (e) {
  if (e.message.indexOf('The user aborted a request') === -1) {
    console.error(e);
    return;
  }
}

// 如果没有选择文件，就不需要继续执行了
if (!handle) {
  return;
}

// 这里的 options 用来声明对文件的权限，能否写入
const options = {
  writable: true,
  mode: 'readwrite',
};
// 然后向用户要求权限
if ((await handle.queryPermission(options)) !== 'granted'
  && (await handle.requestPermission(options)) !== 'granted') {
  alert('Please grant permissions to read & write this file.');
  return;
}

// 前面获取的是 FileHandle，需要转换 File 才能用
const file = await handle.getFile();
// 接下来，`file` 就是普通 File 实例，你想怎么处理都可以，比如，获取文本内容
const code = await file.text();

2. 保存本地文件

前面说过，FileHandle 可以序列化，也即可以进行持久化存储。所以我们只需要把对应的 FileHandle 存下来，然后保存即可。

if (data.file) {
  const writable = await data.file.createWritable();
  await writable.write(data.code);
  await writable.close();
}

如果之前没有获取过 FileHandle，则可以通过 window.showSaveFilePicker 来获取：

try {
  const file = await showSaveFilePicker(filePickerOptions);
} catch (e) {
  if (e.message.indexOf('The user aborted a request.') === -1) {
    console.error(e);
  }
  return;
}
// 然后接前面的代码
const writable = await file.createWritable();
await writable.write(data.code);
await writable.close();

这个功能现在有一点小问题，不知道是不是 Chrome 实现不太稳定，如果你打开开发者工具，然后钩上“Pause on caught exceptions”，那么保存时会暂停数次，并提示错误。不用理会，直接继续执行即可。我猜测这个过程本来应该由浏览器自动捕获并重试，直到超时保护或者写入成功，但是现在会错误地抛出来。

3. 总结

File System Access API 不仅可以操作文件，还可以操作目录，操作目录的方式和文件相仿，我就不详细举例了，大家可以看下后面的参考链接，或者等我用到目录、踩了坑再来分享。

这个 API 对前端来说意义不小。有了这个功能，Web 可以提供更完整的功能链路，从打开、到编辑、到保存，一套到底。虽然目前只有 Chrome 支持，但还是建议大家尽快把它用起来。

参考链接：

分类
js

JavaScript 获取正则表达式中子表达式的个数

正如标题所示，我厂有这么一个需求。我不会，老板鄙视我后丢过来一个链接：stackoverflow: Count the capture groups in a qr regex?

看不太懂 Perl，但是这个思路很棒。所以改写成 JS 版，并记录如下：

function countCapturingGroups(r){
  r = new RegExp(`|${r.source}`);
  const result = ''.match(r);
  return result.length - 1;
}

const result = countCapturingGroups(/fo(.)b(..)/);
console.log(result); // 2

它的原理是这样的。构建一个新正则，包含两部分：空字符和目标正则。空字符正则会完成与目标字符串的匹配，保证有结果（不然的话就会返回 null。接下来 | 会保证后面的正则也是有效的，可以生成包含子表达式结果的数组。

我们知道，结果是个类数组，结构大约是：

  1. 全部匹配字符串
  2. 0～N 子表达式结果
  3. 其它一些属性

所以用其长度 – 1 就能获得子表达式的个数。从功耗上来说，这个应该是很节省了。