babel 背后的东西之 compact-table

一个问题

给定 .browserslistrc 配置，Browserslist 会使用 caniuse-lite 查询出 target browsers，这里直接给他一个明确的 target

chrome >= 49

然后根据 caniuse 显示，chrome49 是支持解构赋值的

所以，这段代码会被 babel 转译吗？点击调试

js 复制代码

var [a, b] = [];

我们发现，虽然 chrome 49 支持解构赋值，但是仍被转译了。将版本提升为 chrome >= 51，才能保持原样，这是为什么呢？

转译结果：

js 复制代码

var _ref = [];
a = _ref[0];
b = _ref[1];
_ref;

原来 babel 制作了比 caniuse 更精确的兼容数据集 compact-table，就像本例中的 destructuring 将以最坏的转换情况为目标。

那最坏的情况是啥呢？通过解构赋值的测试用例可以看出来，等到 chrome 51 才完全支持所有 case。

js 复制代码

{
  name: 'destructuring, assignment',
  category: 'syntax',
  significance: 'medium',
  spec: 'http: //www.ecma-international.org/ecma-262/6.0/#sec-destructuring-assignment',
  mdn: 'https: //developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment',
  // subsets 下包含许多测试用例
  subsets: [
    {
          name: 'iterator closing',
          exec: function () { /*
             var closed = false;
             var iter = global.__createIterableObject([1, 2, 3], {
               'return': function(){ closed = true; return {}; }
             });
             var a,b;
             [a, b] = iter;
             return closed;
         */},
         res: {
             // 但是这条用例 chrome 51 才支持
             chrome51: true,
             ie11: false,
          }
    },
    {
        res: {
             // 这条 49 就支持了
             chrome49: true,
             ie11: false,
          }
    },
    // ...等等，其它用例
  ]
}

具体到本例，人们通常不会解构数组字面，而是解构标识符。

虽然 Babel 可以用一些复杂的方法进行推理，但这需要大量工作，而且会影响性能，因此会有一些次优输出，有一些特别常见的实际用例会更使用精细的策略。

因此遇到这种情况不要吃惊，只是 babel 内部采用了不同的转译策略而已。

兼容性数据源

目前已知的数据源有三种，有重合的部分，但面向不同的领域，来简单看下他们的区别：

@mdn/browser-compat-data

以表格的形式展示了平台兼容，也有很多工具使用了这个数据源，包括 caniuse 🐶

Add-ons Linter 检查附加组件所列支持的Firefox版本是否确实支持附加组件使用的API。
CanIUse Embed 由于caniuse中包含了MDN BCD数据，这个嵌入工具允许将BCD数据嵌入到任何项目中。
Compat Report Firefox插件，显示开发者工具中当前网站的兼容性数据。
compat-tester 用于扫描本地文档以查找兼容性问题。
Visual Studio Code 在代码完成弹出窗口中显示兼容性信息。
webhint.io 提示检查您的CSS、HTML和JavaScript是否具有不推荐使用或不被广泛支持的功能。
WebStorm 允许您检查所使用的所有CSS属性在目标浏览器版本中是否受支持。

caniuse-db 还有存在的必要吗？

caniuse-db 是一个独立的开源项目，它提供了 Can I Use 网站的数据作为一个可查询的数据库。尽管 Can I Use 网站已经开始使用 MDN 的数据源，但 caniuse-db 仍然有其独特的用途。

caniuse-db 可以用于构建自定义的工具和服务，（例如，谷歌的 "Caniuse Embed"，可以在网页上嵌入 Can I Use 网站的浏览器兼容性数据。）或者根据公司业务需要兼容的用户群打造自己的 caniuse-xxx 将其集成到开发环境或持续集成流程中。

此外，caniuse-lite 在其基础上聚合简化，并提供了更快捷的 API 获取平台兼容信息，browserslist 就构筑在其之上，而我们常用的工具又基于 browserslist 构建，比如：

Baseline 的 web-features

在理解这个问题过程中，意外发现的另一个 Google 推出的新标准。

愿景比较宏大，带动 core browser（Firefox, Chrome, Edge and Safari 的最近两个主要版本）统一实现新特性，发布新版本，最终消除平台兼容（应该是不管小厂商的死活了，耳熟吗😋）。

定义了一个关键指标 Interop(互用性)，应该是某特性在各平台都能用的 case 占比，分数越高，代表平台兼容越好。

读懂 Baseline 标记 如下图：

在不完全兼容时受限 Limited available
在全兼容时 Newly available
全兼容30个月后 Widely available（因为要预留2.5年给用户升级，你最新版支持了但是用户不升级也么用啊是不是）

如果你要问用户死活不升级怎么办？人家厂商都能团结，说服老板，酌情放弃这种不与时俱进的用户吧 😂

以后可能会在越来越多的地方看到这种标志，像是某个 github 仓库，MDN 和 web.dev，认识就好了。

内容比较多，有兴趣的自行了解哈，这里只做粗略的介绍，相关内容都贴出来了，按照这个顺序阅读就行。

Baseline 愿景
MDN 中介绍的标准定义
Baseline 推进进度，重要的工作领域，正经干事儿值得学习！

酱~ 拜~