@xihefeng 不会改进
而且其他包管理器早晚会在每个项目本地搞一个依赖目录的（滑稽

npm 在这里试图解决的问题是
当你的项目 P 存在依赖 A、B、C、D 时，
P 依赖 D@1
A 依赖 D@2
B 依赖 D@3
C 依赖 D@4
这种问题是要考虑的


这里能优化的是两个场景
- 一个是已经被 yarn 和 npm 做掉的，一个项目内对一个依赖有多次依赖的时候，会尽量 resolve 到同一个版本（其实新版 npm 做的比 yarn 好，能让 node_modules 更扁平，但是带来了更多的问题（滑稽
- 另一个是楼主说的 不同的项目对一个依赖要求的版本相同的时候，能不能只存一份

后面这个有点尴尬，依赖是往上不断找 node_modules 的，按道理是可以做一个 "根 node_modules"，但是
P1 P2 依赖 D@1
P3 P4 依赖 D@2
要怎么处理呢？
symlink 也不行，webpack 的 resolve.symlinks 可以使用文件的真实路径，如果这么搞，算是 break change，非常僵硬。


或者就等，真 break change，PnP 上线吧，完全由 js 来控制 resolve 依赖的行为，新的依赖布局不需要过多考虑兼容性，能有更多的操作空间。