vue-cli打包产出兼容es5模式探索

Vincent1481089719271
1,305 阅读4分钟

vue-cli打包产出兼容es5模式探索

使用构建工具将业务代码打包产出成es5兼容模式的代码，是很多研发在一定工作年限下都会经历的场景。借由今天的一个机会，分享一下这次的实践经验。

认识vue-cli的这方面打包方案

先说点废话，vue是个非常优秀的框架，这毋庸置疑，但同时它自己高度封装也是一个它显著的特点，因为它需要照顾基于它的规则所培养起来的习惯，这个体现在vue生态的方方面面。就拿今天的打包问题来说，vue-cli默认已经将webpack + Babel的方案封装起来了，且在产物体积和兼容性上做了很好地平衡，但是，一旦业务需求突破了这个平衡，开发者或者负责项目架构的人就不得不从本就不多的社区经验里面探索正确的解决方案，这个时候比起社区本身互相开源的方案来说，封装了一层的vue-cli就显得很让人头皮发麻，一搜十几种解决办法，一配全都不对（或者至少不达预期），最后还得一一删除添加进来的依赖，这个过程，实际操作过的人自然懂里面的麻烦之处。

vue-cli使用的是webpack进行打包，其对于代码兼容方案使用的是Babel。其中对于兼容性解决方案，cli官方文档介绍的是这样：

image

然后就没有了！（说实话挺让人感觉无语的，毕竟来参考这里文档的人大多数还是对它底层使用的库了解不深的，以及对英文文档阅读能力有限的人）

给大家补充介绍一下

browserlist就是在各个前端工具之间共享浏览器版本信息的一个工具，比如Autoprefixer（css兼容属性的前缀处理工具）, Stylelint（代码风格检查） and babel-preset-env（对JavaScript代码进行差异性兼容的Babel工具包集合）

polyfill

紧接着浏览器兼容性的段落，就是在介绍polyfill。

再废话一点，其实从实践完的视角看参考最新的vue-cli，它们把配置的路径解释的挺清晰的，但是奈何这是要实践完，上来就需要配置的用户一般都是已经在之前创建过的vue项目中，有一些早期自带的配置方案是和文档不一致的，这部分都没有很清楚的交代

polyfill简单来说就是给原本不支持某个功能的旧版本浏览器通过补充的形式进行增加功能代码实现其对新标准的代码的支持。

最经典的就是core-js，它对于es标准下能够被补充的功能代码都在进行补充，质量非常高。

@babel/preset-env 和 @vue/babel-preset-app

@vue/babel-preset-app是基于@babel/preset-env进行进一步封装的包，能够结合browserslist和@babel/preset-env对代码进行编译和polyfill补充。

@babel/preset-env则是一个工具包，它集成了很多Babel对于新版本es的语法支持，Babel将他们封装在不同的插件包当中，比如可选链就包含在@babel/plugin-transform-optional-chaining这个插件中，Babel主要解决的是一些语法兼容。

容易踩坑的点

browserslist支持一个语法且它的默认写法就是这个

image

但是这个配置，有一个很大的问题

image

他在中国的覆盖率达不到80%（实际情况更糟糕），所以如果我们使用了default得出来的浏览器兼容情况根本不足以覆盖我们得实际情况，这里的正确写法就是标注浏览器具体版本。

配置解决

  1. 在package.json的browserslist（更具体配置截图在后面）的第一个参数直接填入chrome79，就可以实现通过Babel编译掉可选链，填入chrome44就能编译掉箭头函数，填入chrome45就能编译掉展开运算符（...），这些东西都能在mdn查到。

  2. 主动导入core-js/stable到入口文件

    1. image

  3. 检查编译产出

    1. image

    2. image

    3. 上面分别对应的是对展开运算符(...)和可选链的编译结果，对于es6方法的polyfill，则是在

    4. image

    5. 这部分需要阅读一下core-js源代码对这部分函数的polyfill，以findIndex为例

    6. image

    7. image

    8. 通过对比代码特征都能知道已经打进去了，以防万一可以搜索一下sourceMap

    9. image

最终就是上线发布去做测试了，测试反馈是问题解决了。

完事儿回过头来看

image

image

需要的配置其实非常简单。就这样吧~

avatar
文章
阅读
粉丝