前言
这几天写腾讯实习生 Mini 项目的时候用上了 React 全家桶,当然同时引入了 Webpack 作为打包工具。但是开发过程中遇到一个很棘手的问题就是,React 加上 React-Router、superagent、eventproxy 这些第三方轮子一共有好几百个 module,Webpack 的打包速度极慢。这对于开发是非常不好的体验,同时效率也极低。
问题分析
我们先来看一下完全没有任何优化的时候,Webpack 的打包速度(使用了jsx和babel的loader)。
下面是我们的测试文件:
//test.js var react = require('react'); var ReactAddonsCssTransitionGroup = require('react-addons-css-transition-group'); var reactDOM = require('react-dom'); var reactRouter = require('react-router'); var superagent = require("superagent"); var eventproxy = require("eventproxy");
运行
webpack test.js
在我的2015款RMBP13,i5处理器,全SSD下,性能是这样的:
没错你没有看错,这几个第三方轮子加起来有整整668个模块,全部打包需要20多秒。
这意味着什么呢?你每次对业务代码的修改,gulp 或者 Webpack 监测到后都会重新打包,你要足足等20秒才能看到自己的修改结果。
但是需要重新打包的只有你的业务代码,这些第三方库是完全不用重新打包的,它们的存在只会拖累打包性能。所以我们要找一些方法来优化这个过程。
配置externals
Webpack 可以配置 externals 来将依赖的库指向全局变量,从而不再打包这个库,比如对于这样一个文件:
import React from 'react'; console.log(React);
如果你在 Webpack.config.js 中配置了externals:
module.exports = { externals: { 'react': 'window.React' } //其它配置忽略...... };
等于让 Webpack 知道,对于 react 这个模块就不要打包啦,直接指向 window.React 就好。不过别忘了加载 react.min.js,让全局中有 React 这个变量。
我们来看看性能,因为不用打包 React 了所以速度自然超级快,包也很小:
配置externals的缺陷
问题如果就这么简单地解决了的话,那我就没必要写这篇文章了,下面我们加一个 react 的动画库 react-addons-css-transition-group 来试一试:
import React from 'react'; import ReactAddonsCssTransitionGroup from 'react-addons-css-transition-group'; console.log(React);
对,你没有看错,我也没有截错图,新加了一个很小很小的动画库之后,性能又爆炸了。从模块数来看,一定是 Webpack 又把 react 重新打包了一遍。
我们来看一下为什么一个很小很小的动画库会导致 Webpack 又傻傻地把 react 重新打包了一遍。找到 react-addons-css-transition-group 这个模块,然后看看它是怎么写的:
// react-addons-css-transition-group模块 // 入口文件 index.js module.exports = require('react/lib/ReactCSSTransitionGroup');
这个动画模块就只有一行代码,唯一的作用就是指向 react 下面的一个子模块,我们再来看看这个子模块是怎么写的:
// react模块 // react/lib/ReactCSSTransitionGroup.js var React = require('./React'); var ReactTransitionGroup = require('./ReactTransitionGroup'); var ReactCSSTransitionGroupChild = require('./ReactCSSTransitionGroupChild'); //....剩余代码忽略
这个子模块又反回去依赖了 react 整个库的入口,这就是拖累 Webpack 的罪魁祸首。
总而言之,问题是这样产生的:
读到这里你可能会有疑问,为什么不能把这个动画库也设置到 externals 里,这样不是就不用打包了吗?
问题就在于,这个动画库并没有提供生产环境的文件,或者说这个库根本没有提供 react-addons-css-transition-group.min.js 这个文件。
这个问题不只存在于 react-addons-css-transition-group 中,对于 react 的大多数现有库来说都有这个依赖关系复杂的问题。
初级解决方法
所以对于这个问题的解决方法就是,手工打包这些 module,然后设置 externals ,让 Webpack 不再打包它们。
我们需要这样一个 lib-bundle.js 文件:
window.__LIB["react"] = require("react"); window.__LIB["react-addons-css-transition-group"] = require("react-addons-css-transition-group"); // ...其它依赖包
我们在这里把一些第三方库注册到了 window.__LIB 下,这些库可以作为底层的基础库,免于重复打包。
然后执行 webpack lib-bundle.js lib.js,得到打包好的 lib.js。然后去设置我们的 externals :
var webpack = require('webpack'); module.exports = { externals: { 'react': 'window.__LIB["react"]', 'react-addons-css-transition-group': 'window.__LIB["react-addons-css-transition-group"]', // 其它库 } //其它配置忽略...... };
这时由于 externals 的存在,Webpack 打包的时候就会避开这些模块超多,依赖关系复杂的库,把这些第三方 module 的入口指向预先打包好的 lib.js 的入口 window.__LIB,从而只打包我们的业务代码。
终极解决方法
上面我们提到的方法本质上就是一种动态链接库(dll)”的思想,这在 windows 系统下面是一种很常见的思想。一个dll包,就是一个很纯净的依赖库,它本身不能运行,是用来给你的 app 或者业务代码引用的。
同样的 Webpack 最近也新加入了这个功能:webpack.DllPlugin。使用这个功能需要把打包过程分成两步:
首先我们来打包ddl包,首先配置一个这样的 ddl.config.js:
const webpack = require('webpack'); const vendors = [ 'react', 'react-dom', 'react-router', // ...其它库 ]; module.exports = { output: { path: 'build', filename: '[name].js', library: '[name]', }, entry: { "lib": vendors, }, plugins: [ new webpack.DllPlugin({ path: 'manifest.json', name: '[name]', context: __dirname, }), ], };
webpack.DllPlugin 的选项中:
运行Webpack,会输出两个文件一个是打包好的 lib.js,一个就是 manifest.json,它里面的内容大概是这样的:
{ "name": "vendor_ac51ba426d4f259b8b18", "content": { "./node_modules/react/react.js": 1, "./node_modules/react/lib/React.js": 2, "./node_modules/react/node_modules/object-assign/index.js": 3, "./node_modules/react/lib/ReactChildren.js": 4, "./node_modules/react/lib/PooledClass.js": 5, "./node_modules/react/lib/reactProdInvariant.js": 6, // ............ } }
接下来我们就可以快乐地打包业务代码啦,首先写好打包配置文件 webpack.config.js:
const webpack = require('webpack'); module.exports = { output: { path: 'build', filename: '[name].js', }, entry: { app: './src/index.js', }, plugins: [ new webpack.DllReferencePlugin({ context: __dirname, manifest: require('./manifest.json'), }), ], };
webpack.DllReferencePlugin 的选项中:
DllPlugin 本质上的做法和我们手动分离这些第三方库是一样的,但是对于包极多的应用来说,自动化明显加快了生产效率。
总结
以上就是关于彻底解决Webpack打包慢问题的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对小牛知识库的支持。
本文向大家介绍解决webpack打包速度慢的解决办法汇总,包括了解决webpack打包速度慢的解决办法汇总的使用技巧和注意事项,需要的朋友参考一下 刚开始用webpack,谈一谈解决webpack打包慢的问题的方法 技巧1 webpack在打包的时候第一次总是会做很长的准备工作,包括加载插件之类的。在刚接触webpack的时候总是webpack一下-测一下-改一下-再webpack一下,这种方式最
本文向大家介绍完美解决android 项目jar包冲突的问题,包括了完美解决android 项目jar包冲突的问题的使用技巧和注意事项,需要的朋友参考一下 大家在做开发中竟然需要用到一些三方库 或者 需要集成三方的SDK开发包,尤其是项目特别庞大的时候,引用的三方的东西特别多,那么肯定会碰到一些jar包冲突的情况。 常见的情况有以下几种 1.项目自己引用jar包重复 2.项目中jar包和三方SDK
本文向大家介绍ASP.NET第一次访问慢的完美解决方案(MVC,Web Api),包括了ASP.NET第一次访问慢的完美解决方案(MVC,Web Api)的使用技巧和注意事项,需要的朋友参考一下 问题现象 访问asp.net web项目的时候,第一次访问比较慢,当闲置一段时间后,再次访问还是会非常慢。 问题原因 这是IIS回收造成的,再次访问的时候会初始化操作,初始化需要耗费时间,所以访问会比较慢
本文向大家介绍完美解决java.lang.OutOfMemoryError处理错误的问题,包括了完美解决java.lang.OutOfMemoryError处理错误的问题的使用技巧和注意事项,需要的朋友参考一下 原因: 常见的有以下几种: 1.内存中加载的数据量过于庞大,如一次从数据库取出过多数据; 2.集合类中有对对象的引用,使用完后未清空,使得JVM不能回收; 3.代码中存在死循环或循环产生过
本文向大家介绍ECSHOP完美解决Deprecated: preg_replace()报错的问题,包括了ECSHOP完美解决Deprecated: preg_replace()报错的问题的使用技巧和注意事项,需要的朋友参考一下 随着PHP5.5 的普及,ECSHOP系统又爆出了新的错误。PHP发展到PHP5.5版本以后,有了很多细微的变化。而ECSHOP官方更新又太慢,发现这些问题后也不及时升级,
本文向大家介绍vue-cli webpack模板项目搭建及打包时路径问题的解决方法,包括了vue-cli webpack模板项目搭建及打包时路径问题的解决方法的使用技巧和注意事项,需要的朋友参考一下 这里建议刚学vue的同学第一个小案例不要使用vue-cli进行操作,待对基本的api使用的比较顺手了之后再进行vue-cli的体验比较好。本人是一名后端开发人员,接触前端时间不长,这里有说的不好的地方