Babel 你是個好人，但是......

題圖：tumbao1949 @ unsplash.com

1. 說到 Babel 我會想到的一些關鍵詞，語言特性、tc39、補丁、擴展和生態(tài)、慢，你會想到啥？

2. Babel 的出發(fā)點是讓開發(fā)者提前用上 ECMAScript 提案里的特性，除此之外，我們還用他來打補丁、實現(xiàn) Code Mod、識別文件特征、約束和卡點、magic 功能比如 auto css modules 等

3. 語言特性都是 Babel 官方提供，由很多插件組成，這些特性歸屬不同的 Stage，從 Stage 0 到 3，preset-env 不包含 3 以下的語言特性，所以通常使用方式是 preset-env + 手選的 stage 3 以下特性

4. 語言特性又分兩類，編譯類和補丁類。前者比如 `[1, 2, 3].map(n => n + 1)` 只要編譯成 `[1, 2, 3].map(function (n) { return n + 1 })` 就好， 后者比如 `[1, 2, 3].includes(1)` 的 includes 是需要給不支持的瀏覽器額外 `Array.prototype.includes` 補丁的，有些特性需要兩者結合使用

5. 語言特性的編譯會產(chǎn)生很多輔助代碼，比如 `class {}` 會需要 inherits、setPrototypeOf、createSuper、getPrototypeOf、classCallCheck 等輔助函數(shù)，babel 的編譯是文件級的，所以會產(chǎn)生大量的重復代碼，解法是 plugin-transform-runtime + `@babel/runtime` 的組合，`@babel/runtime`  封裝上述輔助函數(shù)，plugin-transform-runtime 讓編譯產(chǎn)物使用 `@babel/runtime`

6. plugin-transform-runtime 不要配 corejs 帶上補丁，不管是項目還是組件。大家可以想想為什么，算是這篇文章留的一道題

7. 補丁方案 Babel 提供了兩種，通過 targets 配置 + preset-env 的 useBuiltIns 配置實現(xiàn)，兩種方案分別對應的是 entry 和 usage 值，前者會替換 core-js import 為特性列表，后者會按使用引入用到的特性列表

8. Babel 作為編譯器不應該處理 modules 類型的轉換，比如 esm 到 cjs 或 systemjs，這層處理應交給 Bundler，Bundler 通常還要依賴 esm 模塊做 tree-shaking，所以 preset-env 里的 modules 是個廢配置，始終設為 false 就好

9. 慢！是個大問題。影響的不僅有開發(fā)者的效率，還有工程化方案。如果不慢，node_modules 也走 babel 編譯，那很多問題根本不存在。比如補丁方案可以切到 usage 按需打，整體尺寸會更??；比如部分依賴沒有用 es5 語法導致的 ie11 兼容問題；比如組件發(fā)布可以用 ts 寫不用編譯直接發(fā)布。這給 swc 等競對方案留了很多可能性。

10. 生態(tài)很好，卻沒啥可用的。最后一條本想推薦一些三方插件，翻了下發(fā)現(xiàn)并沒有啥，目前在 umi 在用的有 import、macros、svgr-webpack 和 named-asset-import。因為很多 Babel 能做的在 Bundler 層也能做而且更合理，Babel 覆蓋范圍只有項目代碼，Bundler 層覆蓋整個產(chǎn)物，像 remove-console 這種在 Bundler 層做就更合理。