pnpm 对 Cargo `[patch]` / `[replace]` 源覆盖的支持：为 Rust 工作区生成并保留 Cargo.lock

pnpm 对 Cargo[patch]/[replace]源覆盖的支持为 Rust 工作区生成并保留 Cargo.lock【免费下载链接】pnpmFast, disk space efficient package manager项目地址: https://gitcode.com/gh_mirrors/pn/pnpmpnpm 的 Cargo 依赖支持crate:依赖、cargo.enabled工作区此前无法正确处理带有路径path或 Git 来源的[patch]、[replace]源覆盖的 Rust 工作区。本次功能更新见 变更记录让pnpm install可以为这类工作区正确生成Cargo.lock并在添加、删除、更新 crate 时保留覆盖配置同时Cargo lockfile 解析会提前阻断由传递依赖声明的、pnpm 不支持的 Git 传输助手transport helper避免解析过程执行不可信的可执行文件。读完本文你将掌握 pnpm 在何种条件下接管 Cargo 解析、源覆盖如何被检测与校验、以及这一特性背后的实现与测试证据。背景pnpm 如何参与 Cargo 依赖解析pnpm 在启用cargo.enabled: true的 workspace见 pnpm-workspace.yaml 配置中可以用crate:extra1这类说明符为 Cargo 清单添加 Rust crate 依赖见 add.rs。当缺少Cargo.lock时pnpm 需要负责解析依赖并生成锁文件。其解析策略集中在 lockfile.rs 的read_or_resolve_lockfile若锁文件已存在且策略为复用UseExisting直接读取若配置了--frozen-lockfile而锁文件缺失直接报错绝不自行生成否则调用cargo metadata并检测工作区是否含有Git 依赖或source overrides[patch]/[replace]若命中则放弃 pnpm 自研的稀疏索引解析转交真实的cargo generate-lockfile来完成解析否则优先走 pnpr 服务端解析resolve_via_pnpr最后回退到 pnpm 内置的 cargo-resolver。也就是说source overrides 与 git 依赖是触发「委托 Cargo 本体解析」的两类关键信号这正是本次变更的核心逻辑。理解 Cargo 的[patch]与[replace]源覆盖Rust 生态中有两种在清单层面替换依赖来源的机制[patch.crates-io]推荐把某个来自 crates.io 的 crate 覆盖为本地路径或 Git 仓库例如[package] name app version 0.1.0 [dependencies] demo 0 [patch.crates-io] demo { git https://example.com/demo, rev abc123 } # 或 demo { path dep }[replace]遗留机制以精确的名称:版本键指定被替换的 crate[replace] demo:0.0.0 { path dep } # 或 demo:1.0.0 { git https://example.com/demo }两者都要求解析器具备与常规 registry 依赖不同的来源处理能力因此此前 pnpm 无法为这类工作区生成锁文件。检测逻辑has_source_overrides如何识别覆盖在 resolution.rs 的has_source_overrides中pnpm 读取工作区根目录的Cargo.toml并将其解析为 TOML 表遍历[patch]下的每一个子表如[patch.crates-io]检查顶层[replace]表只要任一覆盖表非空即判定工作区存在 source overrides无论覆盖来源是 path 还是 git。这一判定与解析解耦判定只需要清单文本不触发网络请求只有判定命中后后续cargo generate-lockfile才会真正联网解析。覆盖来源的 Git 传输校验对于每个声明了git ...的覆盖项has_override_sources会构造giturl形式的SourceId并调用git::validate_transport见 git.rs仅当 URL scheme 属于SUPPORTED_GIT_PROTOCOLS来自 pnpm-git-fetcher crate时才放行否则报错Cargo source url asks for the scheme transport, which pnpm does not fetch a git dependency over这保证了在 Cargo 运行之前ext://、ssh://等 pnpm 不支持的传输协议就会被拦截而不是等到解析中途失败或触发意外执行。委托解析resolve_with_cargo的隔离与安全当检测到 source overrides 或 git 依赖时resolve_with_cargo会强制默认 registry若配置了自定义cargo.indexUrl非 crates.io直接拒绝解析并提示「Resolving Cargo git dependencies or source overrides requires the default cargo.indexUrl. Use an existing Cargo.lock with a custom Cargo registry.」——自定义 registry 场景只能配合既有锁文件使用使用工具链 sysroot 中的cargo二进制而非 PATH 上任意 cargo以--manifest-path指向工作区Cargo.toml执行cargo generate-lockfile见 resolution_command通过GIT_ALLOW_PROTOCOL环境变量把 Git 传输白名单来自pnpm_git_fetcher::read_allowed_git_protocols传递给 Cargo使子进程的 git 抓取同样受控把.cargo/config/.cargo/config.toml中的unstable.bindeps与resolver.incompatible-rust-versions两项经校验后以--config keyvalue显式传入见 resolution_settings其余配置含[env]、git-fetch-with-cli、凭据提供器一律不进入解析进程防止 checkout 目录中不可信的可执行助手被执行支持--offline透传。解析完成后pnpm 读取工作区新生成的Cargo.lock作为结果。生成流程结束后覆盖配置仍原样保留在Cargo.toml中。覆盖在 add / remove / update 场景下的保留变更记录承诺「Adding, removing, and updating crates also preserve these overrides」。在 cargo_git_install.rs 集成测试 中可验证该行为adding_a_registry_crate_preserves_git_dependencies_and_source_overrides第 213 行对 git 依赖、git patch、path patch 三种工作区执行pnpm add crate:extra1 --lockfile-only后新锁文件既包含新增的extra含正确 checksum又保留原有的demo以及siblinggit 依赖且.cargo/config.toml不被改写lockfile_generation_preserves_legacy_path_replacements第 357 行针对遗留[replace]语法解析后锁文件同时保留被替换包带 source与替换包无 source、带replace标记的独立身份cargo check --locked --offline可成功通过failed_resolution_restores_manifest_lockfile_and_sources第 280 行当解析失败如新增的 crate 在 registry 中 404时Cargo.toml、Cargo.lock、.cargo/config.toml三者全部回滚到原状保证失败不污染工作区。此外pnpm remove与pnpm update复用同一套cargo generate-lockfile管线因此覆盖信息天然随Cargo.toml保留解析结果只反映清单当前的覆盖声明。阻止传递依赖声明的 Git 传输助手变更记录的后半句针对的是安全边界传递依赖transitive dependencies通过Cargo.toml声明的 Git 传输协议必须受控。实现上做了两道防线解析入口校验has_git_dependenciesresolution.rs 第 7-13 行提取元数据中所有 git 依赖来源并对每个来源执行validate_transport执行期环境收紧解析子进程工作目录设在工具链 sysroot避免读取 checkout 目录中的配置同时仅放行GIT_ALLOW_PROTOCOL白名单中的协议。对应测试path_patched_dependencies_cannot_execute_git_transport_helpers第 424 行一个 path 覆盖的本地依赖里声明helper { git pnpm-test://invalid.example/repository }并在 PATH 上放置伪造的git-remote-pnpm-test助手执行pnpm install --lockfile-only后安装失败且助手从未被执行报错包含transport pnpm-test not allowed。锁文件复用场景下的 Git 包落地若锁文件已存在--frozen-lockfilepnpm 不再解析而是直接解析锁文件中的 git 包并落地到 storegit 包以git-submodules-v1-commit作为 slot 标识见 git.rs 的store_slot通过生成[source.giturl...]替换块与.cargo-checksum.jsonpackage 字段为 null的方式让 Cargo 以目录源形式直接使用被钉住的 commit无需再次抓取见 git.rs 模块注释。frozen_install_vendors_versionless_git_members_and_path_dependencies第 100 行验证了冻结安装下版本号缺失的 git 成员与 path 依赖都能被正确落地且配置不被篡改。单元测试佐证覆盖检测的判定矩阵resolution/tests.rs 的root_source_overrides_are_detected_and_git_transports_are_validated给出了精确的判定矩阵Cargo.toml 片段has_source_overrides结果[workspace]false空[patch]/ 空[patch.crates-io]/ 空[replace]false[patch.crates-io] 无 git 的其它注册表false[patch.crates-io] demo { path dep }true[patch.https://example.test/index] demo { git ..., rev ... }true[replace] demo:1.0.0 { path dep }true覆盖使用git ext://...报错transport 校验失败空表判定为 false 是刻意设计无实际覆盖项时无需委托 Cargo可继续走 pnpm 自身更快的解析路径。使用前提与限制小结需要可用的 Cargo 工具链cargo/rustc可从rustc --print sysroot定位Git 覆盖要求配置cargo.indexUrl为默认的 crates.io自定义 registry 场景请使用既有Cargo.lock传递依赖声明的传输协议必须落在 pnpm 支持的白名单内如https、file、git等ext://等自定义传输会被拒绝--frozen-lockfile下锁文件缺失时不会生成而是直接报错「forbids generating」解析失败时工作区文件Cargo.toml、Cargo.lock、.cargo/config.toml会自动回滚。综上本次更新让 pnpm 在 Rust 工作区中真正补齐了「覆盖来源」场景的锁文件生成、保留与安全校验能力使其与常规 npm 依赖安装一样具备可重复、可冻结、可回滚的安装语义。【免费下载链接】pnpmFast, disk space efficient package manager项目地址: https://gitcode.com/gh_mirrors/pn/pnpm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考