不同浏览器兼容性问题 你的Tree-Shaking并没什么卵用(6)

吃了那么多亏后，我们终于明白，打包工具库、组件库，还是rollup好用，为什么呢？

它支持导出ES模块的包。

它支持程序流分析，能更加正确的判断项目本身的代码是否有副作用。

我们只要通过rollup打出两份文件，一份umd版，一份ES模块版，它们的路径分别设为 main， module的值。这样就能方便使用者进行tree-shaking。

那么问题又来了，使用者并不是用rollup打包自己的工程化项目的，由于生态不足以及代码拆分等功能限制，一般还是用webpack做工程化打包。

之前也提到了，我们可以先进行tree-shaking，再进行编译，减少编译带来的副作用，从而增加tree-shaking的效果。那么具体应该怎么做呢？

首先我们需要去掉babel-loader，然后webpack打包结束后，再执行babel编译文件。但是由于webpack项目常有多入口文件或者代码拆分等需求，我们又需要写一个配置文件，对应执行babel，这又略显麻烦。所以我们可以使用webpack的plugin，让这个环节依旧跑在webpack的打包流程中，就像 uglifyjs-webpack-babel一样，不再是以loader的形式对单个资源文件进行操作，而是在打包最后的环节进行编译。这里可能需要大家了解下webpack的 plugin机制。

关于uglifyjs-webpack-plugin，这里有一个小细节，webpack默认会带一个低版本的，可以直接用 webpack.optimize.UglifyJsPlugin别名去使用。具体可以看webpack的 相关说明

webpack =< v3.0.0 currently contains v0.4.6 of this plugin under webpack.optimize.UglifyJsPlugin as an alias. For usage of the latest version (v1.0.0), please follow the instructions below. Aliasing v1.0.0 as webpack.optimize.UglifyJsPlugin is scheduled for webpack v4.0.0

而这个 低版本的uglifyjs-webpack-plugin使用的依赖 uglifyjs也是低版本的，它没有 uglifyES6代码的能力，故而如果我们有这样的需求，需要在工程中重新 npm install uglifyjs-webpack-plugin -D，安装最新版本的 uglifyjs-webpack-plugin，重新引入它并使用。

这样之后，我们再使用webpack的babel插件进行编译代码。不同浏览器兼容性问题

问题又来了，这样的需求比较少，因此webpack和babel官方都没有这样的插件，只有一个第三方开发者开发了一个插件 babel-webpack-plugin。可惜的是这位作者已经近一年没有维护这个插件了，并且存在着一个问题，此插件不会用项目根目录下的 .babelrc文件进行babel编译。有人对此提了 issue，却也没有任何回应。不同浏览器兼容性问题

那么又没有办法，就我来写一个新的插件吧---- webpack-babel-plugin，有了它之后我们就能让webpack在最后打包文件之前进行babel编译代码了，具体如何安装使用可以点开项目查看。注意这个配置需要在 uglifyjs-webpack-plugin之后，像这样：

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-59797-6.html