前端工程化：你所需要知道的最新的babel兼容性实现方案

最新推荐文章于 2024-04-12 10:52:06 发布
最新推荐文章于 2024-04-12 10:52:06 发布
阅读量444 收藏
点赞数
文章标签： 编程语言 java python 人工智能 js
原文链接：https://juejin.cn/post/6976501655302832159
版权

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

网上关于babel兼容性实现方案的剖析有很多，但大部分剖析案例已经不适用于现在的babel生态。作者在最新babel7的基础上，不断编译验证，发现跟网上大部分剖析案例还是有很大不同。所以，输出本文的目的是为了给大家带来最新的babel兼容性方案剖析，让大家对babel的兼容性处理机制有更透彻的了解。

1. core-js

友情提醒：如果不了解core-js是什么的同学，请务必先阅读这一章节，这样有助于后面章节的理解！

core-js[1]是JavaScript的模块化标准库，包括了ECMAScript到2021年的新api的向后兼容实现。它和babel高度集成，是babel解决新特性在浏览器中兼容问题的核心依赖。

目前core-js的版本是3.x，与core-js@2相比不仅在本身的架构上有重大调整，还对babel中的一些插件有重大影响。

1.1 core-js@2

core-js@2被@babel/polyfill、@babel/preset-env和@babel/runtime-corejs2引入来进行新api的兼容处理，其中有两个核心的模块：

  1. library：不污染全局的runtime模块，供@babel/runtime-corejs2引入；

  2. modules：污染全局的polyfill模块，供@babel/polyfill和@babel/preset-env引入。

不污染全局的runtime模块主要是采用模拟替换api的方式解决兼容性问题；污染全局的polyfill模块主要是采用在全局和实例上添加api的方式解决兼容性问题。

1.2 core-js@3

core-js@3放弃了对@babel/polyfill的支持，被@babel/preset-env和@babel/runtime-corejs3引入来进行新api的兼容处理。

由于core-js@2包的体积太大（约2M），并且有很多重复的文件被引用。所以，core-js@3对包进行拆分，其中两个核心的包分别是：

  1. core-js[2]：污染全局的polyfill包，供@babel/preset-env引入，等价于core-js@2/modules（约500k, 40k minified and gzipped）；

  2. core-js-pure[3]：不污染全局的runtime包，供@babel/runtime-corejs3引入，等价于core-js@2/library（约440k）。

core-js@2分支已经冻结，不会再添加新特性，新特性都会添加到core-js@3。例如你使用了 Array.prototype.flat()，如果你使用的是core-js@2，那么其不包含此新特性。但是你仍然可以在core-js@3的基础上使用core-js@2的功能。为了可以使用更多的新特性，建议大家使用core-js@3。

关于core-js的内容大家先了解这么多，先有个印象，大家只需要记住一点：

corejs才是api兼容实现的提供者！

接下来的内容中，作者都会在core-js@2和3的基础上进行区别详解，以让大家更深入的了解core-js。

2. @babel/preset-env

babel运行总共分为三个阶段：解析、转换、生成，如下图：

AST.png

babel自6.0起，就不再对代码进行transform，现在只负责上图中的parse和generate过程，代码的transform过程全都交给一个个plugin去做。所以在没有配置任何plugin的情况下，经过babel输出的代码是没有改变的。

有的环境下可能需要转换几十种不同语法的代码，则需要配置几十个plugin，这显然会非常繁琐。所以，为了解决这种问题，babel提供了预设插件机制preset，preset中可以预设置一组插件来便捷的使用这些插件所提供的功能。目前，babel官方推荐使用@babel/preset-env预设插件。

从babel@7开始，所以针对标准提案阶段的功能所编写的预设（stage preset）都已被弃用，官方已经移除了@babel/preset-stage-x。

@babel/preset-env主要的作用是用来转换那些已经被正式纳入TC39中的语法。所以它无法对那些还在提案中的语法进行处理，对于处在stage中的语法，需要安装对应的plugin进行处理。

{
  "presets": [
    ["@babel/preset-env"]
  ]
}
复制代码

除了语法转换，@babel/preset-env另一个重要的功能是对api的处理，也就是在代码中引入polyfill。但是，@babel/preset-env默认是不开启处理api的功能，只有设置了useBuiltIns选项（不为false）才会开启。

