这是一个非常晚的回复。我们已经在生产中使用这个功能很长时间了,但我看到仍然有人对此感兴趣,可能需要一些帮助。所以,这里是:
当使用GitHub的dependabot(不是dependabot-preview,尽管配置文件可能相同)时:
- 在您的存储库的.github目录中创建一个dependabot.yml文件。
- 指定一个版本控制策略为increase。
它会看起来像这样(例如,npm):
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
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的更新策略,并可能切换到不同的策略。