Babel如何转译ES6+代码详解

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Babel如何转译ES6+代码详解》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

配置Babel转译ES6+代码的核心是使用@babel/preset-env和core-js。首先安装@babel/core、@babel/cli、@babel/preset-env和core-js，然后在项目根目录创建babel.config.js文件，配置presets为@babel/preset-env，并设置targets指定目标环境，useBuiltIns为'usage'以按需引入polyfill，corejs版本为3。推荐使用.browserslistrc文件统一管理浏览器目标，提升配置复用性。在Webpack中通过babel-loader处理JS文件，并排除node_modules以提升性能。注意避免常见问题：如exclude配置错误、useBuiltIns与core-js版本不匹配、modules设置不当导致ESM无法处理等。优化方面，开启babel-loader的cacheDirectory可加速构建，使用@babel/plugin-transform-runtime避免辅助函数重复。对于库开发，应设useBuiltIns为false并结合transform-runtime避免污染全局环境。Babel的作用在于弥合现代语法与旧环境兼容性的鸿沟，让开发者既能使用最新特性，又能覆盖广泛用户。@babel/preset-env负责语法转译，core-js提供API垫片，二者结合确保代码在旧环境中正常运行。

配置Babel来转译ES6+代码，核心在于理解其配置文件和主要预设（presets）。通常，我们会通过安装必要的Babel包，然后在项目根目录创建一个babel.config.js文件，定义需要使用的预设和插件。最常用的是@babel/preset-env，它能根据你指定的目标浏览器或Node.js环境，智能地选择所需的转译规则，将现代JavaScript语法转换为兼容性更好的旧版本。同时，为了支持新的内置对象和方法（如Promise或Array.prototype.includes），我们还会结合core-js进行polyfill。

解决方案

要配置Babel转译ES6+代码，我们主要需要以下几个步骤和核心概念：

1. 安装核心依赖： 首先，你需要安装Babel的核心包、@babel/preset-env预设以及core-js（用于polyfill）。

   npm install --save-dev @babel/core @babel/cli @babel/preset-env core-js
   # 或者使用 yarn
   yarn add --dev @babel/core @babel/cli @babel/preset-env core-js

   如果你在Webpack等构建工具中使用Babel，还需要安装babel-loader。

   npm install --save-dev babel-loader
   # yarn add --dev babel-loader

2. 创建Babel配置文件： 在项目根目录创建一个babel.config.js文件。这是推荐的配置方式，因为它提供了更强大的动态配置能力。

   // babel.config.js
   module.exports = {
     presets: [
       [
         '@babel/preset-env',
         {
           // 指定目标环境，Babel会根据这些目标来决定需要转译哪些特性
           // 这里我通常会用browserslistrc文件来统一管理，更清晰
           targets: {
             edge: '17',
             firefox: '60',
             chrome: '67',
             safari: '11.1',
           },
           // 决定如何处理polyfill。
           // 'usage': 根据代码中实际使用的ES6+特性自动引入所需的polyfill。
           // 'entry': 需要在入口文件手动 import 'core-js/stable'; 和 import 'regenerator-runtime/runtime';
           // false: 不自动引入polyfill，这通常用于库开发，避免污染全局环境。
           useBuiltIns: 'usage',
           // 指定core-js的版本，通常是3
           corejs: 3,
           // 如果你的模块是ESM，可以设置为false，让Webpack等工具处理模块
           // 如果是CommonJS，可以不设置或设置为'commonjs'
           modules: false, // 推荐设置为false，让Webpack处理ESM
         },
       ],
     ],
     plugins: [
       // 可以在这里添加额外的插件，例如处理私有属性、装饰器等
       // ['@babel/plugin-proposal-class-properties', { loose: true }],
       // ['@babel/plugin-proposal-private-methods', { loose: true }],
     ],
   };

   关于targets，我个人更倾向于在项目根目录创建一个.browserslistrc文件来集中管理目标浏览器列表，这样配置看起来更整洁，而且其他工具（如Autoprefixer）也能复用这个配置。例如：

   # .browserslistrc
   > 0.2%
   not dead
   not op_mini all

   这样，@babel/preset-env就会自动读取这个文件。

3. 集成到构建工具（以Webpack为例）： 如果你使用Webpack，需要在webpack.config.js中配置babel-loader来处理JavaScript文件。

   // webpack.config.js
   module.exports = {
     // ...其他配置
     module: {
       rules: [
         {
           test: /\.js$/,
           exclude: /node_modules/, // 这一步很重要，通常不转译node_modules
           use: {
             loader: 'babel-loader',
             options: {
               // Babel配置会从 babel.config.js 读取，这里可以不写
               // 但如果你有特殊需求，也可以在这里直接配置或覆盖
               // cacheDirectory: true, // 开启缓存，加速二次构建
             },
           },
         },
       ],
     },
     // ...其他配置
   };

