早前在第54期周刊中，我们有聊到现代网站的 ES5 现状，其实背后真实引申到的应该是 第三方库 的开发者。
让企业项目的开发者（开源工具的使用者）做更少的事，思考更少的边界情况，这个世界将会更加美好。———— By 不换
以上的话其实是个人的一个愿景，确实是，虽然对于设计来讲可能有些多此一举，有些麻烦，但是使用的人群更多，让更多的人用起来更好，服务更完善，用的人也就更多。
探究思路
采用参照对比的方案进行探究：
准备工作
为了方便实验，本次使用 verdaccio + docker 搭建一个本地的 npm 镜像仓库。
将测试包放在本地 npm 仓库中，只需要借助 nrm 对本地地址进行配置即可。
对照组1
把 带有
polyfill的包在项目不编译其的情况下打包分析体积。
npm包 +polyfill结合项目打包，兼容到chrome 49
对 rollup 进行配置，兼容到 chrome 49。
对 npm 包打包产物进行体积分析：共计 145.51kb
结合项目打包分析(52.7KiB)：
对照组2
npm包不加polyfill
对 rollup 进行配置
对 npm 包打包产物进行体积分析：共计 196B
结合项目打包分析(25.7KiB)：
小结
我们的试验目标都是兼容到 Chrome 49 浏览器，只不过一种是用了包本身去兼容，一种是包不兼容，项目兼容的做法。
好处是：项目本身的 polyfill 和包自己的 polyfill 不会产生重叠的 polyfill。总体上相差 2 倍。
个人观点
三方库的作者明确以下几个要求：
- 提供两个入口：带
polyfill和不带polyfill的版本让使用者选择； - 明确告知使用者，不带
polyfill的支持到什么版本，带polyfill的支持到什么版本，是不是prebundlecorejs的；
以上文章便结束了，我们下一篇文章再见！下篇预告《移动端如何优雅的解决 fixed 布局粘滞抖动的兼容性问题》