进入公司后，接手的是前辈留下的一个大项目。还好整个项目有完整的产品功能文档，但是因为项目太大太老了。包括打包慢、冗余文件过多等诸多问题。如果想快速解决这些问题，彻底重构功能，成本太高了。一个一个来了，时间成本比较大。那么在这篇文章中，就来介绍一下我是如何配合webpack对项目进行一步步分析和优化的。同时我为idea打包了一个webpack-unused-files，用于查找项目中的冗余文件。欢迎尝试和star。问题首先我们来大致看看我们有哪些问题，然后再一步步去解决。项目修改频繁，冗余文件过多。一些第三方依赖被滥用。想去掉但是不知道在哪个文件里。还是没用，但是留在package.json里，工程巨大，打包结果太大，删除多余文件耗时太长Due项目变动频繁，很多文件没有用到，也没有删除。由于项目的不断扩大只会影响我们定位功能和问题的速度，所以清理冗余文件非常重要。但是，我们很难仅凭肉眼识别依赖了哪个文件，所以不得不使用webpack来解决。1.获取项目依赖的所有文件我们看一下webpack的输出文件格式：{...chunks:[{name:'chunk-name',modules:[//每个chunk中的所有依赖文件]}]...}所以，根据这个stats.json，我们可以得到整个项目中所有的项目文件：/***Querydependentmodules*/functionfindSrcModules(){returnnewPromise((resolve,reject)=>{fs.readFile(statPath,(err,data)=>{if(err)returnconstjson=JSON.parse(data)constassetsList=json.chunksletret=[]//获取所有chunk的所有依赖文件assetsList.forEach(chunk=>{constmodules=chunk.modules.map(item=>item.name)ret=ret.concat(modules)})//移除node_modules中的文件ret=ret.filter(item=>item.indexOf('node_modules')<0)resolve(ret)})})}通过这一步，我们可以得到项目中所有打包依赖的文件。2.获取项目中的所有文件通过glob，我们可以获取所有文件：functiongetAllFilesInSrc(){constpattern='./src/**'returnnewPromise((resolve,reject)=>{glob(pattern,{nodir:true},(err,files)=>{constret=files.map(item=>{returnitem.replace('./src','.')})resolve(ret)})})}3.放两个比较文件数组，然后进行删除等操作：比较两个数组，没有出现在dependencies中的文件为冗余文件。我们可以删除findSrcModules().then(ret=>{getAllFilesInSrc().then(allFiles=>{constunUsed=allFiles.filter(item=>{returnret.indexOf(item)<0})constjoin=p=>路径。join('./src',p)unUsed.forEach(file=>{shelljs.rm(join(file))})})})第三方依赖分析根据上面冗余文件的思路，我们还可以对第三方依赖进行处理，大致思路如下，获取包括node_modules在内的所有依赖，对文件名进行拦截去重。获取所有依赖并与package.json进行对比，获取未使用的依赖并分析??对比结果，保存不想使用的依赖再次搜索stat.json，找到依赖的reson字段，获取where引用是依赖项，输出并手动替换和删除依赖项。可以说我们已经获得了所有的依赖和依赖，我们可以灵活地处理它们来得到我们想要的结果。该特性稍后也会更新到webpack-unused-files中。关于打包大小的优化让人震惊的是，由于种种原因，整个项目打包后的大小接近20M！虽然不是TOC项目，页面也实现了代码拆分和懒加载，但是作为一个“合格的前端”，这种现象必须改正（是！）。如何开始？一个一个过一遍代码，看看我们引用了哪些大的依赖，看看哪些项目太大，哪些太复杂。下面看看webpack为我提供了哪些解决方案：1.显示打包结果我们知道，webpack打包完成后，会自动在控制台显示打包结果。同时还提供了输出依赖关系和大小的功能。我们执行以下参数来显示所有依赖项并查看它们的大小。webpack--display-modules--sort-modules-bysize的结果类似这样：我们可以快速定位到最靠前的js文件或第三方依赖，并决定如何处理。2.可视化分析依赖webpack提供了一个功能，可以将所有打包后的依赖文件和关系以json格式输出：webpack--profile--json>stats.json这是我们整篇文章的基础，很多人基于这个封装了一个许多用于可视化分析的工具。可以直观的看到各种文件和chunk的依赖关系和大小，快速定位大文件和大模块。webpackanalyzewebpackchart3.优化方案通过以上两种方式，我们可以很好的定位分析内容文件和依赖关系。网上已经有很多针对包大小的优化方案。这里不再赘述，提供几个思路和参考：CommonsChunkPlugin提取公共代码dll-plugin分离大文件打包，缓存删除无用依赖（后面会提到选择性放弃部分依赖代码压缩babel-polyfillScopeHoisting打包时间的优化关于打包时间优化的文章其实很多，我们这里只是提供一些思路。我们主要的一点是，通过构建，你会发现项目中引用了大量的svg图标和国旗图标每次在静态资源处理的时候，打包的时间都会变得很慢。我们在项目中使用的svg-sprite-loader，自动svg-spirte每一个svg图标。但是我们知道这些图标一旦被引用，我们很少修改尤其是国旗图标，但是我们每次构建的时候都需要重新打包，所以我们可以把这些图标制作成svg-sprite。推荐一个预先精灵化各种svg图标并自动引用的网站：iconmoon的日常打包时间优化点externals避免打包大的第三方依赖dll-plugin预打包第三方依赖happypack多进程处理、缓存缓存和增量构建babel-loader?cacheDirectorywebpackcache:truereducebuildsearchorcompilepathaliasresolve具体打包范围includeexclude总结通过分析webpack的json输出依赖，我们可以直观得到如下数据：所有依赖文件及其大小每个依赖file是该文件引用的项目所依赖的第三方依赖。通过这些数据，我们可以轻松优化现有项目。生命不息，辗转反侧。让我们告别所有恶心的代码！原文链接：http://callmedadaxin.github.io/2018/04/13/analyse-project-with-webpack/
