关于javascript:Babel成员更推荐的新配置方法你知道吗

在上一篇文章——Babel 配置不要再“复制粘贴”了，带你本人配一个 Babel 中，咱们晓得：

如果咱们开发的我的项目是 应用程序 ，或者 大型的我的项目 ，咱们能够利用@babel/preset-env 的配置性能，对 ES6+ API 进行 全局垫平。所以咱们个别这么配置：

// babel.config.js
const presets = [
    [
        '@babel/preset-env',
        {
            modules: false,
            useBuiltIns: 'entry', // 或者 useBuiltIns: 'usage'
            corejs: {version: '3.27.2', proposals: true}
        }
    ]
];

const plugins = ['@babel/plugin-transform-runtime']
module.exports = {plugins, presets};

如果咱们是想开发一个 第三方库 ，咱们能够利用@babel/plugin-transform-runtime 的配置性能，对 ES6+ API 进行 部分垫平，而不影响全局的环境。所以咱们个别这么配置：

// babel.confing.js
const presets = [
    [
        '@babel/preset-env',
        {modules: false}
    ]
];
const plugins = [
    [
        '@babel/plugin-transform-runtime',
        {
            corejs: {
                version: 3,
                proposals: true
            }
        }
    ]
];
module.exports = {plugins, presets};

以上是咱们平时对于 Babel 见得最多的配置办法。然而这么配：

有时咱们要关注 @babel/preset-env 配置，有时又要关注 @babel/plugin-transform-runtime 配置，并且配置项那么多，这种配置办法其实还是挺繁琐的
Babel内容知识点原本就非常多，如果咱们自身对 Babel 就“懵懵懂懂”的话，这无疑会很容易加深咱们对 Babel 的纳闷，让咱们感觉更懵圈。

但其实还有一种新的 Babel 配置办法，它既能实现以上的配置，配置起来更加简洁，并且性能比下面的配置还要弱小，同时它也是 Babel 成员更举荐的配法。

学习是个循序渐进的过程，所以这篇文章接下来会带大家：

大抵理解这种新的配置办法一些背景故事，为什么诞生
理解这种新的配置办法如何配置
答疑以前咱们学习对于 Babel 配置的疑难
目前新配置办法存在的问题

PS：

为了大家浏览不便，每个模块绝对独立，大家能够筛选本人喜爱的模块浏览
想间接看怎么用的敌人，能够间接跳到 应用模块

本着写文章注重质量跟严谨性的态度，也为了大家能够更释怀的应用这个新的配置办法，因而为了这个新的配置办法，我也浏览了大量对于 Babel 的文章，也在 github 上提了一些 issues 向Babel的开发成员求证学习。

Babel的开发成员也非常敌对，也回应了我说：

新的配置办法文档由两局部组成
目前这个新的配置办法是他们更举荐的配法，齐全能够用来替换 @babel/preset-env、@babel/plugin-transform-runtime 这两个包的配置性能，达到一样的配置成果
新的配置办法有一个对应的包，这个包在 @babel/preset-env 外部也稳固应用了

具体的能够看看我在 Babel 提的issues：

issues链接：

Some of the proposed methods do not seem to have been realised
The “useBuiltIns: usage” mode and “usage-global” mode have different output codes

目前 Babel 官网并没有对这个新的配置办法有更具体的阐明，置信后续这个办法可能也会成为 Babel 配置的支流。因而，大家学习到这种办法，也算是对 Babel 的一种拓展，然而最重要的是 咱们能够利用这个新的办法，更不便的配置咱们的Babel

毕竟失去了官网 Babel 开发成员的答复与必定，所以 这个新的配置办法，大家是能够释怀“食用”的。

在文章开始之前，如果你对 Babel 曾经有一个零碎的理解，也明确 Babel 怎么配置，那么这篇文章会让你学习到 Babel 一种更弱小的新的配置办法；

然而如果你才刚接触 Babel，或者对Babel 似懂非懂，还处于迷迷糊糊的状态，那我还是强烈建议你先浏览之前的两篇文章（尤其是第二篇）：

想弄懂 Babel？你必须得先弄清楚这几个包

它次要介绍了咱们平时我的项目中应用 Babel 的几个包，并答疑了咱们学习 Babel 时的一些纳闷，让咱们对 Babel 有个零碎大抵的了解。
Babel 配置不要再“复制粘贴”了，带你本人配一个 Babel