@babel/preset-env主要还是依赖core-js来处理api的兼容性，在升级到7.4.0以上的版本以后，既支持core-js@2，也支持core-js@3，所以增加了corejs的配置来控制所需的版本。如果设置了useBuiltIns选项（不为false）就得设置corejs版本，否则babel将会发出警告。

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage", // 也可配置成 entry，配置为 false 则不需要配置 corejs
        "corejs": 3 // 也可配置成 2
      }
    ]
  ]
}
复制代码

useBuiltIns是babel7的新功能，这个配置提供了三个选项告诉babel该如何引入polyfill包：

2.1 usage

代码中不用主动import，babel会自动将代码里已使用到的且browserslist环境不支持的polyfill导入。

编译前：

const result = [1, 2, 3, 4, 5].copyWithin(0, 3)

const instance = new Promise((resolve, reject) => {
  resolve(123)
})
复制代码

编译后：

"use strict";

require("core-js/modules/es.array.copy-within.js");

require("core-js/modules/es.object.to-string.js");

require("core-js/modules/es.promise.js");

var result = [1, 2, 3, 4, 5].copyWithin(0, 3);
var instance = new Promise(function (resolve, reject) {
  resolve(123);
});
复制代码

2.2 entry

需要在代码运行之前导入，会将browserslist环境不支持的所有polyfill都导入。

编译前：

import "core-js/stable";
import "regenerator-runtime/runtime";

const result = [1, 2, 3, 4, 5].copyWithin(0, 3)

const instance = new Promise((resolve, reject) => {
  resolve(123)
})
复制代码

编译后：

"use strict";

require("core-js/modules/es.symbol.js");

// ... 此处省略400+行代码

require("regenerator-runtime/runtime");

var result = [1, 2, 3, 4, 5].copyWithin(0, 3);
var instance = new Promise(function (resolve, reject) {
  resolve(123);
});
复制代码

2.3 false

只做了语法转换，不会导入任何polyfill进来，并且corejs配置将无效。

编译前：

const result = [1, 2, 3, 4, 5].copyWithin(0, 3)

const instance = new Promise((resolve, reject) => {
    resolve(123)
})

const shen = result?.a
复制代码

编译后：

"use strict";

var result = [1, 2, 3, 4, 5].copyWithin(0, 3);
var instance = new Promise(function (resolve, reject) {
  resolve(123);
});
var shen = result === null || result === void 0 ? void 0 : result.a;
复制代码

3. @babel/polyfill

@babel/polyfill是一个运行时包，主要是通过核心依赖core-js@2来完成对应浏览器不支持的新的全局和实例api的添加。在升级到core-js@3后，如果还要保留@babel/polyfill的使用，就要在@babel/polyfill中添加core-js@2和core-js@3切换的选项，这样@babel/polyfill中将包含core-js@2和core-js@3两个包，出于这个原因官方决定弃用@babel/polyfill。

关于@babel/polyfill有三点要说明：

  1. 如果采用@babel/preset-env的polyfill方案是不需要@babel/polyfill的安装为前提，只需要安装core-js（regenerator-runtime会在安装@babel/preset-env的时候自动安装），然后通过设置useBuiltIns选项来开启对api的兼容性处理。

  2. 当然，你也可以不依赖@babel/preset-env提供的处理api兼容性的能力，直接使用@babel/polyfill来处理。如果使用了core-js@3，则需要做如下的替换工作：

// before
import "@babel/polyfill";

// after
import "core-js/stable";
import "regenerator-runtime/runtime";
复制代码

  1. 网上有很多人认为@babel/polyfill除了有全局污染的缺点外，还会让不同的文件中包含重复的代码，增加编译后的体积。举个例子：

编译前：

const key = 'babel'
const obj = {
  [key]: 'polyfill',
}
复制代码

编译后：

"use strict";

function _defineProperty(obj, key, value) { if (key in obj) { Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); } else { obj[key] = value; } return obj; }

var key = 'babel';

var obj = _defineProperty({}, key, 'polyfill');
复制代码

编译后的代码中插入了_defineProperty函数。的确，如果多个文件中使用了对象的属性名表达式，则会插入多个_defineProperty函数。但是，这件事情并不是@babel/polyfill这种polyfill方案实现的，而是@babel/preset-env本身在语法转换的时候，会使用一些辅助函数来实现一些语法的模拟。而事实的确，这只是一种语法转换。

4. @babel/runtime

在使用@babel/preset-env提供的语法转换和全局api添加的功能时，难免会造成文件的体积增加以及api的全局污染。为了解决这类问题，引入了runtime的概念，runtime的核心思想是以引入替换的方式来解决兼容性问题。

