depcheck 检查项目中依赖的使用情况 避免幽灵依赖的产生
什么是幽灵依赖 (幻影依赖) 形成原因
幽灵依赖是指node_modules中存在 而package.json中没有声明过的依赖 但却能够在项目的依赖树中找到并使用的模块
- Node.js 的模块解析规则： Node.js 采用了一种非传统的模块加载机制，允许模块在其父目录以及祖先目录的 node_modules 目录中查找依赖。当两个或更多的直接依赖间接依赖同一个模块但版本要求不同时，可能会在更高层级的 node_modules 目录中出现一个版本，这个版本虽未被项目直接声明，却会被依赖树中的其他模块使用，形成“幽灵依赖”。
- npm 的扁平化安装策略： 早期 npm 安装依赖时遵循树状结构，即每个依赖包的 node_modules 目录中包含其所有子依赖。后来为了减少磁盘空间占用和降低模块加载复杂度，npm 引入了扁平化（或称拉平）安装策略，使得相同模块只在最顶层的 node_modules 目录中保留一个实例。这种策略可能导致某些模块虽然未被项目直接引用，但由于被多个直接依赖共享，从而成为项目依赖树的一部分
- 间接依赖的变动 当直接依赖更新时，它们可能引入新的间接依赖或者升级已有间接依赖的版本，导致项目中出现了未经显式声明但在运行时被使用的模块版本，形成“幽灵依赖”。
幽灵依赖会导致什么问题
- 版本不确定性 由于未在项目配置中明确指定，幽灵依赖的版本控制变得困难，可能导致项目构建或运行时使用了开发者意料之外的模块版本，引发兼容性问题或行为差异。
- 安全风险： 隐藏的依赖可能包含已知漏洞，而在常规的依赖管理和审计过程中容易被忽视，增加了项目的安全风险。
- 维护困难：当出现问题时，定位和管理幽灵依赖较为困难，因为它们并不直接体现在
package.json文件中。
避免幽灵依赖的产生
- 使用package-lock.json 生成文件版本锁 记录依赖的模板和依赖树的状态 避免直接引入package.json 未声明的依赖直接使用 防止间接引入的发生
- 使用 npm list <package_name> --depth=0 等来查看依赖的层级关系
- 使用depcheck检查项目依赖的安装情况
depcheck使用
安装 npm install -g depcheck
使用 在项目目录下直接执行命令 depcheck
注意: 此插件识别的并不完全准确 需根据项目自行调整 例如@vue那几个文件就肯定是需要的
更多关于depcheck 的命令https://www.npmjs.com/package/depcheck
其他链接 https://blog.csdn.net/weixin_59816940/article/details/131395326
https://blog.csdn.net/linhieng/article/details/137358219
https://blog.csdn.net/black_cat7/article/details/133854985
