精通前端polyfill,兼容各浏览器运行E6语法

ES6 在2015正式发布已经多年。最新浏览器们逼近100% 的支持率&＃xff0c;但为了少数用户体验&＃xff0c;我们很可能需要兼容IE9。 Babel 默认只转码 ES6 的新语法&＃xff08;syntax&＃xff09;&＃xff0c;而不转换新的 API&＃xff0c;比如 Iterator、Generator、Set、Maps、Proxy、Reflect、Symbol、Promise 等全局对象&＃xff0c;以及一些定义在全局对象上的方法&＃xff08;比如 Object.assign、Array.from&＃xff09;都不会转码&＃xff0c;这时我们就需要提供polyfill。

babel 和 polyfill

刚接触 babel 的同学可能都认为在使用了 babel 后就可以无痛的使用 ES6 了&＃xff0c;之后被各种 undefined 的报错无情打脸。一句话概括, babel 的编译不会做 polyfill。那么 polyfill 是指什么呢? 翻译: 一种用于衣物、床具等的填充材料

const foo &＃61; (a, b) &＃61;> {return Object.assign(a, b); };

当我们写出上面这样的代码&＃xff0c;交给 babel 编译时&＃xff0c;我们得到了&＃xff1a;

"use strict";var foo &＃61; function foo(a, b) {return Object.assign(a, b);};

箭头 function 被编译成了普通函数&＃xff0c;但丫的 Object.assign 还没变身&＃xff0c;而它作为 ES6 的新方法&＃xff0c;并不能在IE9等浏览器上。为什么不把 Object.assign 编译成 (Object.assign||function() { /*...*/}) 这样的替代方法呢&＃xff1f;好问题&＃xff01;编译为了保证正确的语义&＃xff0c;只转换语法而不是去增加或修改原有的属性和方法。所以 babel 不处理 Object.assign 反倒是最正确的做法。而处理这些方法的方案则称为 polyfill。

babel-plugin-transform-xxx

这个问题最原始解决思路是缺什么补什么&＃xff0c;babel 提供了一系列 transform 的插件来解决这个问题&＃xff0c;例如针对 Object.assign&＃xff0c;我们可以使用 babel-plugin-transform-object-assign&＃xff1a;

npm i babel-plugin-transform-object-assign# in .babelrc {"presets": ["latest"],"plugins": ["transform-object-assign"] }

方便你尝试&＃xff0c;这里准备了一些测试的代码。编译之前的代码&＃xff0c;我们得到了&＃xff1a;

var _extends &＃61; Object.assign || function (target) { for (var i &＃61; 1; i source &＃61; arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] &＃61; source[key]; } } } return target; };var foo &＃61; exports.foo &＃61; function foo(a, b) {return _extends(a, b); };

babel-plugin-transform-object-assign 在我们用到 Object.assign 方法之前使用ES5或更早的写法替换了。看上去效果不错&＃xff0c;但细细考究一下会发现这样的问题&＃xff1a;

// another.js export const bar &＃61; (a, b) &＃61;> Object.assign(a, b);// index.js import { bar } from &＃39;./another&＃39;;export const foo &＃61; (a, b) &＃61;> Object.assign(a, b);

被编译成了&＃xff1a;

/***/ index.js: /***/ (function(module, exports, __webpack_require__) {"use strict";Object.defineProperty(exports, "__esModule", {value: true }); exports.foo &＃61; undefined;var _extends &＃61; Object.assign || function (target) { for (var i &＃61; 1; i source &＃61; arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] &＃61; source[key]; } } } return target; };var _another &＃61; __webpack_require__(212);var foo &＃61; exports.foo &＃61; function foo(a, b) {return _extends(a, b); };/***/ }),/***/ another.js: /***/ (function(module, exports, __webpack_require__) {"use strict";Object.defineProperty(exports, "__esModule", {value: true });var _extends &＃61; Object.assign || function (target) { for (var i &＃61; 1; i source &＃61; arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] &＃61; source[key]; } } } return target; };var bar &＃61; exports.bar &＃61; function bar(a, b) {return _extends(a, b); };/***/ })