通过上述配置，当你的代码经过Babel处理时，@babel/preset-env会根据targets智能地将ES6+语法（如箭头函数、const/let、类等）转译为更广泛兼容的ES5代码。同时，useBuiltIns: 'usage'结合corejs: 3会自动检测代码中使用的需要polyfill的特性，并按需引入core-js提供的对应polyfill，避免了手动引入和不必要的代码体积。

为什么我们需要Babel？仅仅使用现代浏览器不就行了吗？

这个问题问得很好，我个人也曾有过这样的疑问。毕竟，现在大部分用户用的都是Chrome、Firefox这些现代浏览器，它们对ES6+的支持已经非常完善了。但现实情况往往比我们想象的要复杂一些。

首先，用户环境的多样性是绕不开的。虽然大部分人使用现代浏览器，但总有一部分用户因为各种原因（比如公司内部系统、老旧设备、或者仅仅是懒得更新）还在使用IE 11、Safari的旧版本，甚至是某些国产浏览器的旧内核。对于这些用户，如果你的代码直接使用了ES6+的新特性，他们打开页面可能就是一片空白或者各种报错。作为开发者，我们当然希望自己的产品能尽可能覆盖更广的用户群体，所以为了兼容性，Babel就成了必不可少的工具。

其次，Node.js环境也需要考虑。虽然Node.js本身对ES6+的支持比浏览器要快，但如果你在开发一些需要支持旧版本Node.js的库或应用时，Babel同样能派上用场。

再者，从开发者体验的角度看，Babel让我们能够“活在未来”。我们可以尽情使用最新的JavaScript语法特性，享受它们带来的便利和代码可读性提升，而不用担心兼容性问题。这就像我们有了更先进的工具，可以更高效地完成工作，至于最终产品如何适应不同的环境，交给Babel去处理就好了。

所以，我认为Babel的存在，并非是现代浏览器不够好，而是为了弥合“理想的开发环境”与“复杂的现实用户环境”之间的鸿沟。它让我们既能追求技术前沿，又能照顾到广大的用户群体，这在我看来，是一种非常务实的解决方案。

@babel/preset-env究竟做了什么，它和core-js有什么关系？

@babel/preset-env是Babel生态中最核心也是最常用的一个预设。简单来说，它是一个“智能管家”，它的主要职责是根据你指定的目标环境（比如支持哪些浏览器版本），自动判断你的JavaScript代码中哪些ES6+特性需要被转译，然后只引入必要的Babel插件去完成这些转译工作。

在没有@babel/preset-env之前，我们可能需要手动安装和配置几十个甚至上百个Babel插件，比如@babel/plugin-transform-arrow-functions、@babel/plugin-transform-classes等等。这不仅配置起来繁琐，而且容易出错。@babel/preset-env的出现，极大地简化了这一过程。你只需要告诉它你的目标环境（通过targets选项，可以是browserslist字符串，也可以是对象），它就会根据内置的兼容性数据，为你生成一个最佳的插件列表。例如，如果你的目标环境是所有现代浏览器，它可能就不会转译箭头函数，因为现代浏览器都支持；但如果目标包含IE 11，它就会引入转译箭头函数的插件。

那么，它和core-js又有什么关系呢？这里就要区分一下JavaScript特性的两种类型：

1. 语法特性 (Syntax Features)：比如箭头函数、const/let、类(Class)、模块(ESM)等。这些是JavaScript语言本身的语法结构。@babel/preset-env主要负责将这些新语法转译成旧语法。
2. 内置对象和方法 (Built-in Objects and Methods)：比如Promise、Array.prototype.includes、Map、Set等。这些是JavaScript运行时提供的全局对象或原型方法。Babel本身只能转译语法，它无法“创造”这些不存在于旧环境中的全局对象或方法。

这就是core-js登场的地方。core-js是一个提供polyfill（垫片）的库，它包含了大量ES6+及更高版本JavaScript中新增的内置对象和方法的实现。当你的代码使用了Promise，而目标环境不支持时，@babel/preset-env配合core-js就能发挥作用。

具体来说，当你配置@babel/preset-env并设置了useBuiltIns: 'usage'或'entry'以及corejs: 3时：

• useBuiltIns: 'usage'：Babel会扫描你的代码，如果发现你使用了Promise或Array.prototype.includes等需要polyfill的特性，它会在每个需要的地方自动插入import 'core-js/modules/es.promise'或import 'core-js/modules/es.array.includes'这样的语句。这种方式是按需引入，可以有效减小最终打包体积。
• useBuiltIns: 'entry'：你需要手动在你的入口文件（比如main.js）顶部引入import 'core-js/stable';和import 'regenerator-runtime/runtime';。这种方式会一次性引入所有目标环境需要的polyfill，虽然可能会引入一些不必要的代码，但确保了所有特性都得到支持。regenerator-runtime是用来polyfillasync/await这种生成器函数语法的。