它次要解说了咱们平时我的项目中应用 Babel 配置的一些原理，还有应该如何更好的配置。

咱们把前言提到的以前的配置办法统称为：旧的配置办法
咱们把这篇文章讲的新的配置办法统称为：新的配置办法
咱们把通过引入 core-js 的某个模块 （或其余polyfill），来实现旧版本浏览器不反对的某个 ES6+ API 的过程，叫做垫平
以后 @babel/core 最新版本是：7.21.8
以后 @babel/preset-env 最新版本是：7.21.5

通过前两篇文章，咱们晓得：

咱们能够把所有这种寄存了 ES6+ API 的办法与实现的汇合 叫做polyfill
core-js只是一种polyfill，还有很多其余polyfill。例如：promise-polyfill、proxy-polyfill、es-shims 等
如果咱们是用 core-js 这个 polyfill 来垫平的话，应该用 core-js 的最新版本来垫平，越新的版本，蕴含的 ES6+ API 实现就越多

OK，咱们接着往下看。

Babel 我的项目中有这样一个包——babel-polyfills

留神：大家看清楚，不是 @babel/polyfill 这个包，它跟 @babel/polyfill 是两码事
不理解 @babel/polyfill 这个包的敌人，之前的文章——想弄懂 Babel？你必须得先弄清楚这几个包中有专门的阐明

它的呈现，有一段故事，次要是为了解决以下问题（更具体的故事，能够看看这里）：

以前 @babel/preset-env 这个包的 targets 选项，不能与 @babel/plugin-transform-runtime 这个包共享，@babel/plugin-transform-runtime设置不了targets
下面咱们说过，core-js只是一种 polyfill，还有很多其余polyfill。所以有可能不是所有人都想用core-js 这个polyfill
为了更好的用户体验，旧的配置办法太繁琐

对于问题一，咱们再做一些补充：

在旧的配置办法中，如果咱们想开发一个第三方库的话，咱们是利用 @babel/plugin-transform-runtime 的配置办法来开发的（因为配置@babel/plugin-transform-runtime，会以部分形式垫平ES6+ API）然而在以前，这会导致库的体积非常宏大。

这是因为之前 @babel/plugin-transform-runtime（或者别的插件）不能辨认到咱们要兼容的指标环境（即targets，或者是packjson 的browserslist），所以会把咱们代码中应用到的 ES6+ API 都垫平，即便咱们指标环境反对这些ES6+ API。

然而在咱们后续学习 Babel 配置的时候，咱们会发现 @babel/plugin-transform-runtime（或者别的插件）是能够辨认targets 的，不能辨认 targets 这个问题并不能很好的领会到。这就让咱们非常纳闷。

如果你在学习 Babel 过程中对这个问题有过纳闷的话，能够去 相干答疑模块 查看起因

babel-polyfills 能够看作是一个总的资源包，它寄存了三种用于垫平 ES6+ API 的插件包：

babel-plugin-polyfill-corejs2：用 core-js 2+ 版本来垫平ES6+ API
babel-plugin-polyfill-corejs3：用 core-js 3+ 版本来垫平ES6+ API
babel-plugin-polyfill-es-shims：用 es-shims 这个 polyfill 来垫平 ES6+ API（为了解决上述问题二，不是每人都想用core-js 这个 polyfill 来垫平）

OK，从下面对于三个包的形容，咱们能够分明的晓得它们的作用别离是什么。

咱们重点关注 babel-plugin-polyfill-corejs3 这个包，因为：

Babel举荐的 polyfill 是core-js，目前 core-js 最新版本曾经是 3+ 的版本了
我本人也试了一下用 es-shims 来垫平 ES6+ API，然而并没有core-js 那么不便（大家也能够本人试试）
通过 babel-plugin-polyfill-corejs3 这个包的名字，以此类推，后续如果 core-js 降级到 4+ 版本的话，应该会再出 babel-plugin-polyfill-corejs4 这个包等
babel-plugin-polyfill-corejs3这个包也曾经在 @babel/preset-env 外部应用了（相干链接）
官网所说的新的配置办法，也是基于这个包

在解说如何应用新配置办法前，咱们先大抵回顾剖析一下旧的配置办法是怎么配置，不便后续咱们更好的了解如何应用。

在这里只是大略阐明，更具体的剖析，倡议大家去浏览上一篇文章——Babel 配置不要再“复制粘贴”了，带你本人配一个 Babel

