基于NPM / Node / package.json的修订控制与依赖解决

Question

我们还没有将应用程序中的node_modules文件夹提交到修订控制中。我们的构建过程和开发人员说明包括在初始签出时手动运行"npm“，以安装所需的节点模块。我们的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“的依赖是由于该模块的子依赖("ref”版本"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-注册表”总是引用"ref“包的版本"1.2.0”，但实际上它引入了版本"1.3.4“，最近又引入了"1.3.5”版本，破坏了我们的构建。我在package.json文件中为"ref“验证了它不是版本"1.2.0”。"ref“的package.json文件是巨大的，它在文件中的各种键下有很多值，如"ref@^1.2.0”。package.json文件的有趣部分如下：

{
  /* Lots of other stuff */
  "_spec": "ref@^1.2.0",
  "version": "1.3.4"
}

为什么NPM不加载相同一致的可重复依赖图？我们是否应该将node_modules提交到我们的修订控制中？

Answer 1

请参见这，所以回答：

从最简单的角度来说，倾斜度与最近的次要版本(中间数)相匹配。~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存储库或多或少地强制执行了符号学，因此它有助于了解每个增量在打破和不破坏更改方面的意义。在您的示例中，如果包作者遵循语义版本控制，则这些更改应该是向后兼容的：

给定版本号MAJOR.MINOR.PATCH，增加以下内容：

• 当您进行不兼容的API更改时，
• 以向后兼容的方式添加功能时的次要版本，以及
• 当您进行向后兼容的bug修复时，修补程序版本。