plugin-transform 的引用是 module 级别的&＃xff0c;意味着在多个 module 使用时会重复的引用&＃xff0c;这在多文件的项目里可能带来灾难。且也不想一个个的去添加需要用的 plugin&＃xff0c;如果能自动引入该多好。

babel-runtime & babel-plugin-transform-runtime

前面提到问题主要在于方法的引入方式是内联的&＃xff0c;直接插入了一行代码从而无法优化。鉴于这样的考虑&＃xff0c;babel 提供了 babel-plugin-transform-runtime&＃xff0c;从一个统一的地方 core-js 自动引入对应的方法。

npm i -D babel-plugin-transform-runtime npm i babel-runtime# .babelrc {"presets": ["latest"],"plugins": ["transform-runtime"] }

安装开发时的依赖 babel-plugin-transform-runtime。
安装生产环境的依赖 babel-runtime (是否要在生产环境也依赖它取决于你发布代码的方式&＃xff0c;简单点直接放在 dependency 里总没错)

一切就绪&＃xff0c;编译时它会自动引入你用到的方法。但自动就意味着不一定精确

export const foo &＃61; (a, b) &＃61;> Object.assign(a, b);export const bar &＃61; (a, b) &＃61;> {const o &＃61; Object;const c &＃61; [1, 2, 3].includes(3);return c && o.assign(a, b); };

会编译成&＃xff1a;

var _assign &＃61; __webpack_require__(214); var _assign2 &＃61; _interopRequireDefault(_assign);function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }var foo &＃61; exports.foo &＃61; function foo(a, b) {return (0, _assign2.default)(a, b); };var bar &＃61; exports.bar &＃61; function bar(a, b) {var o &＃61; Object;var c &＃61; [1, 2, 3].includes(3);return c && o.assign(a, b); };

foo 中的 assign 会被替换成 require 来的方法&＃xff0c;而 bar 中这样非直接调用的方式则无能为力了。同时&＃xff0c;因为 babel-plugin-transform-runtime 依然不是全局生效的&＃xff0c;因此实例化的对象方法则不能被 polyfill&＃xff0c;比如 [1,2,3].includes 这样依赖于全局 Array.prototype.includes 的调用依然无法使用。

babel-polyfill

上面两种 polyfill 方案共有的缺陷在于作用域。因此 babel 直接提供了通过改变全局来兼容 es2015 所有方法的 babel-polyfill&＃xff0c;安装 babel-polyfill 后你只需要在main.js加一句 import &＃39;babel-polyfill&＃39; 便可引入它&＃xff0c;如果使用了 webpack 也可以直接在 entry 中添加 babel-polyfill 的入口。

import &＃39;babel-polyfill&＃39;;export const foo &＃61; (a, b) &＃61;> Object.assign(a, b);

加入 babel-polyfill 后&＃xff0c;打包好的 pollyfill.js 一下子增加到了 251kb&＃xff08;未压缩&＃xff09;&＃xff0c;&＃xff08;建议感兴趣的同学把代码拉下来运行一下&＃xff0c;之后提到的所有方式也都可以看到打包结果&＃xff09;搜索一下 polyfill.js 不难找到这样的全局修改&＃xff1a;

//polyfill &＃96;$export($export.S &＃43; $export.F, &＃39;Object&＃39;, {assign: __webpack_require__(79)});

babel-polyfill 在项目代码前插入所有的 polyfill 代码&＃xff0c;为你的程序打造一个完美的 es2015 运行环境。babel 建议在网页应用程序里使用 babel-polyfill&＃xff0c;只要不在意它略有点大的体积&＃xff08;min 后 86kb&＃xff09;&＃xff0c;直接用它肯定是最稳妥的。值得注意的是&＃xff0c;因为 babel-polyfill 带来的改变是全局的&＃xff0c;所以无需多次引用&＃xff0c;也有可能因此产生冲突&＃xff0c;所以最好还是把它抽成一个 common module&＃xff0c;放在项目的 vendor 里&＃xff0c;或者干脆直接抽成一个文件放在 cdn 上。

如果你是在开发一个库或者框架&＃xff0c;那么 babel-polyfill 的体积就有点大了&＃xff0c;尤其是在你实际使用的只有一个 Object.assign 的情况下。更可怕的是对于一个库来说&＃xff0c;改变全局环境是使不得的。谁也不希望使用了你的库&＃xff0c;还附带了一家老小的 polyfill 改变了全局对象。这时不污染全局环境的 babel-plugin-transform-runtime 才是最合适的。

