包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载导读本文剖析 pnpm 仓库中一份 changeset 变更.changeset/held-back-warning-release-age.md当pnpm update因minimumReleaseAge发布成熟度门禁而无法升级到更新版本时此前会误报的 held-back-update更新被滞留警告将不再触发。通过阅读本文你将理解 pnpm 升级解析器npm-resolver中滞留更新警告的判定基线baseline如何工作、minimumReleaseAge门禁的底层实现以及为什么修复后推荐 override 不再会绕过发布年龄安全策略。变更总览这个补丁改了什么该 changeset 声明了对pnpm/resolving.npm-resolver、pnpm以及pacquet三个包的patch级缺陷修复变更核心修复内容为pnpm update打印的 held-back-update 警告在minimumReleaseAge是未选取更新版本的真实原因时不再触发。警告的基线现在采用与选取过程相同的成熟度截断标准因此它不再错误地将滞留归因于你的 manifest 和已安装依赖也不再推荐一个会破坏年龄门禁的 override。该变更关联上游 issue pnpm/pnpm#13071配套测试位于 pnpm11/resolving/npm-resolver/test/heldBackUpdateWarning.test.ts。背景什么是 held-back-update 警告当用户执行pnpm update定向升级时解析器仍会尊重全新安装时会应用的首选版本preferred versions——包括 manifest 中的固定版本pin以及沿依赖链向下传播的版本约束。因此目标版本可能会合理地停留在其语义化版本区间range允许的最高版本之下。此时 pnpm 会为每个包打印一次警告通过warnOnceOnHeldBackUpdate见 index.tsfoo^2.1.3 was updated to 2.1.3, not 2.1.4, to match the version preferred by your manifests and already installed dependencies. To use 2.1.4, add an override to pnpm-workspace.yaml: overrides: { foo^2.1.3: 2.1.4 }这条警告的语义是你的 manifest 或已安装依赖按住了版本如果想强制升级请添加 override。警告中推荐的 override 被限定在正在解析的声明区间namerange内——只有恰好声明了该区间的依赖会匹配此 selector且推荐的版本必然满足该区间因此应用它永远不会违反任何使用方的版本约束源码注释对此有明确说明。然而在引入发布成熟度门禁minimumReleaseAge后出现了误报场景如果某个新版本只是因为发布年龄太短未被选取而不是被 manifest 按住这条警告依然会打印且其推荐 override 的行为会直接绕过年龄门禁削弱安全策略。minimumReleaseAge发布成熟度门禁机制minimumReleaseAge是 pnpm 的供应链安全/信任策略配置之一表示一个包版本从发布到可被采纳所需的最短时间以天为单位。相关配置项在 pnpm11/config/reader/src/Config.ts 中统一定义配置项类型说明minimumReleaseAgenumber版本必须达到的最小发布年龄天minimumReleaseAgeExcludestring[]豁免该策略的包名列表minimumReleaseAgeExcludePruneboolean是否对豁免列表进行裁剪处理minimumReleaseAgeIgnoreMissingTimeboolean当元数据缺少time字段时是否忽略该策略minimumReleaseAgeStrictboolean严格模式开关配置读取层面有两个值得注意的细节见 pnpm11/config/reader/src/index.ts当用户在配置中显式设置minimumReleaseAge时会默认将minimumReleaseAgeStrict视为true严格模式因为显式声明表明用户有明确的安全意图内建的默认minimumReleaseAge则是非严格的。在解析器内部成熟度门禁通过publishedBy截止日期选项生效publishedBy是一个Date表示版本必须在此日期之前发布才被采纳。每次实际选取版本时都会调用applyPublishedByPolicy实现于 pnpm11/resolving/npm-resolver/src/pickPackageFromMeta.ts将元数据收窄到门禁允许的版本集合若包整体被publishedByExclude豁免则保留未过滤的元数据若元数据缺少time字段则标记为需要完整元数据needsFullMetadata: true并保留原元数据否则按发布时间过滤同时保留策略显式点名的受信任版本trusted versions。minimumReleaseAge违规时返回的policyViolation代码为MINIMUM_RELEASE_AGE_VIOLATION_CODE其 reason 形如was published at ISO时间, within the minimumReleaseAge cutoff (截止日期)修复原理警告基线对齐选取基线修复前的问题根源在于警告计算基线的方式与真实选取版本的方式不一致。真实选取过程应用了publishedBy成熟度截断只有通过年龄门禁的版本参与竞争而警告的基线却使用完整元数据重跑一次理想选取于是被门禁挡下的新版本出现在基线里被误判为被 manifest 按住。修复后的warnOnceOnHeldBackUpdate逻辑index.ts分四步前置条件仅当updateRequested且 spec 类型为range时才评估if (!opts.updateRequested || spec.type ! range) return提取非 pin 选择器从 preferred versions 中剔除version类型固定版本的 selector只保留range/tag等选择器——这样pnpm audit --fix引入的漏洞惩罚等选择器也能引导基线警告永远不会推荐这些选择器避开的版本应用成熟度截断若opts.publishedBy ! null先对元数据执行applyPublishedByPolicy(meta, opts.publishedBy, opts.publishedByExclude).meta得到与真实选取相同过滤口径的基线元数据随后用非 pin 选择器在基线上重新选取首选版本按需警告仅当基线首选版本preferred存在且不同于实际选取版本pickedVersion时才打印警告。修复后当minimumReleaseAge挡住了新版本时该版本在基线中同样被年龄门禁过滤掉基线首选版本与实际选取版本一致警告便不再触发——它不再错误归因于你的 manifests 和已安装依赖也不再推荐会破坏年龄门禁的 override。此外警告的去重机制基于warnedHeldBackUpdates集合key 为${spec.name}${spec.fetchSpec}:${pickedVersion}${preferred}见 index.ts 与 index.ts即按(name, picked, preferred)三元组维度确保同一包的同一滞留情况只提示一次。测试佐证三类场景的行为边界配套测试 heldBackUpdateWarning.test.ts 用 mock 注册表setupMockAgent构造了foo包的元数据2.1.3发布于2026-01-012.1.4发布于2026-07-14测试中publishedBy截止日期设为2026-07-01因此2.1.4落在年龄门禁窗口内。三个用例精确划定了警告的行为边界minimumReleaseAge 是原因 → 不警告对应 issue #13071updateRequested: truepublishedBy门禁^2.1.3区间最终选取2.1.3。断言结果id foo2.1.3且收集到的警告中不含任何was updated to消息toStrictEqual([])。manifest 固定版本是原因 → 仍警告无门禁但preferredVersions中对foo存在2.1.3: { selectorType: version, weight: 1000 }的 pin。此时选取2.1.3并恰好收到一条was updated to 2.1.3, not 2.1.4的警告——证明修复没有把真实的被 manifest 按住场景一起静默掉。新版本在门禁下已成熟 → 仍警告当新版本2.1.4的发布时间早于publishedBy截止日期、本身已通过年龄门禁时滞留确实是 manifest/依赖造成的警告照常触发。这三个用例表明修复是精准手术只有把版本挡下的真实原因是年龄门禁时才静默其他归因manifest pin、依赖链约束的警告语义完全保留。总结与影响范围本次补丁的核心价值在于让滞留更新警告的判定基线复用真实选取时的成熟度截断从根源上消除安全策略minimumReleaseAge与更新提示之间的语义冲突。作为patch级修复它随pnpm以及共享该解析逻辑的pacquet的更新发布。对普通用户而言修复后pnpm update的输出更加可信当你看到 held-back-update 警告时可以确信版本滞留确实来自 manifest/依赖约束按警告建议添加 override 是安全的而当minimumReleaseAge挡下新版本时不会有误导性提示诱导你绕过安全门禁。如果你正在排查为什么pnpm update没升到最新版建议先检查是否配置了minimumReleaseAge并留意解析日志中的policyViolationMINIMUM_RELEASE_AGE_VIOLATION_CODE信息。赞分享包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载相关推荐dex2jar错误修复流程从报告到补丁发布dex2jar错误修复流程从报告到补丁发布 1. 错误报告收集与分类 1.1 错误报告渠道 dex2jar错误报告主要来自三个渠道GitHub Issues逆向工程开发工具pnpm self-update 修复minimumReleaseAge 成熟度截断不再让 dist-tag 更新意外降级pnpm self update 修复minimumReleaseAge 成熟度截断不再让 dist tag 更新意外降级 pnpm self update包管理器开发工具CLIRuboCop v1.79.1 补丁解析7 项误报/误修正修复与 2 项 Cop 能力增强RuboCop v1.79.1 补丁解析7 项误报/误修正修复与 2 项 Cop 能力增强 RuboCop v1.79.1 是紧随 v1.79.0 发布的维护代码质量Lint格式化静态分析开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
