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

plugins: [
  new UglifyJsPlugin(),
  new BabelPlugin()
]

但是这样呢，有一个毛病，由于babel在最后阶段去编译比较大的文件，耗时比较长，所以建议区分下开发模式与生产模式。另外还有个更大的问题， webpack本身采用的编译器 acorn不支持对象的扩展运算符(...)以及某些还未正式成为ES标准的特性，所以。。。。。

所以如果特性用的非常超前，还是需要 babel-loader，但是 babel-loader要做专门的配置，把还在es stage阶段的代码编译成ES2017的代码，以便于 webpack本身做处理。

上面讲了这么多，我最后再总结下，在当下阶段，在tree-shaking上能够尽力的事。

尽量不写带有副作用的代码。诸如编写了立即执行函数，在函数里又使用了外部变量等。

如果对ES6语义特性要求不是特别严格，可以开启babel的loose模式，这个要根据自身项目判断，如：是否真的要不可枚举class的属性。

如果是开发JavaScript库，请使用rollup。并且提供ES6 module的版本，入口文件地址设置到package.json的module字段。

如果JavaScript库开发中，难以避免的产生各种副作用代码，可以将功能函数或者组件，打包成单独的文件或目录，以便于用户可以通过目录去加载。如有条件，也可为自己的库开发单独的webpack-loader，便于用户按需加载。

如果是工程项目开发，对于依赖的组件，只能看组件提供者是否有对应上述3、4点的优化。对于自身的代码，除1、2两点外，对于项目有极致要求的话，可以先进行打包，最终再进行编译。

如果对项目非常有把握，可以通过uglify的一些，如：pure_getters: true，删除一些强制认为不会产生副作用的代码。

故而，在当下阶段，依旧没有比较简单好用的方法，便于我们完整的进行tree-shaking。所以说，想做好一件事真难啊。不仅需要靠个人的努力，还需要考虑到历史的进程。

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