babel 与 polyfill两三事

熟悉前端开发的朋友,应该对 Babel这个项目并不陌生,早在两年多以前,阮一峰大大就已经写过文章《Babel 入门教程》 对他进行了介绍,那个时候,其实Babel应该已经算得上是网红开源前端库了。这两年,Babel其实也一直在发展,我这里想说的是我看到的Babel的成长

babel-preset-env

首先是babel-preset-env,详细的介绍文档在这里:https://www.babeljs.cn/docs/plugins/preset-env/

我也并不会去介绍怎么去用这个,只是想谈谈自己的体会。我记得刚开始使用babel的时候,的确有时候会用上一些stage-2,stage-3 的特性,那时候还为了了解这些所谓的stage去看了ECMASCRIPT 新版本发布的流程,觉得也很有意思。但是虽然有意思,但是配置起来却的确繁琐,有时候,你的确需要为了配置这样一个Babel看好多相关文档,这无疑算是一个痛点了。现在好了,就如同文档里面所提到的:

在没有任何配置选项的情况下,babel-preset-env 与 babel-preset-latest(或者babel-preset-es2015,babel-preset-es2016和babel-preset-es2017一起)的行为完全相同。

babel-polyfill

为什么你这么大

我们都知道,Babel为了存心让我们配置起来更困难,故意将他的功能分拆成了两部分,其一是语法上的转化,这个默认情况下他自会帮我们处理。而另外一部分,就是新API的polyfill,需要我们引入babel-polyfill来完成。当然,我前面说,Babel是存心折腾开发者的确是开玩笑的,毕竟并不是所有的时候我们都需要polyfill的。这有点像是React项目也有两个核心包,ReactReactDOM类似。

import React from 'react';  
import ReactDOM from 'react-dom';

babel-polyfill是好东西,能够将新API作用在老的浏览器上,但是我们要注意不要滥用。比如我们随便在百度上搜索一篇文章,讲解如何使用 babel-polyfill的引用和使用,往往都会看到有这样的描述:

module.exports = {entry: ["babel-polyfill", "./app/js"]};

这样做,从功能实现上来看当然是没有错的。但是,如果我们原来的入口是

module.exports = {entry: ["./app/js"]};

那么很容易就能够发现由于入口处增加了babel-polyfill,导致webpack在处理之后,最终的到的入口核心js文件比原来增加了有100kb左右。对于这个问题,也已经有issue,不过很奇怪这位网友把issue提到了babel-loader这个项目下。

然后针对这个问题,有老外网友介绍到了transform-runtime等。但是经过我的测试,这也并不是一个很好的实践。

动态识别

为了polyfill 这件事情,其实是有两种思路可循的。第一个思路是根据浏览器缺失哪些特性来补全哪些特性,这个思路的代表是 polyfill-service,这个项目 。它能够根据浏览器的UA来判断当前浏览器缺失哪些特性,进而进行补强。但是经过我的调研,这个项目在天朝可能还存在水土不服的问题,一个很明显的事实是将安卓微信内置的QQ浏览器X5交给这个库来处理,它会认为当前的浏览器是safari,原因大概是因为UA上有safari这个字段。考虑到我们天朝还有类似微信这样很怪异的UA,我认为并不适合在当前这个时间来对此进行实践。(在这里多说两句,polyfill-service这个库和另外一个知名项目fastclick同属于英国金融时报,而最近我发现fastclick在现代浏览器上也有一些tricky的地方,在他们的issue区有能够找到一些吐槽,然而,这个库已经两年多没有人维护了)

把polyfill-service仍在一边,我们接下来说另一个思路。能不能根据我使用了多少新API,来决定我引入多少polyfill的内容呢?比如我只在我的项目中使用了ES6的set,没有使用其他新API。那么我引入polyfill的时候,能不能只引入set的polyfill呢?答案当然是可以的,这就是babel-7的新特性,没错,由于当前稳定版是babel-6,因此这个特性还处在测试阶段。但是根据我自己的测试,表现很多。

不过有趣的是,虽然还只是Beta版,Babel却将之写入了正式版的文档当中,结果当时我为了测试这个新特性,都已经测试到怀疑人生了。文档戳这里,感兴趣的同学可以去看看。总之,实际上只是对babel增加一项配置。

"useBuiltIns": "usage"

不过由于涉及到升级Babel,当时我在测试的时候,还是有些不顺的。但是一旦迁移成功,应用上useBuiltIns的这项配置,的确能够让polyfill的体积大幅度减小。

browserlist

前面的动态polyfill,的确可以让webpack生成的js文件体积更小,但是能不能再小一些呢?毕竟我们前端开发的目的就是极致的用户体验,当然可以。这个时候browserlist能够帮到我们。

关于这个话题,网路上相关的文章非常多,我就不再多谈了。

感兴趣的同学,可以看看ant-design项目中使用的browserlist。

https://github.com/ant-design/antd-tools/blob/master/lib/getBabelCommonConfig.js