安装babel不就是为了使用es的所有新特性么,为什么还要弄个插件配置来说明我要用哪些新特性?

搞不懂为什么babel不设计成无需插件配置,装上就能使用es所用新特性?
关注者
150
被浏览
20624

因为 babel 的存在不只是为了『使用 es 的所有新特性』。它需要考虑如下问题:

  1. 如何处理尚未成为标准的提案? 建议你先了解一下 ECMAScript 的制定流程 (参考: wwsun.github.io/posts/n),除了已经正式纳入规范 (ES2015/6/7) 的特性,还有许多处于不同讨论阶段的特性提案 (stage 1/2/3/4)。这些讨论中的特性严格来说还不算是标准,尤其是 stage 1/2 的特性,完全有可能被改动甚至是撤销提案。因此从 babel 的角度来说,显然不能够默认启用这些特性,而需要有可配置的选项让用户自行衡量风险,决定是否使用。
  2. 如何针对不同平台的支持情况,减少无用特性的编译。 默认目标通常是 ES5,但其实每个特性都有对应的性能开销,babel 本来速度就不是很快,如果能针对目标平台减少需要处理的特性,可以提高编译效率,也可以尽量使用平台原生的 ES 特性。比如如果只针对最新的 Chrome,大部分插件都是不需要的。有时候你可能只需要一两个特定的插件,比如 syntax-dynamic-import。有时候你可能需要保留一些 ES 特性不编译,比如使用 webpack 2 的时候保留 ES modules 语法不编译为 CommonJS。这些都决定了可配置性是必需的。当然手动配置肯定很麻烦,这也是为什么现在有了 babel-preset-env,可以自动根据目标平台分析需要用哪些插件。
  3. 作为一个编译工具链,给予用户实验、甚至是实现非标准的语言扩展的能力。 Babel 的一个重要意义就在于能够让用户提前使用尚未成为标准的语言特性,从而为标准本身的制定提供实践中才能获得的反馈。一个提案靠不靠谱,该不该成为标准?先做个插件出来用到项目里感受一下,比空口讨论靠谱得多。 至于非标准扩展,比如 JSX 并非 ES 标准,但其编译就是完全依赖 Babel 的可配置的插件能力才得以实现的。 另外,babel 作为一个工具链还可以有很多其他用途,比如用来进行编译时的性能优化、测试覆盖率的 instrumentation 等等。

综上,插件化是 babel 存在的核心价值,对于配置的问题,它的答案是 preset;对于题主的需求,用 babel-preset-env 的默认配置即可。另外如果没有以上这些可配置性方面的需求,Buble (buble.surge.sh) 也是一个可以考虑的选择,但 Buble 并不追求与规范 100% 的一致性,是否适合你,需要你自行判断。