抽象的来说，平时咱们做开发，不是开发大型项目、应用程序，就是开发第三方库。
而这些都是须要配置 Babel 来垫平咱们不反对 ES6 API 的指标环境的。所以在这里，咱们能够抽象的把垫平形式看成两大形式：

全局形式垫平 —— 实用于大型项目或者应用程序
部分形式垫平 —— 实用于开发第三方库

全局的形式 垫平 ES6+ API，则都是利用@babel/preset-env 的配置性能，它有两种配法（配置代码可见 前言模块）：

useBuiltIns: 'entry'
useBuiltIns: 'usage'

`useBuiltIns: 'entry'`

这种形式比较简单粗犷。它须要咱们在入口文件手动 import 所有或者某块 polyfill，这样Babel 会引入咱们指标环境（targets）不反对的 polyfill 模块。

这种形式能够防止一些奇奇怪怪的问题，但某种程度来说，也会增大咱们打包后的体积。

`useBuiltIns: 'usage'`

这种形式则不须要咱们手动引入 polyfill。Babel 会依据咱们 以后代码中用到的 ES6+ API，并判断以后的targets 支不反对咱们用到的这个 ES6+ API，不反对的话则 主动导入这个 ES6+ API 对应的polyfill。

这种形式尽管比拟不便，然而它是依据咱们 以后代码中 用到的 ES6+ API 来做判断的。所以如果咱们应用的第三方库中，有用到咱们以后 targets 不反对的 ES6+ API，然而咱们本人的代码又没有用到这个API 的话，那就会出问题了。

具体问题能够看看这个例子 use-third-party-library-problem

如果咱们开发的是一个第三方库，咱们当然要把咱们的代码与使用者的代码做隔离，所以咱们是须要以部分形式来垫平 ES6+ API 的。

而以 部分的形式 垫平 ES6+ API，则是利用@babel/plugin-transform-runtime 的配置性能（配置代码见 前言模块）。

它会判断咱们想要兼容的指标环境（很久以前判断不了），并依据 咱们代码中应用到的 ES6+ API，最初再将polyfill 以局部变量的形式 进行垫平。

下面咱们的大略说了：

新的配置办法诞生的一些历史
新的配置办法是基于 babel-plugin-polyfill-corejs3 这个插件包
回顾了一下旧的配置办法

咱们先来看看新的配置办法是怎么配置的，先有个大略印象：

const presets = ['@babel/preset-env',]
const plugins = [
    [
        'babel-plugin-polyfill-corejs3',
        {
            method: "entry-global", // usage-global || usage-pure
            version: '3.20.2',
            proposals: true
        }
    ],
    '@babel/plugin-transform-runtime',
];

咱们能够跟 前言模块 旧的配置办法比照一下，这几乎简便的不能再简便

OK，接下来咱们具体看看到底怎么配置。

在提了 issues 询问了对于文档的配置项，并失去 Babel 贡献者的答复后，能够晓得 babel-plugin-polyfill-corejs3 这个包有以下配置项：

method（重点）
version
proposals
targets
ignoreBrowserslistConfig
configPath
debug
include
exclude
shouldInjectPolyfill
absoluteImports
missingDependencies

大家不要被那么多配置项吓到，平时用到的就前三个 （targets 也会解说一下），其余的在咱们须要用到的时候在学（太累了，能不学的尽量不学）。

`method`

这个配置项就是用来 管制咱们垫平 ES6+ API 的形式。

它一共有三个值：

entry-global
usage-global
usage-pure

咱们能够这么拆解，这样更不便咱们记忆应用：

咱们能够把 - 后面当做第一局部，它指的是管制 polyfill 引入的形式。是手动在入口引入，还是依据 咱们代码中用到的 ES6+ API 主动引入
咱们能够把 - 后面当做第二局部，它指的是 polyfill 是以全局还是部分的形式垫平
咱们也会发现它们的值，跟旧的配置办法有所对应

`entry-global`

剖析

咱们能够把值拆成两局部来看：entry跟global。从这两个非常语义化的词咱们能够晓得：

entry：入口。它指的是咱们要在入口引入咱们的polyfill
global：全局。指的是，polyfill 以全局的形式 垫平

咱们以 ie 11 为指标浏览器，用 entry-global 这个例子，来感受一下它跟旧的配置办法有没有什么区别：

依据下面的后果，咱们会发现：

