起因
最近公司接了个新项目打算使用前年的项目的框架基础开发,最后决定安排我这个菜鸟预热项目。当我克隆项目下来之后下载依赖之后一些依赖报错了,我就回想原本项目完美的收尾了为啥现在就连下载依赖都这么困难,所以打算写这篇文章。现在我的node版本是v16。下载依赖报错图片:
排查问题
从上面的图片看到我们下载依赖的时候有个commander依赖需要node版本v18+,然后我们就按照提示使用nvm将node版本切换到v18,这时候又发现下载依赖没问题了,但是我们启动的时候出现了问题,看图片:这是什么错误呢,因为 node.js V17版本中最近发布的OpenSSL3.0, 而OpenSSL3.0对允许算法和密钥大小增加了严格的限制,可能会对生态系统造成一些影响。
总结问题
现在我们得到了结果,一个是项目依赖中要求使用对应的版本下载依赖,二个是node版本17版本之后跟项目本身不匹配。如果在17版本上改可能需要做一次项目升级,那我就还是在node版本v16找问题吧。
解决办法
回看第一个图片报错信息是commander依赖需要node版本v18+,那我们找到项目哪里用到这个依赖,项目中没有用到这个依赖,那也就是依赖中用到这个依赖。那我们就要知道是哪个依赖用到了commander@v12版本。
- 在根目录运行
npm ls commander
就能知道整个项目用到commander依赖的包了。贴图出来: - 进入node_modules/mockjs看他的依赖,贴图:
- 发现这个包使用了*号,它有什么作用:它匹配任何可用的
commander
版本,包括主版本、次版本和修订版本。这意味着当运行npm install
命令时,npm 将会安装commander
的最新版本,而不考虑其具体的版本号。所以导致我们在下载依赖的时候报错了。 - 问题找到了,最后我们在项目中限制一下改依赖的版本就行但是又不能直接写死所以我的写法是:
- 意思是
resolutions
字段用于解决依赖项的版本冲突。当在resolutions
中指定依赖项及其版本范围时,npm 将会强制安装指定的版本,而不考虑范围之外的版本就完美解决该问题了。