babel-preset-env

回到应用开发。通过babel-runtime自动识别代码引入 polyfill 来优化不太靠谱&＃xff0c;那是不是就无从优化了呢&＃xff1f;并不是。还记得 babel 推荐使用的 babel-preset-env 么&＃xff1f;它可以根据指定目标环境判断需要做哪些编译。babel-preset-env 也支持针对指定目标环境选择需要的 polyfill 了&＃xff0c;只需引入 babel-polyfill&＃xff0c;并在 babelrc 中声明 useBuiltIns&＃xff0c;babel 会将引入的 babel-polyfill 自动替换为所需的 polyfill。

targets 指定需要兼容的浏览器类型和版本,
如果用 Node.js 开发&＃xff0c;也同样可以指定 Node 的版本&＃xff0c; 也可以直接写成 "node": "current"&＃xff0c;将自动采用你当前用来运行 Babel 的 Node.js 版本
modules 用来指定模块化方式&＃xff0c;支持 AMD、UMD、SystemJS、CommonJS 等。当然在 Webpack 2/3 的时代&＃xff0c;推荐将 modules 设置为 false&＃xff0c;即交由 Webpack 来处理模块化&＃xff0c;通过其 TreeShaking 特性将有效减少打包出来的 JS 文件大小

# .babelrc {"presets": [["env", {"modules": false,"targets": {"browsers": ["last 2 versions", "safari >&＃61; 7", "IE >&＃61; 9" ],"node": "current", // 自动采用你当前用来运行 Babel 的 Node.js 版本"modules": false },"useBuiltIns": "entry", // entry usage falseinclude: []}],"stage-2"],"plugins": ["transform-vue-jsx", "transform-runtime"],"env": {"test": {"presets": ["env", "stage-2"],"plugins": ["transform-vue-jsx", "transform-es2015-modules-commonjs", "dynamic-import-node"]}} }

对比 "IE >&＃61; 9" 和 "chrome >&＃61; 59" 环境下编译后的文件大小:

Asset Size Chunks polyfill.js 252 kB 0 [emitted] [big]ie9.js 189 kB 1 [emitted]chrome.js 30.5 kB 2 [emitted] transform-runtime.js 17.3 kB 3 [emitted] transform-plugins.js 3.48 kB 4 [emitted]

在目前 IE9 的需求下能节省到将近 30%&＃xff0c;但想不到浏览器之神 chrome 也还需要 30kb 的 polyfill&＃xff0c;可能是为了修正那些 v8 的一些细小的规范问题吧。

polyfill.io

以上本应该已经够用了&＃xff0c;但本质上还是让那些愿意使用最新浏览器的优质用户们做了牺牲。聪明的你可能已经想到了一种优化方案&＃xff0c;针对浏览器来选择 polyfill。没错&＃xff01;polyfill.io 给出的一项服务。

你可以尝试在不同的浏览器下请求 https://cdn.polyfill.io/v2/polyfill.js 这个文件&＃xff0c;服务器会判断浏览器 UA 返回不同的 polyfill 文件&＃xff0c;你所要做的仅仅是在页面上引入这个文件&＃xff0c;polyfill 这件事就自动以最优雅的方式解决了。更加让人喜悦的是&＃xff0c;polyfill.io 不旦提供了 cdn 的服务&＃xff0c;也开源了自己的实现方案 polyfill-service。简单配置一下&＃xff0c;便可拥有自己的 polyfill service 了。

看上去一切都很美好&＃xff0c;但在使用之前还请你多考虑一下。polyfill.io 面对国内奇葩的浏览器环境能不能把 UA 算准&＃xff0c;如果缺失了 polyfill 还有没有什么补救方案&＃xff0c;也许都是你需要考虑的。但无论如何&＃xff0c;这是个优秀的想法和方案&＃xff0c;或许未来也会有更多的网站采用 polyfill.io 的思路的。比如 theguardian 和 redux 作者 Dan 在 create-react-app 上的提议&＃xff08;虽然没被接受哈~&＃xff09;。