最近在博动星球的PC官网项目中，采用了新版babel7作为ES语法转换器。babel7的一个重大变化是改进了配置文件的加载逻辑，但实际上往往给不熟悉babel配置逻辑的朋友带来更多的问题。本文为babel7配置文件中文指南。是英语学渣的救星，是懒人的美味佳肴。我们对任何错误概不负责，欢迎指正。PrefaceBabel7从2018年3月开始进入alpha阶段，第一个版本在5个月后于2018年8月发布。最新版本是2019年2月26日发布的7.3.4，时光荏苒，在这美好的9012年，ES2019即将发布的时候，我想：是时候使用babel7了。本文不是babel7的升级教程，只是对babel7的新变化和配置逻辑的一点洞察。Babel7对monorepo结构项目的优化恰恰符合我们目前的项目架构预期，简化了我们配置的复杂度，但是其不可理解的配置加载逻辑却让我踩了很多坑，这就是本文的出处。说说变化在开始说babel7的配置逻辑之前，我们先从以下几个方面说说babel7所做的变化及其逻辑意义。proposal语法特性在历史（babel6）时代，人们通常使用babel提供的preset-stage预设来体验ES6之后proposal阶段的语法特性。例如做如下babel配置："presets":["es2015","react","stage-0"]其中，es2015preset会包含ES6标准中的所有语法特性；stage-0preset会包含当前(安装)ES语法级数中stage0到3的特性(在默认npm包的那一刻)(小数包含大数)。但实际上babel官方提供了stagepresets这样一来，就会出现很多问题，比如：随着es标准的不断发展，大量的新特性几乎成为了标准，同时stage0-3的特性也必然会发生变化，可以是说stage0-3的stage特性不稳定，很有可能在某个时候被TC39委员会除名，换stage，改语法。虽然babel-preset-*defaults会与TC39一致更新，但这样的用法需要用户不断更新才能与标准保持一致。preset-es2015与preset-stage-0的历史实践极其混乱。比如，没有人知道他需要的特性在多少个阶段，如果一个语言特性从stage3变成stage4，往往会导致前面stage0（包括1、2、3）的配置出现问题。因为feature提升后，新的stage0将不再包含feature内容，但用户可能不知道应该将feature所在的ES标准添加到配置中。eslint等大量社区工具依赖babel；babel的preset-Stage预设更新会导致这些社区工具经常出现问题。今天，babel官方认为使用不稳定的stage0-3作为预设是不合理的，因此放弃了stage预设，用户可以选择使用哪个proposalfeatureplugin，这样会带来更多的Clarity（用户不需要了解阶段，他们可以清楚地知道他们选择的插件可以在代码中使用哪些功能）。所有具有提议特性的插件都改变了命名约定，即像@babel/plugin-proposal-function-bind这样的命名方式来表明这是一个提议阶段的特性。ES标准特性对于正经的ES标准特性，babel从6开始建议使用babel-preset-env，一个可以根据环境自动配置的预设。有了babel7，我们可以彻底告别这些历史预设：preset-es2015/es2016/es2017/latest为什么preset-env更好？我认为对于开发者来说，理解目标用户平台（兼容哪些浏览器）比“编译到哪个ES标准”更容易理解。只需将编译插件的选择留给preset-env即可。它将根据兼容表和您设置的目标用户平台选择正确的插件。polyfill具有与阶段默认值相同的结尾。对于提案阶段的特性，polyfill中也移除了对它们的支持。之前的babel-polyfill是这样实现的：import"core-js/shim";//included