应用了新旧两种配置办法，发现编译后，注入的 polyfill 都是234 行
编译后的文件都是截然不同的。

总结

method: 'entry-global'相当于旧的配置办法中的useBuiltIns: 'entry'

留神

文档说 version 配置项，只有在应用 usage-global 或者 usage-pure 时才有用。

然而我试了一下，在 entry-global 也是能够应用 version 的，所以我有提 issues，目前没有回答

`usage-global`

剖析

咱们能够把值拆成两局部来看：entry跟global。从这两个非常语义化的词咱们能够晓得：

usage：用法。它指的是 咱们代码中用到 的ES6+ API
global：全局。指的是polyfill 以全局的形式 垫平

咱们以 ie 11 为指标浏览器，应用两个ES6+ API：

array-grouping：它是个能够让数组分组更不便的 API，目前它处于stage-3 阶段
Promise：咱们最相熟的异步API

并且用 usage-global 这个例子来感受一下它跟旧的配置办法有没有什么区别：

依据下面的后果，咱们会发现：

在 ie 11 中，只垫平了咱们用到的那两个ES6+ API
编译后的文件都是截然不同的

总结

method: 'usage-global'相当于旧配置办法中的useBuiltIns: 'usage'

`usage-pure`

剖析

咱们能够把值拆成两局部来看：usage跟pure。从这两个非常语义化的词咱们能够晓得：

usage：用法。它指的是 咱们代码中用到 的ES6+ API
pure：污浊。指的是polyfill 以部分的形式 垫平，并不会净化全局，因而它是污浊的

咱们以 ie 11 为指标浏览器，还是应用下面两个ES6+ API：

array-grouping：它是个能够让数组分组更不便的 API，目前它处于stage-3 阶段
Promise：咱们最相熟的异步API

并且用 usage-pure 这个例子来感受一下它跟旧的配置办法有没有什么区别：

依据下面的后果，咱们会发现：

旧的配置办法，是 无奈垫平一些提案阶段的 ES6+ API 的。因为旧的配置设置的 version 只能是 3，3 代表的是 core-js@3.0.0 的版本，那它必定不能垫平一些比拟新的提案

总结

method: 'usage-pure'相当于旧配置办法中，配置 @babel/plugin-transform-runtime 的形式
新的配置办法比旧的配置办法 更简便，更强

留神

咱们须要npm i core-js-pure -S，因为：

以 全局变量形式 垫平是基于 core-js 这个包
以 局部变量形式 垫平是基于 core-js-pure 这个包

文档没有说，不装置相干依赖的话，会报错

`targets`

它指的是咱们垫平 ES6+ API 的指标环境。

这个配置项设计的初衷是为了解决 历史问题模块 提到的第一个问题：

利用 @babel/plugin-transform-runtime 配置开发第三方库时，以前 @babel/plugin-transform-runtime 是不能辨认 targets 的，这会导致库的体积很大。

所以有了 targets 这个配置项，会帮咱们大大的缩小体积。

咱们进行以下步骤：

装置 < 7.13.0 版本的Babel（@babel/core@7.12.0）
应用 Promise、Array.includes 两个ES6+ API

而后用 target-configuration 这个案例，感受一下以前 targets 这个配置项在以前是怎么发挥作用的。

咱们先看第一个后果（不配置targets，但设置了browserslist: ["chrome 100"]）：

依照最新版本的 Babel 来说，设置了 browserslist: ["chrome 100"]，咱们的代码只会垫平chrome 100 不反对的 ES6+ API。
然而当初咱们装置的是比拟旧的版本（7.12.0），依据上图咱们会发现，即便咱们设置的指标浏览器（chrome 100）是反对这些 API 的，但 Babel 仍旧垫平了这些 API，所以咱们的库会变得非常大，这是 历史问题模块 问题一很好的体现。

咱们再来看第二个后果（配置targets）:

咱们会发现，因为咱们新的配置办法设置了 targets，所以此时Babel 不会垫平 targets 反对的 API，这大大节约了咱们库的体积。这就很好的解决了 历史问题模块 的问题一。

在 Babel >= 7.13.0 的版本当前，在 Babel 配置文件新增了一个顶级的 targets，并且Babel 也反对辨认 browserslist
所以在新的配置办法里 targets 这个配置项就不怎么用了。

`version`

它指的是咱们提供 polyfill 的汇合包（像 core-js，外面寄存了很多polyfll 汇合）的版本。

