Question

我对npm有些新意，我一直致力于将现有的构建过程转换为使用grunt和npm包管理。我们有许多内部组件可以构建我们的应用程序。这导致依赖树变得相当复杂。作为简化示例，请考虑：

module-bcm@1.1.0
├─┬ module-help@1.0.8
│ └── module-translation@1.2.1
└─┬ module-validation@1.0.6
  └── module-translation@1.2.2

在maven世界中，模块转换包将被解析为单个版本，然后构建系统知道要包含在应用程序中的包。

在npm中，我发现在node_modules目录中创建了完整的树，遵循here, under the section: Cycles, Conflicts, and Folder Parsimony描述的方法。

是否有任何工具可以解析为单个版本？
1. 我更喜欢这种方法，因此我可以使用glob模式将所有已解析的依赖项包含到应用程序中。
让系统在npm中解析为单个版本是不是一个坏主意？
1. 当然，这可能会导致依赖关系之间出现不兼容的版本，但无论是系统地还是手动地将依赖关系解析为单个版本，都会出现这种情况。还有其他潜在问题吗？

这里有一个相关问题，但没有答案：npm nested dependency management。

Answer 1

我发现这个问题在npm依赖管理的世界中并没有多大意义。与maven等工具不同，js可以同时使用同一个包/工件的多个版本。

我的理解是使用诸如browserify（或requirejs）之类的工具，它可以处理需要不同版本的“模块转换”的上述情况。所以真的，没有必要弄平树。由于展平树可能会产生版本冲突，为什么如果browserify可以处理多个版本呢？

Answer 2

在某种程度上相关的注释上，yarn（它在后台使用npm）提供了一个选项，可以安装所有依赖项，每个软件包（yarn install --flat）仅安装一个版本。有效地生成平面依赖树。

如果需要更精细的控制，请查看selective dependency resolutions。