前言
在现代前端开发流程中，包管理工具扮演着至关重要的角色，其中
npm和yarn是两个非常流行的JavaScript包管理工具。虽然它们为开发者提供了极大的便利，但也存在一些痛点，特别是关于"幽灵依赖（Phantom Dependencies）"和"依赖分身（Dependency Duplication）"。
幽灵依赖（Phantom Dependencies）
举例
假设： 引入依赖a，a依赖又依赖于b，逻辑上则结构就应该是
bash
> -node_module/a
> -node_module/a/node_module/b但是在扁平化展开后则变成了
bash
> -node_module/a
> -node_module/b此时我们的package.json中只有a，却可以引用b
在某些情况下，项目的依赖树中可能出现所谓的"幽灵依赖"，这是指那些在项目的package.json文件中没有直接声明，但是因为被其他依赖引入而存在项目中的依赖。这种依赖的主要问题在于：
- 难以追踪：因为这些依赖没有直接声明，在尝试了解项目使用了哪些包及其版本时，这会造成混淆。
- 版本冲突：如果两个模块分别依赖同一个包的不同版本，而npm或yarn解决方案导致某些模块实际使用的版本与其依赖的版本不一致，可能会造成意料之外的问题。
尽管yarn通过yarn.lock锁定了版本以及通过一定的策略减少了此类问题，但仍然不能完全避免。
依赖分身（Dependency Duplication）
举例
bash
> -node_module/a
> -node_module/a/node_module/b@1.0.0
> -node_module/c
> -node_module/c/node_module/b@2.0.0这时，依赖a和c分别依赖b的不同版本。
不论此刻提升@1.0.0的版本到根目录层级还是提升@2.0.0的版本到根目录层级，都会出现一个问题，将出现一个重复的依赖拷贝，这个依赖拷贝就叫作：依赖分身。
依赖分身指的是在项目的node_modules目录中，同一个依赖包存在多个不同版本的情况。这种情况可能发生的原因包括：
- 不同的依赖要求：项目中不同的模块可能依赖同一个包的不同版本。
- 扁平化机制的失败 ：虽然
yarn和较新版本的npm尝试通过依赖扁平化（将依赖尽可能安装在顶层node_modules下）来减少重复依赖的问题，但并不是所有情况都能完全扁平化，特别是当存在不兼容版本时。
这会导致以下几个问题：
- 增加项目大小：同一个包的多个版本会占用更多的磁盘空间。
- 运行时不确定性：可能导致难以预料的行为，因为不同的代码部分可能会使用同一个包的不同版本。
解决方案和建议
- 对于"幽灵依赖"，建议定期使用
npm ls或yarn list来审查项目的依赖树，确保了解所有实际使用的依赖及其来源。 - 避免"依赖分身"的一个方法是在更新或安装新依赖时认真评估版本要求，尽可能地统一依赖的版本。对于npm，可以使用
npm dedupe尝试减少重复的依赖。 - 使用现代化的工具和方法（如使用最新版本的
npm和yarn以及合理配置package.json）可以在一定程度上缓解这些问题。 - 使用pnpm 高效前端开发：解密pnpm的存储与链接
最终，无论是使用npm还是yarn，对依赖管理的合理规划和持续维护都是确保项目稳定性和性能的关键。