runtime包其实有三个：

  • \@babel/runtime[4]

  • \@babel/runtime-corejs2[5]

  • @babel/runtime-corejs3

@babel/runtime与@babel/runtime-corejs2类似，区别只是@babel/runtime-corejs2使用了core-js@2来处理全局api。所以接下来只阐述@babel/runtime-corejs2和@babel/runtime-corejs3的区别。

@babel/runtime-corejs2会从core-js中的library模块去加载对应的runtime代码：

// runtime-corejs2/core-js/array/from.js
module.exports = require("core-js/library/fn/array/from");
复制代码

@babel/runtime-corejs3会从core-js-pure这个包中去加载对应的runtime代码：

// runtime-corejs3/core-js/array/from.js
module.exports = require("core-js-pure/features/array/from");
复制代码

@babel/runtime-corejs3相比较@babel/runtime-corejs2最大的改变就是可以模拟实例上的api。

比如数组的includes方法，@babel/runtime-corejs3提供了模拟api，而@babel/runtime-corejs2没有：

import _includesInstanceProperty from "@babel/runtime-corejs3/core-js-stable/instance/includes";

_includesInstanceProperty(foo).call(foo, "a");
复制代码

甚至，如果我们想在一个不支持Promise的环境下使用Promise，可以这样：

// @babel/runtime-corejs2
// var _interopRequireDefault = require("@babel/runtime-corejs2/helpers/interopRequireDefault");
// var _promise = _interopRequireDefault(require("@babel/runtime-corejs2/core-js/promise"));

// @babel/runtime-corejs3
var _interopRequireDefault = require("@babel/runtime-corejs3/helpers/interopRequireDefault");
var _promise = _interopRequireDefault(require("@babel/runtime-corejs3/core-js-stable/promise"));

var instance = new _promise["default"](function (resolve, reject) {
  resolve(123);
});
复制代码

显然这样一个个手动导入很麻烦，这个时候我们就需要借助自动导入插件来帮助我们完成这项工作。

@babel/runtime是api模拟方案的提供者，是项目生产依赖，而不是开发依赖，安装的时候不要使用-D

5. @babel/plugin-transform-runtime

@babel/plugin-transform-runtime就是为了方便@babel/runtime的使用。通过ast的分析，自动识别并替换代码中的新api，解决手动require的烦恼。

{
  "presets": [
    [
      "@babel/preset-env"
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "corejs": 3
      }
    ]
  ]
}
复制代码

corejs选项来配置使用的是@babel/runtime-corejs2还是@babel/runtime-corejs3。

编译前：

const result = [1, 2, 3, 4, 5].copyWithin(0, 3)

const instance = new Promise((resolve, reject) => {
  resolve(123)
})

const key = 'babel'
const obj = {
  [key]: 'polyfill',
}
复制代码

使用@babel/runtime-corejs2编译后：

"use strict";

var _interopRequireDefault = require("@babel/runtime-corejs2/helpers/interopRequireDefault");

var _defineProperty2 = _interopRequireDefault(require("@babel/runtime-corejs2/helpers/defineProperty"));

var _promise = _interopRequireDefault(require("@babel/runtime-corejs2/core-js/promise"));

var result = [1, 2, 3, 4, 5].copyWithin(0, 3);
var instance = new _promise["default"](function (resolve, reject) {
  resolve(123);
});
var key = 'babel';
var obj = (0, _defineProperty2["default"])({}, key, 'polyfill');
复制代码

使用@babel/runtime-corejs3编译后：

"use strict";

var _interopRequireDefault = require("@babel/runtime-corejs3/helpers/interopRequireDefault");

var _defineProperty2 = _interopRequireDefault(require("@babel/runtime-corejs3/helpers/defineProperty"));

var _copyWithin = _interopRequireDefault(require("@babel/runtime-corejs3/core-js-stable/instance/copy-within"));

var _promise = _interopRequireDefault(require("@babel/runtime-corejs3/core-js-stable/promise"));

var _context;

var result = (0, _copyWithin["default"])(_context = [1, 2, 3, 4, 5]).call(_context, 0, 3);
var instance = new _promise["default"](function (resolve, reject) {
  resolve(123);
});
var key = 'babel';
var obj = (0, _defineProperty2["default"])({}, key, 'polyfill');
复制代码