总结一下，@babel/preset-env负责处理语法层面的转译，而core-js则负责提供运行时API层面的polyfill。两者结合，才能确保你的ES6+代码在旧环境中既能运行，又能拥有完整的特性支持。我个人在应用开发中倾向于使用usage模式，因为它更精准，能有效控制最终产物的大小。

在实际项目中，Babel配置有哪些常见的“坑”和优化技巧？

在实际项目中配置Babel，虽然看似简单，但确实有一些常见的“坑”和一些可以提升效率和性能的优化技巧。我在这里分享一些我个人遇到过和总结的经验。

常见的“坑”：

1. node_modules的误伤或漏网之鱼： 最常见的错误之一就是没有正确配置babel-loader的exclude: /node_modules/。通常我们不希望Babel去转译node_modules里的代码，因为它们通常已经是预编译过的，或者有自己的Babel配置。但反过来，有时候某些第三方库为了发布方便，直接发布了ES6+源码，这时候你就需要把它们从exclude中移除，或者单独配置一个规则去转译这些特定的模块。这很像一个“双刃剑”，需要小心平衡。

2. useBuiltIns和core-js的版本不匹配或配置不当： 如果corejs选项指定了2，但你实际安装的是core-js@3，或者反过来，都会导致polyfill失效。另外，useBuiltIns: 'entry'模式下，忘记在入口文件顶部手动import 'core-js/stable';也是常犯的错误，这会导致一些全局API缺失。

3. modules: false的理解偏差： 在@babel/preset-env中设置modules: false，意味着Babel不会将ESM（import/export）语法转译为CommonJS（require/module.exports），而是保留ESM语法。这通常是推荐的做法，因为这样Webpack等打包工具可以更好地进行Tree Shaking，优化代码体积。但如果你没有使用打包工具，或者你的目标环境不支持ESM，那么就需要设置为'commonjs'。我曾有次在Node.js项目中忘了设为'commonjs'，结果直接运行报错，才发现这个细节。

4. 插件和预设的顺序问题： Babel的插件和预设执行顺序是有讲究的。插件会在预设之前运行，并且插件是从前往后执行，预设是从后往前执行。如果顺序不对，可能会导致一些转换不生效或报错。比如，处理类属性的插件通常要在处理类的插件之前运行。

5. 缓存问题：babel-loader提供了cacheDirectory选项，开启后能显著提升二次构建速度。但有时候，如果缓存失效或者配置更新后缓存没有被正确清除，可能会导致一些奇怪的转译问题。遇到这类问题，尝试删除缓存目录（通常是node_modules/.cache/babel-loader）往往能解决。

优化技巧：

1. 利用.browserslistrc精确控制targets： 前面提到过，将目标环境配置集中到.browserslistrc文件，不仅能让babel.config.js更简洁，也能让其他工具（如Autoprefixer）复用这个配置，保持项目兼容性策略的一致性。这是一种很优雅的管理方式。

2. babel-loader的cacheDirectory： 在webpack.config.js中为babel-loader开启options: { cacheDirectory: true }。这能将Babel的转译结果缓存到文件系统，在后续的构建中，如果文件内容没有变化，Babel会直接使用缓存，大大加快构建速度，尤其是在大型项目中效果显著。

3. 使用@babel/plugin-transform-runtime避免重复的辅助函数： 当Babel转译一些高级语法（如async/await、类继承）时，它可能会生成一些小的辅助函数（helper functions）。默认情况下，这些辅助函数会内联到每个需要它们的文件中，导致代码重复和体积增大。@babel/plugin-transform-runtime插件的作用就是将这些辅助函数提取出来，作为独立的模块导入，从而避免重复。

   // babel.config.js
   module.exports = {
     // ...
     plugins: [
       ['@babel/plugin-transform-runtime', {
         corejs: false, // 如果你已经通过 @babel/preset-env 引入了 core-js，这里可以设置为 false
         helpers: true, // 启用辅助函数转换
         regenerator: true, // 启用 async/await 的 regenerator runtime
       }],
     ],
   };

4. 针对库开发和应用开发的不同策略： 如果你在开发一个库，通常不希望Babel引入polyfill，因为这可能会污染使用者的全局环境。这时，你可以将@babel/preset-env的useBuiltIns设为false，并且在@babel/plugin-transform-runtime中设置corejs: 3（或2），让它按需引入polyfill，但这些polyfill会以模块形式引入，而不是修改全局对象。这样，库的消费者可以自行决定如何处理polyfill。

5. Monorepo中的配置策略： 在Monorepo（多包仓库）中，你可能希望有一个统一的babel.config.js在项目根目录，但某些子包又有自己的特殊需求。这时，Babel的配置查找机制会从当前文件向上查找，直到找到babel.config.js。你可以利用这个特性，在子包内部放置一个.babelrc或babel.config.js来覆盖或扩展根目录的配置。

这些“坑”和技巧都是我在实践中摸索出来的，理解它们能帮助我们更高效、更稳定地使用Babel，避免不必要的麻烦。配置Babel其实是一个不断学习和调整的过程，毕竟JavaScript生态发展太快了。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。