记一次vue-cli3下filemanager-webpack-plugin的报错和解决

附上一篇filemanager-webpack-plugin插件的使用方法：[email protected] 直接打包成zip压缩文件

前言

因为对之前项目进行再次开发时，遇到了太多因维护引起的问题（满满的心智负担，导致San值严重下降。。( ′Д`)）。

所以想尝试一下，重新git clone一次某vue项目，想从二次开发者的视角去窥探，看流程能不能顺利。果不其然，出了问题。

正文

项目是使用Vue-cli3建立的。之前本地的旧项目代码一直能够正常工作，但是重新clone一次之后，却报了错。

把项目代码重新“git clone”下来后，使用"npm i"命令安装所有依赖，然后使用“npm run serve”命令运行本地服务器，但是不能正常启动，报以下错误：

原因

项目使用了叫作filemanager-webpack-plugin的webpack插件，目的是为了在进行打包的时候，直接把打包结果dist文件夹压缩，变成dist.zip文件。

调用代码位于vue.config.js下：

const FileManagerPlugin = require('filemanager-webpack-plugin')
module.exports = {
     
     configureWebpack: {
       
         plugins: [
             new FileManagerPlugin({
       
                 onEnd: {
     
                     delete: [   
                         './dist.zip',
                     ],
                    archive: [ 
                         {
     source: './dist', destination: './dist.zip'},
                     ]
                 }
             })
         ]
     }
 };

代码的本意是想在调用“npm run build”进行生产打包的时候，生成dist.zip压缩包。

但是事实上发现，在运行“npm run serve”进行调试时，也会根据dist文件夹，去生成压缩包。而如果是从git远程库新clone下来的代码，默认是没有dist文件夹的（一般项目都会在.gitignore里，把dist文件夹设为不推送到远程库），导致filemanager-webpack-plugin因找不到dist文件夹而报错。

解决

在插件的onEnd钩子里最前面，加一句：

mkdir: ['./dist']

变成这样：

const FileManagerPlugin = require('filemanager-webpack-plugin')
module.exports = {
     
     configureWebpack: {
       
         plugins: [
             new FileManagerPlugin({
       
                 onEnd: {
     
                     mkdir: ['./dist'], // 新加的一句代码
                     delete: [   
                         './dist.zip',
                     ],
                    archive: [ 
                         {
     source: './dist', destination: './dist.zip'},
                     ]
                 }
             })
         ]
     }
 };

即在生成dist.zip压缩包之前，先自动创建一个空的dist文件夹，防止因为找不到dist文件夹而报错。这样做，也不会对生产打包造成影响，此时的dist就是包含了打包内容的正常文件夹了。

感觉以后在使用这个插件进行压缩时，不能照抄网上的教程了，得使用一下这个改进后的配置。

当然如果有更好的方法，欢迎指教。

想出解决方法的思维过程

在出现这个报错时，曾经一度怀疑是安装依赖出了问题。因为旧项目文件夹是能正常本地运行的，咋眼看去新旧项目文件夹唯一的不同，就是node_modules文件夹了。

但是无论是使用“npm i”进行正常安装，还是使用“npm ci”进行锁版安装，全都没用。最后被逼无奈，只好把旧项目文件夹里的node_modules文件夹，直接拷贝到新项目文件夹里，但是依然报出同样的错误。

在与同事一起交流探讨之后，不经意把注意力放到了dist.zip压缩包上。

因为我们是从远程库新clone下来的项目，dist.zip这个压缩文件，肯定不是我们之前推送到远程库的，那么它到底是怎么产生的？

把它删掉之后，重新运行“npm run serve”命令，发现它是在这个过程产生的。于是我开始逐渐把视角放到了“安装”之外：依赖报错，难道一定就是依赖安装得不对吗？当然不是，在调用依赖的时候，如果我们配置不当或者调用不当，不是也会报错吗？
（只是我们脑海中一直有种固有观念：能够被大众广泛使用的东西，一定做了异常处理，就算不能达到我们预想的效果，但至少也不可能报错）

这样一来原因就逐渐明朗了。既然有压缩，那必然要存在原文件夹，如果原文件夹不存在，是不是就会报错？为新项目手动添加了一个dist文件夹后，再执行“npm run serve”，果然不报错了。

那么解决办法也就清楚了，同样利用filemanager-webpack-plugin插件，我们就每次在压缩前，先给它生成一个dist文件夹，以防不测就好了。

后文

按理说 在运行“npm run serve” 的时候，我们并不想打包，这时不应该要去做压缩dist的操作。网上查到的不少相关配置教程有问题，有些违反我们的常理和预期。

这并非插件本身的错，而在于我们使用者使用得不当。如果我们对webpack以及其插件有更深入的了解的话，大概能配置出更好的自动化构建流程吧。

从解决这个异常的过程中，大概学到了：
1）依赖报错，不要光认为是“安装”这一过程出了问题。配置和使用也可能是导致异常的原因。
2）多交流，就算不能从他人身上直接得到解决办法，也许也能得到一丝灵感、或者能够获得另外一种视角。自己一人瞎想，可能就会一直在死胡同徘徊。