Nor*_*mac 5 dependency-management node.js npm gruntjs
我对 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
Run Code Online (Sandbox Code Playgroud)
在 maven 世界中,模块翻译包将被解析为单个版本,然后构建系统知道将哪个包包含到应用程序中。
在 npm 中,我发现在 node_modules 目录中创建了完整的树,按照此处描述的方法,在以下部分下: Cycles, Conflicts, and Folder Parsimony。
这里有一个相关的问题,但没有答案:npm 嵌套依赖管理。
我发现这个问题在 npm 依赖管理领域不太有意义。与maven等工具不同,js可以同时使用同一个包/工件的多个版本。
我的理解是,使用 browserify (或 requirejs) 等工具可以处理上述需要不同版本的“模块翻译”的情况。所以说真的,没有必要把树压平。既然扁平化树可能会产生版本控制冲突,那么如果 browserify 无论如何都可以处理多个版本,为什么还要这样做呢?
| 归档时间: |
|
| 查看次数: |
2203 次 |
| 最近记录: |