使用NPM / Node / package.json进行修订控制和依赖分辨率

Question

我们尚未在应用程序中使用node_modules文件夹来修订控制。我们的构建过程和开发人员说明包括在初始退房中手动运行" NPM安装"，以安装所需的节点模块。我们的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.4"的版本，然后" 1.3.5"打破了我们构建。我在package.json文件中验证了" ref"它不是版本" 1.2.0"。" ref"的package.json文件很大，它在文件中的各个键下都有许多值，例如ref@^1.2.0"。包装的有趣部分。JSON文件如下：

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

为什么NPM不加载相同一致的可重复依赖性图？我们应该将node_modules用于我们的修订控制吗？

Answer 1

请参阅此答案：

在最简单的术语中，Tilde匹配了最新的次要版本（中间号码）。〜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更改时，
• 次要版本以向后兼容的方式添加功能时，
• 修补版本时，当您进行后退兼容错误修复时。