Question

我们还没有在我们的应用程序中将node_modules文件夹提交到版本控制。我们的构建过程和开发人员指令包括在初始检出时手动运行“npm install”以安装所需的节点模块。我们的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-registry”版本“0.1.3”的依赖性因该模块的子依赖关系而破坏（“ref”版本“1.2.0”）。 “windows-registry”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-registry”总是会引用“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

请参阅this SO回答：

用最简单的术语来说，代字号与最近的次要版本（中间数字）相匹配。 ~1.2.3将匹配所有1.2.x版本，但将错过1.3.0。
另一方面，插入符号更放松。它会将您更新为最新的主要版本（第一个数字）。 ^ 1.2.3将匹配任何1.x.x版本，包括1.3.0，但将在2.0.0推迟。

至于你的其他问题：你绝对应该不提交你的node_modules文件夹。您应该提交一个package-lock.json文件，它将按原样冻结您的依赖项。 shrinkwrap命令通常用于此目的，但从npm v5开始，默认情况下会生成锁定文件

我还建议调查yarn，这是一个npm兼容的包管理器，在管理复杂的依赖关系树方面更好，更快

最后，由于npm存储库或多或少强制执行semver，因此有必要了解每个增量所谓的在破坏与非破坏方面的含义变化。在您的情况下，如果包作者遵循语义版本控制，则更改应该向后兼容：

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


当您进行不兼容的API更改时的MAJOR版本，

以向后兼容的方式添加功能时的MINOR版本，

当您进行向后兼容的错误修复时的PATCH版本。

使用NPM / Node / package.json进行版本控制和依赖性解析

1 个答案: