Dependabot 只更新锁文件。

Question

我们最近将依赖检查工具从Greenkeeper 切换到 Dependabot，然后我们发现 Dependabot 仅开启PR更改package-lock.json而package.json则保持原样。

相反地，Greenkeeper会在这两个文件上做出更改。

这是怎么回事？这种情况是否正常？或者我们在设置方面错过了什么吗？

- Johnny

---

嘿，@Johnny，你找到了一个合适的解决方案吗？ - flaky

@flaky 是的。在 dependabot 配置文件中有一个配置设置，可以强制所有更新也写入 package.json 文件中。你应该仔细查看 GitHub 的 dependabot 文档。我可能会写一篇答案来更好地解释该怎么做。 - Johnny

我很想要一个好的解释 :) Dependabot文档有时候靠谱，有时候不太行 :) - flaky

@flaky，请检查一下我的答案。 - Johnny

Answer 1

这是一个非常晚的回复。我们已经在生产中使用这个功能很长时间了，但我看到仍然有人对此感兴趣，可能需要一些帮助。所以，这里是：

当使用GitHub的dependabot（不是dependabot-preview，尽管配置文件可能相同）时：

• 在您的存储库的.github目录中创建一个dependabot.yml文件。
• 指定一个版本控制策略为increase。

它会看起来像这样（例如，npm）：

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # Always increase the version requirement
    # to match the new version.
    versioning-strategy: increase

就这样。现在，package.json和package-lock.json都已经被写入并增加了版本号。

---

这是其中的扩展逻辑。`package.json`指定了应用程序和库的“永久依赖约束”，而`package-lock.json`跟踪满足所有这些约束的一组确切版本，以避免不必要的变化。在`package.json`中经常使用的约束类型可能是“caret range”，看起来像这样：`^1.2.3`。插入符号是使其成为范围而不是确切版本规范的原因。除了允许确切版本“1.2.3”之外，它还允许“1.2.9”或“1.4.1”，但不允许“2.0.6”；dependabot通常可以满足您的`package.json`中的所有插入符号（和其他）范围，同时进行必要的升级，而无需更改任何这些相对宽松的约束。现在，被视为库而不是应用程序的软件包的默认`versioning-strategy`将是`widen`，即根据需要扩大范围。

继续前面的例子，如果 Dependabot 想要升级一个通过 caret 范围指定的库，如 "^1.2.3"（或者根本没有限制），从 "1.2.3" 升级到 "1.4.1"，Dependabot 可以不动 "package.json"，因为 "1.4.1" 已经被 "^1.2.3" 允许了。然而，如果需要进行一个主要的升级到 "2.0.6"，那么 caret 范围就必须扩大。它可能会被替换为类似于 ">=1.2.3 <=2.0.6" 的形式在 "package.json" 中。如果你的 "package.json" 非常简单（约束很少，自由度很大），在使用默认的版本策略时，Dependabot 很少需要更新 "package.json"。

但是，如果您将npm版本策略更改为“增加”，dependabot将倾向于通过增加其最小值来缩小您的caret范围。 例如，您可以在您的package.json中获得^1.4.1，它代表着“>=1.4.1 <2.0.0-0”，而不是^1.2.3，它代表着“>=1.2.3 <2.0.0-0”。

除了“widen”（实际上是指“如果需要扩大范围”）和“increase”（有点类似于“始终缩小范围以排除比我们的目标版本旧的版本”）之外，还有一个值为“increase-if-necessary”的选项，它允许增加范围，但仅在满足升级目标的情况下才会增加。如果您的package.json非常简单（约束较少，限制较宽松），您可能不会在“widen”和“increase-if-necessary”之间看到太大的区别，因为dependabot通常不会认为有必要干预您的所需范围。

对于我们中的一些人来说，教训是我们应该仔细阅读有关package.json语法的可能性，以了解我们现有的依赖要求是多么自由或具体，然后再评判dependabot的更新策略，并可能切换到不同的策略。

- Johnny

---

你能否编辑这个答案，更清楚地说明为什么设置“versioning-strategy”会导致package.json文件更新？这个设置的具体作用是什么？dependabot的文档并不清晰。 - Andy Ray

@AndyRay - 给你。 - undefined

Answer 2

我也遇到了类似的问题，可能有两个原因：

1. 在dependendabot配置中，您只需要接受package-lock.json的更新。
2. （这是对我有效的方法）在package.json文件中，如果您在键Name中使用了不正确的符号，例如我的情况是web-app，那么符号-会导致无法更新，现在我将其更改为webapp。

- Kevin Ariza

---

让我理解一下，可能有99%的npm包在它们的名称中都有一个“-”符号。如果这是问题的原因，那么这是dependabot中的一个大bug（可能已经被发现了）。 - Johnny

我说的不是这个，我指的是 package.json 文件中项目名称，例如： { "name": "ProjectN", => 这就是我所说的。 "version": "1.0.0", "description": "Web App", "main": "index.js" } 这种写法是错误的： "name" : "Project-N" - Kevin Ariza

Answer 3

文件 package-lock.json 的目标是跟踪安装的每个包的确切版本，以便产品在包维护者更新包时仍然可以以完全相同的方式进行 100% 复制。 参考链接在这里 因此，package.json 和 package-lock.json 具有不同的目的。

Dependabot 尝试推送修改后的 package-lock.json 上没有错误。

- Cláudio

---

他并没有询问关于.lock和清单文件之间差异的解释。 - flaky

这让我更好地理解了dependabot的升级方法。如果还有package.json的建议就更好了，因为仅仅升级package-lock可能会导致应用程序崩溃。 - Luyang Du