可以看到，使用@babel/runtime-corejs3可以模拟数组上的copyWithin方法，而@babel/runtime-corejs2则不能。

@babel/plugin-transform-runtime则是开发依赖，编译时负责处理@babel/runtime，两者是搭配使用的。

6. 总结

目前，babel处理兼容性问题有两种方案：

  1. @babel/preset-env + corejs@3实现语法转换 + 在全局和实例上添加api，支持全量加载和按需加载，我们简称polyfill方案；

  2. @babel/preset-env + @babel/runtime-corejs3 + @babel/plugin-transform-runtime实现语法转换 + 模拟替换api，只支持按需加载，我们简称runtime方案。

两种方案都依赖核心包corejs@3，只不过依赖的模块不同，导致实现方式不同。两种方案各有优缺点：

  1. polyfill方案很明显的缺点就是会造成全局污染，而且会注入冗余的工具代码；优点是可以根据浏览器对新特性的支持度来选择性的进行兼容性处理；

  2. runtime方案虽然解决了polyfill方案的那些缺点，但是不能根据浏览器对新特性的支持度来选择性的进行兼容性处理，也就是说只要在代码中识别到的api，并且该api也存在core-js-pure包中，就会自动替换，这样一来就会造成一些不必要的转换，从而增加代码体积。

所以，polyfill方案比较适合单独运行的业务项目，如果你是想开发一些供别人使用的第三方工具库，则建议你使用runtime方案来处理兼容性方案，以免影响使用者的运行环境。

关于本文

来源：PandlyShen

https://juejin.cn/post/6976501655302832159

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

   “分享、点赞、在看” 支持一波 

