我对 npm 有点陌生,我一直致力于将现有的构建过程转换为使用带有 npm 包管理的 grunt。我们有许多构建应用程序的内部组件。这会导致依赖关系树变得相当复杂。作为一个简化示例,请考虑:
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 .
- 是否有任何工具可以解析为单一版本?
- 我更喜欢这种方法,因此我可以使用 glob 模式将所有已解析的依赖项包含到应用程序中。
- 让系统在 npm 中解析为单一版本是不是一个坏主意?
- 当然,这可能会导致依赖项之间的版本不兼容,但是无论依赖项是系统地还是手动地解析为单一版本,这个问题都存在。还有其他潜在问题吗?
这里有一个相关问题,但没有答案:npm nested dependency management .
最佳答案
我发现这个问题在 npm 依赖管理的世界里没有多大意义。与maven等工具不同,js可以同时使用同一个包/工件的多个版本。
我的理解是使用诸如browserify(或requirejs)之类的工具可以处理上述需要不同版本的“模块翻译”的情况。所以真的,没有必要把树弄平。由于展平树可能会产生版本冲突,如果 browserify 无论如何都可以处理多个版本,为什么还要这样做呢?
关于node.js - 如何将树中的所有 npm 依赖项解析为单一版本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27363988/