因为咱们是应用 babel-plugin-polyfill-corejs3 这个包

全局形式垫平的话，是用 core-js 这个包来垫平，所以 version 指的是 core-js 版本
部分形式垫平的话，是用 core-js-pure 这个包来垫平的，所以 version 指的就是 core-js-pure 的版本

咱们 version 当然是要越高越好，这样蕴含的 polyfill 才会更多

参考文章：babel-plugin-polyfill-corejs3

`proposals`

它指的是，咱们是否开启编译处于提案阶段的 ES6+ API，那咱们当然是要开启的，这个值只有在method: 'usage-global' 或者 method: 'usage-pure' 时有用

在 历史问题 模块中，咱们有说到：

在后续学习的过程中，咱们发现 @babel/plugin-transform-runtime（或者别的插件）是能够辨认targets 的，但有些文章说不能辨认 ，这加深了咱们对Babel 的纳闷。

其实这所有的起因还是因为：咱们后续学习 Babel 的时候，Babel曾经进行了很多更新，咱们以后学习 Babel 时候的版本，跟以前那会的 Babel 版本曾经不一样了，因而问题不能很好的体现。

所以当前咱们学习 Babel 肯定要留神好版本号，这就是为什么对于 Babel 的文章，我都会写上 Babel 版本备注的起因。

OK，咱们接着往下看。

在 Babel 公布 7.13.0 版本时候有一些记录说到：

减少了顶层的targets
反对辨认 browserslist 外面环境

这就是为什么后续咱们学习 Babel，有些文章说@babel/plugin-transform-runtime 不能辨认 targets，然而咱们照着例子敲，后果却截然相同的起因。 因为咱们学习的时候，Babel版本可能曾经 >= 7.13.0，并且可能配置了browserslist 或者 targets，这时@babel/plugin-transform-runtime 曾经能够辨认 targets 了

为了更好的感触这个问题，咱们用 transform-runtime-targets-problem 这个案例来感受一下：

咱们装置一个 < 7.13.0 版本（7.12.0）
配置 browerslist 为chrome 100
应用 Array 的includes办法（chrome 100曾经反对）
应用 Promise（chrome 100 曾经反对）

咱们来看看后果：

chrome 100曾经反对了 Array 的includes跟Promise，但仍旧被垫平了。

因为咱们装置的Babel < 7.13.0，此时还没实现插件能辨认targets

依据这个案例，置信大家应该对 Babel 的纳闷又缩小了一些了。

咱们在 回顾模块 有说到，应用局部变量的形式垫平 ES6+ API，它会依据 咱们代码中应用到的 ES6+ API，最初再以 局部变量的形式 进行垫平。

Babel在进行编译的时候，是会注入很多 辅助函数 的，那么会有这样一种状况：

咱们的代码中没有应用到 Promise，然而辅助函数中用到了Promise，那这时咱们的代码是不会垫平Promise 的，因为咱们本人的代码中没有用到Promise，那这是不是会导致代码报错呢？

这是个很事实的问题，咱们用 usage-pure-problem 这个例子来看看新旧配置办法，对于这块问题有没有解决。

咱们先看看旧的配置办法的体现：

咱们来剖析一下这个编译过程：

咱们的源码外面只应用了async
Babel从 @babel/runtime-corejs3 这个包里引入了辅助函数
ie 11失常运行

咱们先看看新的配置办法的体现：

咱们来剖析一下这个编译过程：

咱们的源码外面只应用了async
Babel从 @babel/runtime 这个包里引入了辅助函数
ie 11报错

咱们来剖析一下，为什么新的配置办法在 ie 11 会报 Promise 的错。

咱们本人的源码中没有用到 Promise，所以这个Promise 必定来自辅助函数。咱们能够看到新旧配置办法，引入的辅助函数是来自不同的包：

旧的配置办法辅助函数来自：@babel/runtime-corejs3
新的配置办法辅助函数来自：@babel/runtime

通过一番查问，咱们发现：

旧的配置办法，Promise来自辅助函数的这个包：@babel/runtime-corejs3/helpers/asyncToGenerator
新的配置办法，Promise来自辅助函数的这个包：@babel/runtime/helpers/asyncToGenerator

咱们比照一下这两个包有什么不一样的：

通过剖析比照，咱们能够很分明的晓得：