傲娇的koala
关注
前端十九种兼容性
weixin_49473712的博客
08-06 541
第一种兼容 在设置宽度的时候，子级的宽度大于父级的宽度时。 标准浏览器下，子级的宽度不会撑开父级 IE浏览器下会撑开对应的宽度 第二种兼容 IE6中不能用margin的方法让元素显示在一行， 必须使用float的方法，让内容显示在一行。 第三种兼容 嵌套问题：P标签不能包div 就是说P标签不能包含块标签 第四种兼容 元素的最小高度 IE6中会自动给高度添加为19。因为IE6认为最小高度为19px，如果不足，自动补全 如果想要设置高度小于19px的，做到浏览器兼容， 必须添加ov
Vue前端工程化（babel && webpack打包）
Lawless
02-06 1197
1.模块化的分类 A.浏览器端的模块化 1).AMD(Asynchronous Module Definition,异步模块定义) 代表产品为：Require.js 2).CMD(Common Module Definition,通用模块定义) 代表产品为：Sea.js B.服务器端的模块化 服务器端的模块化规范是使用CommonJS规范： 1).使用require引入其他模块或者包 2).使...
浅谈前端兼容问题
mapbar_front的博客
04-14 6308
1、为什么会出现兼容问题 在各大浏览器厂商的发展过程中，他们其实对web的标准都有不同的实现，因为实现的标准的不同，所以会有兼容性的产生。通俗的说，就是对于web标准，有些浏览器支持，有些浏览器不支持。 2、从历史角度看兼容 早期IE是在浏览器的世界中，占据主导地位。所以它自身实现了很多不同于标准浏览器的东西，有css的，也有js的： Js方面： 1、滚动事件的兼容： scroll...
前端兼容性问题总结
weixin_34399060的博客
05-29 111
##HTML 篇 #####样式兼容性问题 <!-- IE 按 Edge 模式渲染 --> <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> <!-- IE 8 9 10 按 IE7 模式渲染 --> <meta http-equiv="X-UA-Compatible" content="IE=...
前端兼容性
南北极之间
07-27 656
参考资料： https://www.jianshu.com/p/6afd596440bb https://www.cnblogs.com/angel648/p/11392262.html https://blog.csdn.net/weixin_38536027/article/details/79375411 《==我觉得这个比较通俗易懂
前端常见的浏览器兼容性问题及解决方案
chunianzai8996的博客
10-18 768
市场上浏览器种类很多，不同浏览器的内核也不尽相同，所以各个浏览器对网页的解析存在一定的差异。 浏览器内核主要分为两种，一是渲染引擎，另一个是js引擎，内核更加倾向于说渲染引擎。 常见的浏览器内核： 常见的浏览器内核可以分为四种：Trident、Gecko、Blink、Webkit ...
前端工程化 体系设计与实践
05-09
在现代Web开发中，前端工程化是提升效率、保证代码质量和可维护性的关键。"前端工程化 体系设计与实践"这一主题深入探讨了如何构建高效、可扩展且易于维护的前端项目。以下是对这一主题的详细阐述： 一、前端工程化...
前端工程化：构建与打包工具的选择与配置
# 1. 前端工程化概述 ## 1.1 什么是前端工程化 前端工程化是指通过工具和方法来优化...常见的前端工程化工具包括构建工具（Webpack、Gulp、Grunt、Parcel、Rollup等）和打包工具（Babel、UglifyJS、Terser、PostCSS、
前端工程化：构建工具、包管理与自动化部署
# 1. 前端工程化概述 前端工程化在当今的Web开发中扮演着至关重要...在前端工程化中，开发人员需要通过工具和流程来管理项目、优化代码、提升性能，以应对日益复杂的前端项目和需求。 ## 1.2 前端工程化的重要性 随
weekly:技术周刊，主要关注数据可视化、前端工程化、组件化等领域
04-21
在本周的技术周刊中，我们聚焦于三个核心领域：数据可视化、前端工程化和组件化。这些主题对于现代Web开发至关重要，因为它们不仅提高了开发效率，还增强了用户体验。 首先，让我们探讨数据可视化。在这个信息化...
前端兼容性处理
最新发布
weixin_53000437的博客
04-12 1811
proxy有一个不完整的polyfill：proxy-polyfill，只实现了部分proxy的方法，而且初始化时对象的属性需要是确定的，类似于Object.defineProperty。vue3由于使用了proxy api，而proxy并没有完全匹配的polyfill，所以当浏览器版本不支持proxy时，无法做到兼容。平时我们通过vue-cli创建的项目都默认包含了babel-loader的配置，所以不需要额外处理。是一个 Babel 的插件，它会自动为你的代码添加所需的。
js的一些兼容性写法
weixin_34080571的博客
11-28 205
//兼容性写法 document.onclick = function(ev){ var e = ev||window.event; var x = e.clientX; var y = e.clientY; } var winW=document.body.clientWidth||document.docuemntElement.cl...
【前端兼容性】常见的浏览器兼容问题及解决方案
m_sy530的博客
10-29 5252
前言 现今市面上的浏览器种类繁多，而前端开发过程中所用到的一些功能属性不可能兼容所有浏览器，因此就需要解决浏览器的兼容问题。（PS：死亡要求——兼容IE浏览器a(ﾉ=▼ω▼=)ﾉ┴─┴） ...
前端浏览器兼容性问题整理
weixin_53416425的博客
01-04 1874
前端浏览器兼容性常见问题，摘录于各个网站文章以及平时所见，为积累经验和跳槽面试做准备，如有侵权，请及时联系。
常见兼容性问题
weixin_34357962的博客
04-19 104
为什么80%的码农都做不了架构师？>>> ...
前端开发中的浏览器兼容性问题及解决方案
极限突破者的博客
03-03 7042
在之前的文章中，我们学习了前端开发中的网站性能提升的相关内容。在本文中，我们将深入探讨一个前端开发者必须面对的问题：浏览器兼容性问题。我们将介绍什么是浏览器兼容性问题，为什么会发生这种问题，以及如何解决这些问题。浏览器兼容性问题是指在不同的浏览器中，同一段代码可能会呈现出不同的效果，这对于前端开发者来说是一个头疼的问题。CSS兼容问题及解决方案JS兼容问题及解决方案移动端兼容问题及解决方案浏览器兼容性问题是前端开发中必须面对的问题，但是通过使用适当的解决方案，我们可以最大程度地减少这些问题的影响。
前端开发常见的兼容性问题
weixin_44315394的博客
07-24 1383
作为一个前端开发者，最烦恼的应该是如何让网页在所有浏览器下都能正常浏览。现在我来总结下我在工作中所遇到的一些问题以及我的一些解决方法。 css 方面的兼容问题 设置透明度 ==IE浏览器使用滤镜实现== filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=50) ==非IE浏览器== opacity:0.5 ...
前端工程化实践与面试必备知识点详解
"该资源是关于前端面试的全面知识点总结，涵盖了前端工程化、数据安全、前端错误信息采集、微前端、JavaScript基础、Vue框架以及前端优化等多个领域，旨在帮助面试者准备相关面试并提升技能水平。" 在前端开发中，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值