使用NPM/Node/package.json修订控制和依赖关系解析

我们还没有在应用程序中将node_modules文件夹提交到修订控制。我们的构建流程和开发者指令包括在初始检查时手动运行“npm install”以安装所需的节点模块。我们的package.json文件详细说明了特定的依赖版本。使用NPM/Node/package.json修订控制和依赖关系解析

最近，我们的自动构建破了，因为一个下游依赖打破了由于最近的第三方提交，我认为这是不可能的。我们的package.json文件如下：

{ 
      "name": "test-package", 
    "description": "Test Package", 
     "version": "1.0.0", 
     "license": "UNLICENSED", 
     "private": true, 
    "repository": { "type": "svn", "url": "" }, 
    "dependencies": { 
    "extend": "3.0.0", 
    "windows-registry": "0.1.3" 
    } 
}

具体来说，我们对“Windows的注册表”版本依赖“0.1.3”，因为该模块（“参考”版本“1.2.0孩子依赖的爆发“）。从“Windows的注册表”的package.json文件的依赖关系如下：

"dependencies": { 
     "debug": "^2.2.0", 
     "ffi": "^2.0.0", 
     "ref": "^1.2.0", 
    "ref-struct": "^1.0.2", 
    "ref-union": "^1.0.0" 
}

我会假设“Windows的注册表”总是引用“裁判”包版“1.2.0”，但它是实际上拉动了版本“1.3.4”，然后是最近的“1.3.5”，这打破了我们的构建。我在package.json文件中为“ref”验证它不是版本“1.2.0”。 “ref”的package.json文件非常庞大，文件中的各个键下面有很多值，比如“[email protected]^1.2.0”。是的package.json文件中有趣的部分如下：

{ 
    /* Lots of other stuff */ 
    "_spec": "[email protected]^1.2.0", 
    "version": "1.3.4" 
}

为什么NPM不加载相同一致的可重复的依赖关系图？我们应该将node_modules提交给我们的修订控件吗？

来源

2017-09-06 jriffel73

见this SO回答：

在最简单的方面，波浪线之后的最新次要版本（中间数）相匹配。〜1.2.3将匹配所有1.2.x版本，但会错过1.3.0。

另一方面，插入符号更放松。它会将您更新到最新的主要版本（第一个数字）。^1.2.3将匹配包括1.3.0在内的任何1.x.x版本，但会在2.0.0版本上推迟。

至于你的其他问题：你一定要不提交您node_modules文件夹。您应该提交package-lock.json文件，该文件将冻结您的依赖项。该shrinkwrap命令通常用于此，但由于npm V5锁定文件默认生成

我也建议寻找到yarn，这是在管理复杂的依赖关系树更好，更快的npm兼容包管理器

最后，由于npm库或多或少执行semver，它有助于了解每个增量是什么应该打破与非重大更改的术语来表示。就你而言，如果程序包作者遵循语义版本控制，则更改应该向后兼容：

给定版本号MAJOR.MINOR。PATCH，递增：

当你做出不兼容的API改变主要版本，

当你在一个向后兼容的方式添加功能次要版本，当你做向后兼容的bug修复

补丁版本。

来源

2017-09-06 20:04:26 kuzyn

在我的程序员想要读到这样一个正则表达式的CARRET而且感觉更具体的我 - 这就是我得到的不是阅读文档更好。我想用这种说法来确保您的依赖性是一致的唯一方法是提交您的节点模块？这真的很臭，因为它很大，并在bin文件夹中包含编译的二进制文件等。有没有其他办法呢？ – jriffel73

使用NPM/Node/package.json修订控制和依赖关系解析

回答

相关问题