旧的配置办法，引入的辅助函数都是局部变量形式的存在的，所以咱们不须要放心咱们辅助函数里的 ES6+ API 没有被垫平；而新的配置办法则不是。

所以，按目前状况来说，如果咱们想 开发第三方库，并且想用新的配置办法来代替旧的配置办法：

咱们要留神，这可能会导致在旧的浏览器运行不起来的状况。因为在新的配置办法中，辅助函数可能存在ES6+ API，它不会被垫平。
新的配置办法目前来说，实用于咱们要兼容的一些比拟新的指标环境

以上问题当然也有别的开发者发现了，目前这个问题曾经解决了，预计后续的版本会修复。在修复当前，开发第三方库，咱们就能够完完全全的用新的配置办法代替旧的配置办法了。

参考文章：

@babel/plugin-transform-runtime not transform Object.hasOwn correctly
ownKeys, _objectSpread not imported from @babel/runtime helpers
Add back moduleName option to @babel/plugin-transform-runtime
Allow polyfill providers to specify custom @babel/runtime pkg

OK，最初咱们总结一下新的配置办法：

如果咱们开发的我的项目是 应用程序 ，或者 大型的我的项目，那咱们能够这么配置：

// Babel 配置
const presets = [
    [
        '@babel/preset-env',
        {modules: false}
    ]
];
const plugins = [
    '@babel/plugin-transform-runtime',
    [
        'babel-plugin-polyfill-corejs3',
        {
            method: "entry-global", // 或者 method: "usage-global"
            version: '3.20.2',
            proposals: true
        }
    ]
];
module.exports = {plugins, presets};

// package.json
{
    ...,
    // 设置指标环境
    "browserslist": ["ie 11"]
}

// 入口文件
// ---- useBuiltIns: 'entry' 时，须要引入以下 ----
// 垫平全副 ES6+ 稳定版 API
import 'core-js/stable'; 
// ---- 或者 -----
// 垫平所有 ES6+ API，包含提案阶段
import 'core-js';

如果咱们是想开发一个 第三方库，咱们能够这么配置：

// Babel 配置
const presets = [
    [
        '@babel/preset-env',
        {modules: false}
    ]
];
const plugins = [
    '@babel/plugin-transform-runtime',
    [
        'babel-plugin-polyfill-corejs3',
        {
            method: "usage-pure",
            version: '3.20.2',
            proposals: true
        }
    ]
];
module.exports = {plugins, presets};

// package.json
{
    ...,
    // 设置指标环境
    "browserslist": ["ie 11"]
}

// 入口文件
const Method = {wait(delay) {return new Promise(resolve => setTimeout(() => resolve(), delay);
    }
}
...

咱们能够比照一下旧的配置办法，新的配置办法更加的简洁，更加的弱小。咱们相当于:

只利用 @babel/preset-env 进行 ES6+ 语法编译
利用 babel-plugin-polyfill-corejs3 来垫平ES6+ API
咱们基本不须要在 @babel/preset-env 跟@babel/plugin-transform-runtime这两个包切来切去；咱们只须要关注 babel-plugin-polyfill-corejs3 如何配置就能够了

另外：

如果想用新的配置办法用来 开发第三方库 ，须要留神一些旧版本的浏览器可能会报错，因为它不会垫平辅助函数外面的ES6+ API。所以想开发第三方库， 新的配置办法更适宜用于一些比拟新的浏览器
如果想用新的配置办法用来 开发利用我的项目或大型项目 ，用全局形式垫平ES6+ API，那么 新的配置办法齐全能够间接代替旧的配置办法

文章波及到的例子，曾经上传 Github，感觉有帮忙的话，欢送 Star 或者 Fork 学习（写文章真的很辛苦）。

如果读完这篇文章的你，感觉真的有帮忙到，欢送点赞珍藏 ；如果有异同点， 欢送在评论区探讨。

关于javascript:Babel成员更推荐的新配置方法你知道吗

前言

特地阐明

筹备

备注

历史问题

补充

构造

回顾

全局形式垫平

`useBuiltIns: 'entry'`

`useBuiltIns: 'usage'`

部分形式垫平

应用

配置项

`method`

`entry-global`

剖析

总结

留神

`usage-global`

剖析

总结

`usage-pure`

剖析

总结

留神

`targets`

`version`

`proposals`

相干答疑

新配置办法目前存在的问题

旧的配置办法

新的配置办法

剖析

总结

总结

最初