JavaScript 依赖锁定Dependency Pinning实战指南Pin、SemVer 范围与 Renovate 更新噪音治理【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate导读本文基于 Renovate 官方文档 dependency-pinning.md 展开。当你开始使用 Renovate 这类依赖自动化工具时面临的最大抉择往往不是要不要自动化而是要不要把package.json里的依赖从 SemVer 范围如^1.1.0改为精确锁定如1.1.0。读完本文你将掌握锁定与范围各自的适用场景与代价、锁定配合 lock file 的正确姿势以及用rangeStrategy、automerge、schedule、packageRules等 Renovate 配置把升级噪音降到最低的完整方案。什么是依赖锁定Dependency Pinning为了确保讨论在同一频道上先精确界定锁定的含义。历史上JavaScript 项目习惯在package.json中使用 SemVer 范围执行npm install foobar后package.json中通常会出现foobar: ^1.1.0。展开来说这意味着任何大于等于 1.1.0 且小于 2 的 foobar 版本。项目会自动使用后来发布的1.1.1、1.2.0、1.2.1等——也就是说你不仅会得到补丁patch更新还会得到特性minor更新。另一种范围写法是foobar: ~1.1.0表示任何大于等于 1.1.0 且小于 1.2 的 foobar 版本把范围收窄到 1.1 系列内的补丁更新。而**锁定pin**则意味着使用精确版本foobar: 1.1.0含义是只使用 1.1.0其他一概不用。在 Renovate 中是否锁定以及如何改写范围由全局配置项rangeStrategy决定。从 lib/config/options/index.ts 的源码可以看到该配置的完整取值如下取值含义源码description/ 推断auto默认由 Renovate 依据各语言/管理器自动决定最优策略pin将范围改写为精确版本即锁定bump更新时顺便提升范围下限例如^1.1.0→^1.2.0replace直接用新版本替换原范围widen扩宽范围以容纳新版本如^1.0 \|\| ^2.0常见于库项目update-lockfile只更新 lock file、不改动package.json中的范围in-range-only仅当新版本落在现有范围内时才更新这些策略并非纸上谈兵——在 lib/modules/versioning/composer/index.ts 等各语言 versioning 实现中widen、update-lockfile都有具体的范围改写算法与大量单元测试用例见composer/index.spec.ts例如^1.2widen 新版本2.0.0会改写为^1.2 || ^2.0。为什么使用范围Ranges对任何类型的项目而言使用范围的首要理由是自动获得新版本——其中可能包含安全修复。所谓自动指的是只要你运行npm install且不使用 lock file就能拿到符合 SemVer 的最新版本。Tilde 与 Caret 之争熟悉 SemVer 理论的人可能认为只需要用 tilde 范围如~1.1.0就能拿到 bug 修复而不必用 caret如^1.1.0。这在理论上成立但实践中并非如此。现实是大多数开源包不会把修复反向移植backport到旧的 minor 版本而 minor 版本本身也可能夹带修复。例如1.2.0可能既包含一个新特性也包含一个修复如果你坚持1.1.0由于1.2.0发布后不会再出现1.1.1你将永远错过这个修复。这是大多数开源包的常态。库Libraries为什么要用范围第二个理由适用于以 npm 包形式发布、被其他包require()使用的库项目。此时把所有依赖锁定通常是坏主意因为那会引入一个极窄的范围只有一个版本导致你的绝大多数下游用户node_modules中堆满重复副本。例如你把foobar锁到1.1.0另一位作者把依赖锁到1.2.2那么同时使用你们两个包的用户npm 将尝试安装两个不同版本的foobar甚至可能无法正常工作。即便两个项目都用 Renovate 持续把锁定依赖更新到最新也总会出现不同步一个包先更新、另一个后更新中间哪怕只有 30 分钟联合下游用户也会拿到重复版本。为什么锁定依赖Pinning锁定版本主要换来两个词确定性certainty与可见性visibility。当package.json中每个依赖都是锁定版本时你随时都能精确知道当前安装的是哪个版本——这对升级和出问题时的回滚都有好处。注lock file 的问题后面会专门讨论先不展开。升级锁定版本的优势设想foobar发布了一个有问题的版本1.2.0它破坏了你的一项测试如果使用默认的 caret 范围你的main分支现在就坏了——因为package.json声明任何 1.x 且大于 1.1.0 的版本都可用npm 会选择最新的1.2.0。你需要手动排查到底是哪个依赖导致的失败foobar未必是自上次测试通过以来唯一自动升级的依赖然后自己动手把它 pin 住阻止 npm 安装1.2.0。如果使用的是锁定版本main分支不会被破坏因为版本被锁在foobar1.1.0取而代之的是你会收到一个把依赖升级到foobar1.2.0的 Pull Request而它测试失败。你很清楚不要合并它可以等foobar1.2.1或之后修复后再升级。锁定让你确切知道自己运行的是什么也确切知道是什么失败了。再考虑一个更常见也更危险的场景foobar1.2.0有缺陷但没被任何自动化测试捕获使用 SemVer 范围时这个新版本迟早会被自动部署到生产环境之后你才发现错误然后需要手动逐个排查是哪个依赖惹的祸前提是你猜对方向再手动编辑package.json逐个 pin。使用锁定版本时你会收到一个等待批准的foobar1.2.0PR。你可以在合并前阅读 changelog 或亲自检查分支有机会避免把坏代码推上生产。即使你没在合并前发现故障锁定版本依然占优在生产发现问题后你可以在开发环境逐个回滚提交找到能修复问题的那个回滚然后直接 revert 那个提交foobar1.1.0→foobar1.2.0的逆操作推回main。等foobar发布1.2.1时你又会收到新 PR这次仔细检查后再合并。综上锁定依赖让构建对开发者而言更加一致、可预测。锁定的代价升级噪音锁定给开发工作流带来的最大负面影响是仓库中潜在增多的噪音每当依赖有新版本你都会收到一个 PR。你维护的仓库数量、每个仓库的依赖数量决定了这种默认方式是否让人应接不暇例如每天醒来面对 10 个新 PR。降低依赖更新的噪音依赖升级 PR 数量增多在某种程度上是锁定与可预测的必然代价但也有办法在保留大部分收益的同时削减噪音。在 Renovate 中这些手段都有对应的配置项定义于 lib/config/options/index.ts方案一PR 自动合并automerge有些依赖要么a不可能在生产环境搞出问题要么b已被你的测试完全覆盖。例如eslint几乎不可能破坏生产环境——只要构建/测试通过就没问题。此时可以为所有 lint 类包开启automerge省去每次手动批准的工作可能一觉醒来发现 5/10 个 PR 已经自动合并了。另一个适合自动合并的候选是数据库驱动比如node-postgresnpm 上的pg——前提是你的 API 有 100% 测试覆盖。此时pg的 minor/patch 更新只要通过全部测试自动合并与手动检查的效果相当。源码中automerge默认值为falseautomergeType默认值为pr可选branch、pr、pr-comment见 lib/config/options/index.ts。更完整的行为说明可参考 自动合并文档。方案二分支自动合并Branch automerging即便开启 PR 自动合并你仍可能被每个 PR 的创建/合并通知烦到。此时可以把automergeType设为branchRenovate 将创建测试分支等待测试完成测试通过则直接把提交推到main或仅当测试失败才发起 PR。这种方式的更新几乎是静默的——不产生任何通知但你自然能在main上看到每次提交。方案三调度Scheduling虽然第一时间拿到更新很爽但现实是你通常并不需要那么频繁的更新。更糟的是npm 上发布不足 72 小时的版本可以被取消发布unpublish如果锁定的版本已不存在你的构建会直接挂掉。为减少自动化更新的打扰可以考虑给 Renovate 设置调度只在周末更新每周最多更新一次包而且此时 CI 构建机通常闲置每天更新但放在午夜到凌晨 5 点之间开发者工作时不受通知打扰构建机也留给了白天的开发。schedule配置项在源码中的默认值为[at any time]lib/config/options/index.ts支持传入 cron 风格或自然语言时间段。完整语法见 调度scheduling文档。方案四分组相关包Grouping虽然为了便于排查最好每个依赖更新彼此隔离但有时噪音不值得或某些包天然属于一组例如所有babel包。可以通过packageRules配置把它们分组即使多个包同时有更新也只会生成一个合并分支。groupName、groupSlug等分组配置定义于 lib/config/options/index.ts。一个典型的配置示例{ packageRules: [ { matchPackageNames: [eslint, eslint-*], groupName: eslint packages, automerge: true }, { matchPackageNames: [babel*], groupName: babel packages, schedule: [before 6am on monday] } ] }锁定依赖与 Lock Fileyarn与npm5起都支持 lock file所以常见疑问是既然已经用了 lock file为什么还要锁定依赖这是个好问题。lock file 是 SemVer 范围或依赖锁定的绝佳伴侣因为它把锁定的层次推进到比package.json更深的依赖树。Lock File 能做什么当 lock file 与其关联的package.json保持同步时它会进一步锁定项目使用的精确依赖与子依赖让每个运行npm install或yarn install的人安装到与上次更新 lock file 的人/机器人完全相同的依赖。回到前面的例子你可以在package.json中写foobar^1.1.0同时在 lock file 中锁定1.1.0这样当有问题的foobar1.2.0发布时团队中没人会安装到它。Lock File 不能做什么一旦 lock file 与package.json失同步它就无法再保证锁定任何东西package.json将重新成为安装的事实来源。lock file 只是推迟了必然发生的问题而且它的可见性远不如package.json——它不是为人类阅读设计的内容非常稠密。如果package.json中是范围而范围内发布了会破坏构建的新版本那么即使 lock file 还在勉强维持你的package.json实质上已经处于损坏状态。好处是 lock file 会把foobar按住不动除非被迫升级坏处是你最终如何发现这个破坏最简单的情形你出于某个新特性不得不升级foobar于是运行yarn upgrade foobar然后在开发或推送 CI 时发现破坏——前提是你猜对了是foobar而不是自己的代码。另一种情形有人觉得lockfile 大概过期很久了可能漏掉关键补丁于是yarn upgrade一口气全升。diff 中必然满屏红绿直接与间接依赖版本大量变动推到 CI 后失败你得在众多变更中逐一排查甚至需要手动逐行翻看 lock file diff——如果依赖blahblah同时坏了难度还会加倍。把直接依赖版本的掌控权交给 lock file意味着你失去了知道何时发生了更新的能力还可能错过真正重要的补丁它们明明在范围内却被锁在 lock file 里停在有漏洞或有 bug 的版本上。对照同样的场景如果foobar在package.json中被锁定为1.1.0升级到1.2.0有问题的版本会通过 Renovate PR 明确地呈现给你你看到破坏就知道这个版本不行与此同时你仍可以放心升级其他依赖的重要修复甚至可以定期运行yarn upgrade获取 lockfile 中的间接依赖更新并确认一切是否通过。结论lock file 解决的不是 pinning 解决的那类 SemVer 问题两者是互补关系。因此官方一贯建议无论是否锁定直接依赖都用 lock file即便有 lock file 也建议锁定直接依赖。当然你也可以按自己的偏好配置。此外 Renovate 也欢迎社区对让 lock file 更新更可见的想法——例如你是否需要这样一个功能任何直接依赖获得范围内更新时只发一个 lockfile-only 的 PR间接/子依赖怎么办社区有一个经典观点来自 LinusU锁定只会保护你免受一小部分在很多情况下包的破坏。比如你安装了 Express 并锁定了它你只会免受糟糕的 Express 版本之害却无法应对 Express 那 30 个依赖。确实锁定只作用于直接依赖而间接依赖在 lockfile 中的总量通常远大于直接依赖比如 Express 依赖的那 30 个。锁定是否带来了更高的安全性毫无疑问。问题不在于有没有而在于这份安全是否有代价例如噪音。但 Linus 也指出虚假的安全感本身也是一种代价。别忘了还有传递信任transitive trust你需要谨慎选择直接依赖以及使用的版本——某种程度上也是因为它们如何打理自己的依赖链测试覆盖够不够、是否用 Renovate 保持更新等。所以即使 lockfile 里 90% 是间接依赖那些责任其实已经委托给了你的直接依赖比如你希望 Express 团队比自己更擅长盯紧它的依赖链。至于是否带来虚假安全感这确实无法量化回答。到底怎么选官方建议结合上述全部讨论Renovate 官方给出如下推荐任何应用Web 或 Node.js——只要不被其他包require()应锁定所有类型的依赖以获得最大的可靠性/可预测性浏览器或浏览器/Node.js 双端库——会被他人消费/require()dependencies应继续使用 SemVer 范围但devDependencies可以锁定纯 Node.js 库——可以考虑锁定全部依赖因为与浏览器相比Node.js 中应用体积/重复依赖没那么关键当然如果你的库是微型库、可能被磁盘敏感环境消费就不要这样做使用 lock file。正如前文所述锁定后依赖更新总量会高于使用范围。如果这开始困扰你就用 Renovate 规则削减数量调度更新、分组、自动合并安全的更新——这些正是 rangeStrategy、schedule、automerge、packageRules 等配置源码定义见 lib/config/options/index.ts的用武之地。相关文档与源码索引配置项完整说明configuration-options.md调度语法详解key-concepts/scheduling.md自动合并详解key-concepts/automerge.mdrangeStrategy与pin/automerge/schedule/lockFileMaintenance等配置定义lib/config/options/index.tswiden、update-lockfile等范围改写算法的实现与测试lib/modules/versioning/composer/index.ts 及对应.spec.ts锁定的默认分组行为Pin Dependencies、pin-dependencieslib/config/options/index.ts本文是一份活文档官方会在有新想法或有价值的反馈时持续更新最早更新于 2018-01-19起因是 LinusU 对 lockfile 的精辟反馈。依赖治理没有银弹在确定性、可见性与更新噪音之间找到属于你项目的平衡点才是长期可维护的关键。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
JavaScript 依赖锁定Dependency Pinning实战指南Pin、SemVer 范围与 Renovate 更新噪音治理【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate导读本文基于 Renovate 官方文档 dependency-pinning.md 展开。当你开始使用 Renovate 这类依赖自动化工具时面临的最大抉择往往不是要不要自动化而是要不要把package.json里的依赖从 SemVer 范围如^1.1.0改为精确锁定如1.1.0。读完本文你将掌握锁定与范围各自的适用场景与代价、锁定配合 lock file 的正确姿势以及用rangeStrategy、automerge、schedule、packageRules等 Renovate 配置把升级噪音降到最低的完整方案。什么是依赖锁定Dependency Pinning为了确保讨论在同一频道上先精确界定锁定的含义。历史上JavaScript 项目习惯在package.json中使用 SemVer 范围执行npm install foobar后package.json中通常会出现foobar: ^1.1.0。展开来说这意味着任何大于等于 1.1.0 且小于 2 的 foobar 版本。项目会自动使用后来发布的1.1.1、1.2.0、1.2.1等——也就是说你不仅会得到补丁patch更新还会得到特性minor更新。另一种范围写法是foobar: ~1.1.0表示任何大于等于 1.1.0 且小于 1.2 的 foobar 版本把范围收窄到 1.1 系列内的补丁更新。而**锁定pin**则意味着使用精确版本foobar: 1.1.0含义是只使用 1.1.0其他一概不用。在 Renovate 中是否锁定以及如何改写范围由全局配置项rangeStrategy决定。从 lib/config/options/index.ts 的源码可以看到该配置的完整取值如下取值含义源码description/ 推断auto默认由 Renovate 依据各语言/管理器自动决定最优策略pin将范围改写为精确版本即锁定bump更新时顺便提升范围下限例如^1.1.0→^1.2.0replace直接用新版本替换原范围widen扩宽范围以容纳新版本如^1.0 \|\| ^2.0常见于库项目update-lockfile只更新 lock file、不改动package.json中的范围in-range-only仅当新版本落在现有范围内时才更新这些策略并非纸上谈兵——在 lib/modules/versioning/composer/index.ts 等各语言 versioning 实现中widen、update-lockfile都有具体的范围改写算法与大量单元测试用例见composer/index.spec.ts例如^1.2widen 新版本2.0.0会改写为^1.2 || ^2.0。为什么使用范围Ranges对任何类型的项目而言使用范围的首要理由是自动获得新版本——其中可能包含安全修复。所谓自动指的是只要你运行npm install且不使用 lock file就能拿到符合 SemVer 的最新版本。Tilde 与 Caret 之争熟悉 SemVer 理论的人可能认为只需要用 tilde 范围如~1.1.0就能拿到 bug 修复而不必用 caret如^1.1.0。这在理论上成立但实践中并非如此。现实是大多数开源包不会把修复反向移植backport到旧的 minor 版本而 minor 版本本身也可能夹带修复。例如1.2.0可能既包含一个新特性也包含一个修复如果你坚持1.1.0由于1.2.0发布后不会再出现1.1.1你将永远错过这个修复。这是大多数开源包的常态。库Libraries为什么要用范围第二个理由适用于以 npm 包形式发布、被其他包require()使用的库项目。此时把所有依赖锁定通常是坏主意因为那会引入一个极窄的范围只有一个版本导致你的绝大多数下游用户node_modules中堆满重复副本。例如你把foobar锁到1.1.0另一位作者把依赖锁到1.2.2那么同时使用你们两个包的用户npm 将尝试安装两个不同版本的foobar甚至可能无法正常工作。即便两个项目都用 Renovate 持续把锁定依赖更新到最新也总会出现不同步一个包先更新、另一个后更新中间哪怕只有 30 分钟联合下游用户也会拿到重复版本。为什么锁定依赖Pinning锁定版本主要换来两个词确定性certainty与可见性visibility。当package.json中每个依赖都是锁定版本时你随时都能精确知道当前安装的是哪个版本——这对升级和出问题时的回滚都有好处。注lock file 的问题后面会专门讨论先不展开。升级锁定版本的优势设想foobar发布了一个有问题的版本1.2.0它破坏了你的一项测试如果使用默认的 caret 范围你的main分支现在就坏了——因为package.json声明任何 1.x 且大于 1.1.0 的版本都可用npm 会选择最新的1.2.0。你需要手动排查到底是哪个依赖导致的失败foobar未必是自上次测试通过以来唯一自动升级的依赖然后自己动手把它 pin 住阻止 npm 安装1.2.0。如果使用的是锁定版本main分支不会被破坏因为版本被锁在foobar1.1.0取而代之的是你会收到一个把依赖升级到foobar1.2.0的 Pull Request而它测试失败。你很清楚不要合并它可以等foobar1.2.1或之后修复后再升级。锁定让你确切知道自己运行的是什么也确切知道是什么失败了。再考虑一个更常见也更危险的场景foobar1.2.0有缺陷但没被任何自动化测试捕获使用 SemVer 范围时这个新版本迟早会被自动部署到生产环境之后你才发现错误然后需要手动逐个排查是哪个依赖惹的祸前提是你猜对方向再手动编辑package.json逐个 pin。使用锁定版本时你会收到一个等待批准的foobar1.2.0PR。你可以在合并前阅读 changelog 或亲自检查分支有机会避免把坏代码推上生产。即使你没在合并前发现故障锁定版本依然占优在生产发现问题后你可以在开发环境逐个回滚提交找到能修复问题的那个回滚然后直接 revert 那个提交foobar1.1.0→foobar1.2.0的逆操作推回main。等foobar发布1.2.1时你又会收到新 PR这次仔细检查后再合并。综上锁定依赖让构建对开发者而言更加一致、可预测。锁定的代价升级噪音锁定给开发工作流带来的最大负面影响是仓库中潜在增多的噪音每当依赖有新版本你都会收到一个 PR。你维护的仓库数量、每个仓库的依赖数量决定了这种默认方式是否让人应接不暇例如每天醒来面对 10 个新 PR。降低依赖更新的噪音依赖升级 PR 数量增多在某种程度上是锁定与可预测的必然代价但也有办法在保留大部分收益的同时削减噪音。在 Renovate 中这些手段都有对应的配置项定义于 lib/config/options/index.ts方案一PR 自动合并automerge有些依赖要么a不可能在生产环境搞出问题要么b已被你的测试完全覆盖。例如eslint几乎不可能破坏生产环境——只要构建/测试通过就没问题。此时可以为所有 lint 类包开启automerge省去每次手动批准的工作可能一觉醒来发现 5/10 个 PR 已经自动合并了。另一个适合自动合并的候选是数据库驱动比如node-postgresnpm 上的pg——前提是你的 API 有 100% 测试覆盖。此时pg的 minor/patch 更新只要通过全部测试自动合并与手动检查的效果相当。源码中automerge默认值为falseautomergeType默认值为pr可选branch、pr、pr-comment见 lib/config/options/index.ts。更完整的行为说明可参考 自动合并文档。方案二分支自动合并Branch automerging即便开启 PR 自动合并你仍可能被每个 PR 的创建/合并通知烦到。此时可以把automergeType设为branchRenovate 将创建测试分支等待测试完成测试通过则直接把提交推到main或仅当测试失败才发起 PR。这种方式的更新几乎是静默的——不产生任何通知但你自然能在main上看到每次提交。方案三调度Scheduling虽然第一时间拿到更新很爽但现实是你通常并不需要那么频繁的更新。更糟的是npm 上发布不足 72 小时的版本可以被取消发布unpublish如果锁定的版本已不存在你的构建会直接挂掉。为减少自动化更新的打扰可以考虑给 Renovate 设置调度只在周末更新每周最多更新一次包而且此时 CI 构建机通常闲置每天更新但放在午夜到凌晨 5 点之间开发者工作时不受通知打扰构建机也留给了白天的开发。schedule配置项在源码中的默认值为[at any time]lib/config/options/index.ts支持传入 cron 风格或自然语言时间段。完整语法见 调度scheduling文档。方案四分组相关包Grouping虽然为了便于排查最好每个依赖更新彼此隔离但有时噪音不值得或某些包天然属于一组例如所有babel包。可以通过packageRules配置把它们分组即使多个包同时有更新也只会生成一个合并分支。groupName、groupSlug等分组配置定义于 lib/config/options/index.ts。一个典型的配置示例{ packageRules: [ { matchPackageNames: [eslint, eslint-*], groupName: eslint packages, automerge: true }, { matchPackageNames: [babel*], groupName: babel packages, schedule: [before 6am on monday] } ] }锁定依赖与 Lock Fileyarn与npm5起都支持 lock file所以常见疑问是既然已经用了 lock file为什么还要锁定依赖这是个好问题。lock file 是 SemVer 范围或依赖锁定的绝佳伴侣因为它把锁定的层次推进到比package.json更深的依赖树。Lock File 能做什么当 lock file 与其关联的package.json保持同步时它会进一步锁定项目使用的精确依赖与子依赖让每个运行npm install或yarn install的人安装到与上次更新 lock file 的人/机器人完全相同的依赖。回到前面的例子你可以在package.json中写foobar^1.1.0同时在 lock file 中锁定1.1.0这样当有问题的foobar1.2.0发布时团队中没人会安装到它。Lock File 不能做什么一旦 lock file 与package.json失同步它就无法再保证锁定任何东西package.json将重新成为安装的事实来源。lock file 只是推迟了必然发生的问题而且它的可见性远不如package.json——它不是为人类阅读设计的内容非常稠密。如果package.json中是范围而范围内发布了会破坏构建的新版本那么即使 lock file 还在勉强维持你的package.json实质上已经处于损坏状态。好处是 lock file 会把foobar按住不动除非被迫升级坏处是你最终如何发现这个破坏最简单的情形你出于某个新特性不得不升级foobar于是运行yarn upgrade foobar然后在开发或推送 CI 时发现破坏——前提是你猜对了是foobar而不是自己的代码。另一种情形有人觉得lockfile 大概过期很久了可能漏掉关键补丁于是yarn upgrade一口气全升。diff 中必然满屏红绿直接与间接依赖版本大量变动推到 CI 后失败你得在众多变更中逐一排查甚至需要手动逐行翻看 lock file diff——如果依赖blahblah同时坏了难度还会加倍。把直接依赖版本的掌控权交给 lock file意味着你失去了知道何时发生了更新的能力还可能错过真正重要的补丁它们明明在范围内却被锁在 lock file 里停在有漏洞或有 bug 的版本上。对照同样的场景如果foobar在package.json中被锁定为1.1.0升级到1.2.0有问题的版本会通过 Renovate PR 明确地呈现给你你看到破坏就知道这个版本不行与此同时你仍可以放心升级其他依赖的重要修复甚至可以定期运行yarn upgrade获取 lockfile 中的间接依赖更新并确认一切是否通过。结论lock file 解决的不是 pinning 解决的那类 SemVer 问题两者是互补关系。因此官方一贯建议无论是否锁定直接依赖都用 lock file即便有 lock file 也建议锁定直接依赖。当然你也可以按自己的偏好配置。此外 Renovate 也欢迎社区对让 lock file 更新更可见的想法——例如你是否需要这样一个功能任何直接依赖获得范围内更新时只发一个 lockfile-only 的 PR间接/子依赖怎么办社区有一个经典观点来自 LinusU锁定只会保护你免受一小部分在很多情况下包的破坏。比如你安装了 Express 并锁定了它你只会免受糟糕的 Express 版本之害却无法应对 Express 那 30 个依赖。确实锁定只作用于直接依赖而间接依赖在 lockfile 中的总量通常远大于直接依赖比如 Express 依赖的那 30 个。锁定是否带来了更高的安全性毫无疑问。问题不在于有没有而在于这份安全是否有代价例如噪音。但 Linus 也指出虚假的安全感本身也是一种代价。别忘了还有传递信任transitive trust你需要谨慎选择直接依赖以及使用的版本——某种程度上也是因为它们如何打理自己的依赖链测试覆盖够不够、是否用 Renovate 保持更新等。所以即使 lockfile 里 90% 是间接依赖那些责任其实已经委托给了你的直接依赖比如你希望 Express 团队比自己更擅长盯紧它的依赖链。至于是否带来虚假安全感这确实无法量化回答。到底怎么选官方建议结合上述全部讨论Renovate 官方给出如下推荐任何应用Web 或 Node.js——只要不被其他包require()应锁定所有类型的依赖以获得最大的可靠性/可预测性浏览器或浏览器/Node.js 双端库——会被他人消费/require()dependencies应继续使用 SemVer 范围但devDependencies可以锁定纯 Node.js 库——可以考虑锁定全部依赖因为与浏览器相比Node.js 中应用体积/重复依赖没那么关键当然如果你的库是微型库、可能被磁盘敏感环境消费就不要这样做使用 lock file。正如前文所述锁定后依赖更新总量会高于使用范围。如果这开始困扰你就用 Renovate 规则削减数量调度更新、分组、自动合并安全的更新——这些正是 rangeStrategy、schedule、automerge、packageRules 等配置源码定义见 lib/config/options/index.ts的用武之地。相关文档与源码索引配置项完整说明configuration-options.md调度语法详解key-concepts/scheduling.md自动合并详解key-concepts/automerge.mdrangeStrategy与pin/automerge/schedule/lockFileMaintenance等配置定义lib/config/options/index.tswiden、update-lockfile等范围改写算法的实现与测试lib/modules/versioning/composer/index.ts 及对应.spec.ts锁定的默认分组行为Pin Dependencies、pin-dependencieslib/config/options/index.ts本文是一份活文档官方会在有新想法或有价值的反馈时持续更新最早更新于 2018-01-19起因是 LinusU 对 lockfile 的精辟反馈。依赖治理没有银弹在确定性、可见性与更新噪音之间找到属于你项目的平衡点才是长期可维护的关键。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
