Turbo prune --docker 与 Bun 锁文件重写问题解析基于 bun-v1-issue-12816 复现夹具的深度解读【免费下载链接】turboBuild system optimized for JavaScript and TypeScript, written in Rust项目地址: https://gitcode.com/gh_mirrors/tu/turbo本篇以 turborepo 仓库中lockfile-tests/fixtures/bun-v1-issue-12816复现夹具为核心深入讲解turbo prune --docker在 Bun 包管理器下生成的bun.lock会被bun install --frozen-lockfile重写的问题包括复现仓库结构、测试元数据meta.json的完整字段语义、端到端锁文件校验机制的底层原理以及对应的 Rust 实现依据帮助读者理解 Turbo 锁文件剪枝lockfile pruning的正确性是如何被持续验证的。背景什么是turbo prune --docker在 monorepo 中构建 Docker 镜像时一个经典痛点是镜像体积过大——因为整个仓库包括所有 workspace 的依赖都会被复制进构建上下文。Turbo 提供了turbo prune命令来解决这个问题它只保留目标 workspace及其内部依赖链所需的文件生成一个最小化的out/目录供 Docker 的COPY阶段使用。# 只保留 api 及其依赖链所需的文件 turbo prune api # 生成面向 Docker 多阶段构建的 out/json 与 out/full 两个目录 turbo prune api --docker其中默认turbo prune输出一个out/目录加上--docker后输出变为out/json包含剪枝后的package.json与锁文件和out/full包含完整源码树这是官方推荐的 Docker 构建姿势。关键点turbo prune不仅剪枝源码文件还会剪枝锁文件lockfile。也就是说Turbo 需要理解package-lock.json、pnpm-lock.yaml、yarn.lock、bun.lock等不同格式把不属于目标 workspace 依赖闭包的条目剔除输出一个精简但语义等价的锁文件保证在容器内npm ci/bun install --frozen-lockfile可以直接使用、且不会改动锁文件内容。正是这个剪枝后的锁文件必须与package.json保持同步、且被包管理器原样接受的要求催生了仓库中的lockfile-tests测试体系也留下了本文主角——bun-v1-issue-12816这个回归复现夹具。问题现场Issue 12816 描述了怎样的故障夹具目录下的 README.md 用一句话精确描述了问题Reproduction forturbo prune --dockerproducing a Bun lockfile thatbun install --frozen-lockfilerewrites after pruningapi.翻译过来即turbo prune --docker生成的 Bun 锁文件在剪枝api之后会被bun install --frozen-lockfile重写。bun install --frozen-lockfile的语义是严格按锁文件安装锁文件不得有任何变动。正常情况下如果剪枝生成的bun.lock与剪枝后的package.json集合完全一致bun 应该直接接受它并保持文件不变。而该 issue 表明剪枝输出存在不一致导致 bun 认为锁文件过时或不匹配从而主动重写锁文件。对 CI 与 Docker 构建而言这是典型的隐患锁文件被重写说明剪枝结果与bun的解析结果不一致存在锁文件漂移风险如果构建流程包含校验锁文件是否被改动的步骤如git diff --exit-code会直接失败依赖版本可能在重写过程中被意外变更破坏可复现构建。复现夹具全景一个微型 Bun monorepo该夹具是一个完整的、可独立运行的微型 monorepo目录结构如下lockfile-tests/fixtures/bun-v1-issue-12816/ ├── README.md # 问题描述 ├── bun.lock # bun 1.3.14 生成的锁文件剪枝输入 ├── meta.json # 测试元数据驱动 check-lockfiles 测试 ├── package.json # 根 workspacemonorepo ├── turbo.json # 任务配置 └── apps/ ├── api/ # 目标 workspaceprune target │ └── package.json └── front/ # 非目标 workspace应被剪掉 └── package.json根package.json定义 workspace 与包管理器根 package.json 声明了 Bun 风格的 workspace 与packageManager字段{ name: monorepo, version: 0.1.0, private: true, workspaces: [ apps/* ], devDependencies: { turbo: 2.9.15-canary.3 }, packageManager: bun1.3.14 }三个字段的语义字段值作用workspaces[apps/*]声明apps/下所有目录为 workspace 成员devDependencies.turbo2.9.15-canary.3固定复现时使用的 Turbo 版本canary 版packageManagerbun1.3.14声明包管理器及其精确版本测试框架据此准备 bun 环境两个应用 workspace制造剪枝落差apps/api/package.json依赖sequelize-cli^6.6.3一个体量不小、依赖树较深的 CLI 工具apps/front/package.json依赖eslint-config-next14.0.1同样携带庞大的 eslint 生态依赖。设计意图很清晰两个 workspace 各自携带独立的依赖闭包。当以api为剪枝目标时front及其所有依赖eslint 全家桶等都必须从锁文件中剔除只保留api的依赖闭包与根 workspace 的 devDependenciesturbo 本身。任何误留或漏删都会导致剪枝锁文件与bun的期望不一致从而触发重写。turbo.json常规任务配置夹具的 turbo.json 是典型的 Next.js 应用配置build输出.next/**、check-types、dev为 persistent 任务。它在本测试中的作用主要是让夹具看起来像一个真实的 Turbo monorepo因为turbo prune本身的正确性与任务定义无关但完整的任务配置能让测试更贴近真实项目。bun.lock剪枝前的完整锁文件夹具的 bun.lock 是 bun 1.3.14 的 JSON 格式锁文件lockfileVersion: 1包含workspaces段列出根 workspacemonorepo、apps/api、apps/front三个工作区及其直接依赖声明packages段以包名: [版本, 路径, 依赖信息, 完整性哈希]四元组形式列出全部依赖条目例如sequelize-cli: [sequelize-cli6.6.5, , { dependencies: { fs-extra: ^9.1.0, js-beautify: 1.15.4, lodash: ^4.17.21, umzug: ^2.3.0, yargs: ^16.2.0 } }, sha512-DqyISCULOaEbTMrRQH4YvcUWeOC1XDiSKcjsC6TfAnT7W837mNkChJhtB/Z4FdCFHRCojmiP7zsrA4pARmacA]以及大量嵌套条目如isaacs/cliui/string-width: [string-width5.1.2, ...]体现 bun 锁文件中嵌套依赖以作用域键形式平铺的特点。这些细节正是 Bun 锁文件剪枝算法需要正确处理的部分——从 Rust 测试注释见下文可知Turbo 需要保留嵌套键层级、必要时将嵌套条目提升到顶层、按 bun 的格式编码。meta.json驱动自动化测试的元数据夹具的 meta.json 是整个 lockfile-tests 体系的测试指令字段如下{ packageManager: bun, packageManagerVersion: bun1.3.14, lockfileName: bun.lock, pruneTargets: [api], docker: true }对照 check-lockfiles.ts 中定义的FixtureMeta接口第 34-51 行各字段含义为字段本夹具取值语义packageManagerbun包管理器类型可选npm/pnpm/yarn/yarn-berry/bunpackageManagerVersionbun1.3.14精确版本测试框架按它准备运行时环境lockfileNamebun.lock锁文件名用于定位与对比锁文件是否被改动pruneTargets[api]对哪些 workspace 执行turbo prunedockertrue以--docker模式运行校验out/json下的剪枝结果production未设置若为 true 则追加--production参数validateResolution未设置npm 专用追加npm ls --all深度校验expectedFailures未设置声明已知失败目标本夹具未标记说明该问题在修复后应通过端到端校验机制check-lockfiles 如何抓住这个 buglockfile-tests的核心思想见 check-lockfiles.ts 头部注释对每个夹具执行真实的turbo prune然后用真实包管理器校验剪枝后的锁文件能否被原样接受。流程如下发现夹具扫描lockfile-tests/fixtures/下所有含meta.json的目录第 158-190 行生成测试用例对每个pruneTargets生成fixture → target用例并打上docker/production等标记第 196-235 行解析 Turbo 二进制优先使用--turbo-path指定否则按../target/debug/turbo、../target/release/turbo、../target/release-turborepo/turbo顺序探测本地编译产物第 241-269 行准备包管理器环境按packageManagerVersion缓存环境——非 bun 走corepack preparebun 则通过bun.sh/install脚本安装精确版本到临时目录见 runners/local.ts 第 195-239 行复制夹具并 git init把夹具整体复制到临时目录并提交一次初始 committurbo prune需要 git 上下文见第 432-443 行执行剪枝运行turbo prune api --docker第 460-466 行校验剪枝锁文件在out/json下执行对应包管理器的校验命令第 483-511 行。bun 的校验命令如何证明锁文件被重写在 runners/local.ts 第 146-151 行bun 的校验命令定义为case bun: { return { command: bun install --frozen-lockfile, env: { BUN_CONFIG_SKIP_INSTALL_PACKAGES: 1 } }; }解读bun install --frozen-lockfile严格锁文件安装BUN_CONFIG_SKIP_INSTALL_PACKAGES1跳过实际的包下载临时目录里也没有缓存可下把校验聚焦在锁文件与 package.json 的一致性这一层校验成功的判定runLockfileValidation第 313-364 行命令退出码为 0 即通过。关键设计在verifyLockfileUnchanged对于yarn-berry等模式框架还会读取校验前后锁文件的字节内容并对比第 343-361 行一旦发现锁文件被包管理器改动就报错Lockfile validation changed bun.lock. The lockfile is not valid for the current package.json files.。这正是 Issue 12816 场景的自动化表达——剪枝后的锁文件若被 bun 重写说明剪枝结果无效。此外整个测试体系还有一层前提自检validateFixture第 268-311 行先对未剪枝的原始夹具执行同样的校验确保夹具本身的 package.json 与 bun.lock 是自洽的避免把夹具自身就坏误判为prune 剪坏了。剪枝实现原理Rust 侧的依据turbo prune的锁文件剪枝逻辑实现在 Rust crateturborepo-lockfiles中。Bun 锁文件的解析、剪枝与编码对应 crates/turborepo-lockfiles/src/bun 模块其 test.rs 中的测试注释直接印证了本夹具涉及的几类复杂场景单 workspace 剪枝必须保留嵌套键层级test.rs 第 1200 行附近bun 锁文件中依赖按作用域键嵌套平铺剪枝时不能破坏层级关系嵌套条目需要提升到顶层第 1392 行附近当依赖版本因剪枝而唯一化时嵌套条目必须被提升否则 bun 的解析会与锁文件不一致最终清扫要与 bun 的清理逻辑一致第 638-639 行overridden 依赖、冗余条目必须按 bun 自身的 clean pass 方式去除输出的编码方式必须与turbo prune写 bun.lock 的方式一致第 2489 行附近每个声明的依赖都必须以 bun 的方式解析第 2468 行附近即最邻近祖先匹配规则第 2251 行附近涉及nuxt/kit3的 pathe 解析案例。Issue 12816 恰恰暴露了这些规则中的某一环在--docker 剪枝api组合下产生偏差导致剪枝锁文件与 bun 的解析结果不一致、触发重写。这类问题难以靠人工审查发现因此仓库选择以真实包管理器做端到端黑盒校验的回归测试策略——每个修复都必须让对应夹具从expectedFailures变为真正通过。如何运行与验证前置条件本地已编译 Turbo 二进制或指定--turbo-pathNode.js tsx见 lockfile-tests/package.json网络可达bun 环境安装需要下载测试需要 bun由 runner 自动安装指定版本到临时目录。运行命令# 在 lockfile-tests 目录下 pnpm check-lockfiles # 运行全部夹具 pnpm check-lockfiles --fixture bun-v1-issue-12816 # 只运行本夹具 pnpm check-lockfiles --pm bun # 只运行 bun 相关夹具 pnpm check-lockfiles --turbo-path ./target/release/turbo # 指定 Turbo 二进制结果解读输出会按用例打印PASS/FAIL (prune)/FAIL (validation)/EXPECTED FAIL等状态check-lockfiles.ts 第 373-389 行FAIL (prune)turbo prune本身失败FAIL (validation)剪枝成功但包管理器不接受/改写了锁文件——Issue 12816 修复前本夹具即落在此状态PASS (was expected to fail!)标记为已知失败的目标意外通过提示维护者移除meta.json中的expectedFailures第 397-404 行。修复验证闭环开发者在 Rust 侧修改剪枝逻辑 →cargo build编译 → 运行pnpm check-lockfiles --fixture bun-v1-issue-12816→ 观察从FAIL (validation)变为PASS同时确认 bun.lock 在bun install --frozen-lockfile前后字节一致。总结bun-v1-issue-12816夹具虽然只有寥寥数个文件却是 Turbo 锁文件剪枝质量保障体系的一个缩影它完整串联了问题定义turbo prune --docker生成的 bun.lock 会被bun install --frozen-lockfile重写最小复现双 workspace 的 Bun monorepo配合meta.json精确声明剪枝目标api与模式docker自动化验证check-lockfilesLocalRunner用真实 bun 对剪枝产物做黑盒校验以锁文件是否被改动作为正确性判据底层实现turborepo-lockfilescrate 的 bun 模块负责解析、剪枝与编码测试注释揭示了嵌套键保留、条目提升、依赖解析规则等核心约束。对 monorepo 用户而言理解这套机制能帮助你预判turbo prune输出可能存在的坑对贡献者而言lockfile-tests是修改锁文件相关逻辑后必须运行的回归保障——新的锁文件场景都可以参照bun-v1-issue-12816的模式以夹具 meta.json 端到端校验的形式沉淀为可长期维护的测试资产。【免费下载链接】turboBuild system optimized for JavaScript and TypeScript, written in Rust项目地址: https://gitcode.com/gh_mirrors/tu/turbo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Turbo prune --docker 与 Bun 锁文件重写问题解析：基于 bun-v1-issue-12816 复现夹具的深度解读
Turbo prune --docker 与 Bun 锁文件重写问题解析基于 bun-v1-issue-12816 复现夹具的深度解读【免费下载链接】turboBuild system optimized for JavaScript and TypeScript, written in Rust项目地址: https://gitcode.com/gh_mirrors/tu/turbo本篇以 turborepo 仓库中lockfile-tests/fixtures/bun-v1-issue-12816复现夹具为核心深入讲解turbo prune --docker在 Bun 包管理器下生成的bun.lock会被bun install --frozen-lockfile重写的问题包括复现仓库结构、测试元数据meta.json的完整字段语义、端到端锁文件校验机制的底层原理以及对应的 Rust 实现依据帮助读者理解 Turbo 锁文件剪枝lockfile pruning的正确性是如何被持续验证的。背景什么是turbo prune --docker在 monorepo 中构建 Docker 镜像时一个经典痛点是镜像体积过大——因为整个仓库包括所有 workspace 的依赖都会被复制进构建上下文。Turbo 提供了turbo prune命令来解决这个问题它只保留目标 workspace及其内部依赖链所需的文件生成一个最小化的out/目录供 Docker 的COPY阶段使用。# 只保留 api 及其依赖链所需的文件 turbo prune api # 生成面向 Docker 多阶段构建的 out/json 与 out/full 两个目录 turbo prune api --docker其中默认turbo prune输出一个out/目录加上--docker后输出变为out/json包含剪枝后的package.json与锁文件和out/full包含完整源码树这是官方推荐的 Docker 构建姿势。关键点turbo prune不仅剪枝源码文件还会剪枝锁文件lockfile。也就是说Turbo 需要理解package-lock.json、pnpm-lock.yaml、yarn.lock、bun.lock等不同格式把不属于目标 workspace 依赖闭包的条目剔除输出一个精简但语义等价的锁文件保证在容器内npm ci/bun install --frozen-lockfile可以直接使用、且不会改动锁文件内容。正是这个剪枝后的锁文件必须与package.json保持同步、且被包管理器原样接受的要求催生了仓库中的lockfile-tests测试体系也留下了本文主角——bun-v1-issue-12816这个回归复现夹具。问题现场Issue 12816 描述了怎样的故障夹具目录下的 README.md 用一句话精确描述了问题Reproduction forturbo prune --dockerproducing a Bun lockfile thatbun install --frozen-lockfilerewrites after pruningapi.翻译过来即turbo prune --docker生成的 Bun 锁文件在剪枝api之后会被bun install --frozen-lockfile重写。bun install --frozen-lockfile的语义是严格按锁文件安装锁文件不得有任何变动。正常情况下如果剪枝生成的bun.lock与剪枝后的package.json集合完全一致bun 应该直接接受它并保持文件不变。而该 issue 表明剪枝输出存在不一致导致 bun 认为锁文件过时或不匹配从而主动重写锁文件。对 CI 与 Docker 构建而言这是典型的隐患锁文件被重写说明剪枝结果与bun的解析结果不一致存在锁文件漂移风险如果构建流程包含校验锁文件是否被改动的步骤如git diff --exit-code会直接失败依赖版本可能在重写过程中被意外变更破坏可复现构建。复现夹具全景一个微型 Bun monorepo该夹具是一个完整的、可独立运行的微型 monorepo目录结构如下lockfile-tests/fixtures/bun-v1-issue-12816/ ├── README.md # 问题描述 ├── bun.lock # bun 1.3.14 生成的锁文件剪枝输入 ├── meta.json # 测试元数据驱动 check-lockfiles 测试 ├── package.json # 根 workspacemonorepo ├── turbo.json # 任务配置 └── apps/ ├── api/ # 目标 workspaceprune target │ └── package.json └── front/ # 非目标 workspace应被剪掉 └── package.json根package.json定义 workspace 与包管理器根 package.json 声明了 Bun 风格的 workspace 与packageManager字段{ name: monorepo, version: 0.1.0, private: true, workspaces: [ apps/* ], devDependencies: { turbo: 2.9.15-canary.3 }, packageManager: bun1.3.14 }三个字段的语义字段值作用workspaces[apps/*]声明apps/下所有目录为 workspace 成员devDependencies.turbo2.9.15-canary.3固定复现时使用的 Turbo 版本canary 版packageManagerbun1.3.14声明包管理器及其精确版本测试框架据此准备 bun 环境两个应用 workspace制造剪枝落差apps/api/package.json依赖sequelize-cli^6.6.3一个体量不小、依赖树较深的 CLI 工具apps/front/package.json依赖eslint-config-next14.0.1同样携带庞大的 eslint 生态依赖。设计意图很清晰两个 workspace 各自携带独立的依赖闭包。当以api为剪枝目标时front及其所有依赖eslint 全家桶等都必须从锁文件中剔除只保留api的依赖闭包与根 workspace 的 devDependenciesturbo 本身。任何误留或漏删都会导致剪枝锁文件与bun的期望不一致从而触发重写。turbo.json常规任务配置夹具的 turbo.json 是典型的 Next.js 应用配置build输出.next/**、check-types、dev为 persistent 任务。它在本测试中的作用主要是让夹具看起来像一个真实的 Turbo monorepo因为turbo prune本身的正确性与任务定义无关但完整的任务配置能让测试更贴近真实项目。bun.lock剪枝前的完整锁文件夹具的 bun.lock 是 bun 1.3.14 的 JSON 格式锁文件lockfileVersion: 1包含workspaces段列出根 workspacemonorepo、apps/api、apps/front三个工作区及其直接依赖声明packages段以包名: [版本, 路径, 依赖信息, 完整性哈希]四元组形式列出全部依赖条目例如sequelize-cli: [sequelize-cli6.6.5, , { dependencies: { fs-extra: ^9.1.0, js-beautify: 1.15.4, lodash: ^4.17.21, umzug: ^2.3.0, yargs: ^16.2.0 } }, sha512-DqyISCULOaEbTMrRQH4YvcUWeOC1XDiSKcjsC6TfAnT7W837mNkChJhtB/Z4FdCFHRCojmiP7zsrA4pARmacA]以及大量嵌套条目如isaacs/cliui/string-width: [string-width5.1.2, ...]体现 bun 锁文件中嵌套依赖以作用域键形式平铺的特点。这些细节正是 Bun 锁文件剪枝算法需要正确处理的部分——从 Rust 测试注释见下文可知Turbo 需要保留嵌套键层级、必要时将嵌套条目提升到顶层、按 bun 的格式编码。meta.json驱动自动化测试的元数据夹具的 meta.json 是整个 lockfile-tests 体系的测试指令字段如下{ packageManager: bun, packageManagerVersion: bun1.3.14, lockfileName: bun.lock, pruneTargets: [api], docker: true }对照 check-lockfiles.ts 中定义的FixtureMeta接口第 34-51 行各字段含义为字段本夹具取值语义packageManagerbun包管理器类型可选npm/pnpm/yarn/yarn-berry/bunpackageManagerVersionbun1.3.14精确版本测试框架按它准备运行时环境lockfileNamebun.lock锁文件名用于定位与对比锁文件是否被改动pruneTargets[api]对哪些 workspace 执行turbo prunedockertrue以--docker模式运行校验out/json下的剪枝结果production未设置若为 true 则追加--production参数validateResolution未设置npm 专用追加npm ls --all深度校验expectedFailures未设置声明已知失败目标本夹具未标记说明该问题在修复后应通过端到端校验机制check-lockfiles 如何抓住这个 buglockfile-tests的核心思想见 check-lockfiles.ts 头部注释对每个夹具执行真实的turbo prune然后用真实包管理器校验剪枝后的锁文件能否被原样接受。流程如下发现夹具扫描lockfile-tests/fixtures/下所有含meta.json的目录第 158-190 行生成测试用例对每个pruneTargets生成fixture → target用例并打上docker/production等标记第 196-235 行解析 Turbo 二进制优先使用--turbo-path指定否则按../target/debug/turbo、../target/release/turbo、../target/release-turborepo/turbo顺序探测本地编译产物第 241-269 行准备包管理器环境按packageManagerVersion缓存环境——非 bun 走corepack preparebun 则通过bun.sh/install脚本安装精确版本到临时目录见 runners/local.ts 第 195-239 行复制夹具并 git init把夹具整体复制到临时目录并提交一次初始 committurbo prune需要 git 上下文见第 432-443 行执行剪枝运行turbo prune api --docker第 460-466 行校验剪枝锁文件在out/json下执行对应包管理器的校验命令第 483-511 行。bun 的校验命令如何证明锁文件被重写在 runners/local.ts 第 146-151 行bun 的校验命令定义为case bun: { return { command: bun install --frozen-lockfile, env: { BUN_CONFIG_SKIP_INSTALL_PACKAGES: 1 } }; }解读bun install --frozen-lockfile严格锁文件安装BUN_CONFIG_SKIP_INSTALL_PACKAGES1跳过实际的包下载临时目录里也没有缓存可下把校验聚焦在锁文件与 package.json 的一致性这一层校验成功的判定runLockfileValidation第 313-364 行命令退出码为 0 即通过。关键设计在verifyLockfileUnchanged对于yarn-berry等模式框架还会读取校验前后锁文件的字节内容并对比第 343-361 行一旦发现锁文件被包管理器改动就报错Lockfile validation changed bun.lock. The lockfile is not valid for the current package.json files.。这正是 Issue 12816 场景的自动化表达——剪枝后的锁文件若被 bun 重写说明剪枝结果无效。此外整个测试体系还有一层前提自检validateFixture第 268-311 行先对未剪枝的原始夹具执行同样的校验确保夹具本身的 package.json 与 bun.lock 是自洽的避免把夹具自身就坏误判为prune 剪坏了。剪枝实现原理Rust 侧的依据turbo prune的锁文件剪枝逻辑实现在 Rust crateturborepo-lockfiles中。Bun 锁文件的解析、剪枝与编码对应 crates/turborepo-lockfiles/src/bun 模块其 test.rs 中的测试注释直接印证了本夹具涉及的几类复杂场景单 workspace 剪枝必须保留嵌套键层级test.rs 第 1200 行附近bun 锁文件中依赖按作用域键嵌套平铺剪枝时不能破坏层级关系嵌套条目需要提升到顶层第 1392 行附近当依赖版本因剪枝而唯一化时嵌套条目必须被提升否则 bun 的解析会与锁文件不一致最终清扫要与 bun 的清理逻辑一致第 638-639 行overridden 依赖、冗余条目必须按 bun 自身的 clean pass 方式去除输出的编码方式必须与turbo prune写 bun.lock 的方式一致第 2489 行附近每个声明的依赖都必须以 bun 的方式解析第 2468 行附近即最邻近祖先匹配规则第 2251 行附近涉及nuxt/kit3的 pathe 解析案例。Issue 12816 恰恰暴露了这些规则中的某一环在--docker 剪枝api组合下产生偏差导致剪枝锁文件与 bun 的解析结果不一致、触发重写。这类问题难以靠人工审查发现因此仓库选择以真实包管理器做端到端黑盒校验的回归测试策略——每个修复都必须让对应夹具从expectedFailures变为真正通过。如何运行与验证前置条件本地已编译 Turbo 二进制或指定--turbo-pathNode.js tsx见 lockfile-tests/package.json网络可达bun 环境安装需要下载测试需要 bun由 runner 自动安装指定版本到临时目录。运行命令# 在 lockfile-tests 目录下 pnpm check-lockfiles # 运行全部夹具 pnpm check-lockfiles --fixture bun-v1-issue-12816 # 只运行本夹具 pnpm check-lockfiles --pm bun # 只运行 bun 相关夹具 pnpm check-lockfiles --turbo-path ./target/release/turbo # 指定 Turbo 二进制结果解读输出会按用例打印PASS/FAIL (prune)/FAIL (validation)/EXPECTED FAIL等状态check-lockfiles.ts 第 373-389 行FAIL (prune)turbo prune本身失败FAIL (validation)剪枝成功但包管理器不接受/改写了锁文件——Issue 12816 修复前本夹具即落在此状态PASS (was expected to fail!)标记为已知失败的目标意外通过提示维护者移除meta.json中的expectedFailures第 397-404 行。修复验证闭环开发者在 Rust 侧修改剪枝逻辑 →cargo build编译 → 运行pnpm check-lockfiles --fixture bun-v1-issue-12816→ 观察从FAIL (validation)变为PASS同时确认 bun.lock 在bun install --frozen-lockfile前后字节一致。总结bun-v1-issue-12816夹具虽然只有寥寥数个文件却是 Turbo 锁文件剪枝质量保障体系的一个缩影它完整串联了问题定义turbo prune --docker生成的 bun.lock 会被bun install --frozen-lockfile重写最小复现双 workspace 的 Bun monorepo配合meta.json精确声明剪枝目标api与模式docker自动化验证check-lockfilesLocalRunner用真实 bun 对剪枝产物做黑盒校验以锁文件是否被改动作为正确性判据底层实现turborepo-lockfilescrate 的 bun 模块负责解析、剪枝与编码测试注释揭示了嵌套键保留、条目提升、依赖解析规则等核心约束。对 monorepo 用户而言理解这套机制能帮助你预判turbo prune输出可能存在的坑对贡献者而言lockfile-tests是修改锁文件相关逻辑后必须运行的回归保障——新的锁文件场景都可以参照bun-v1-issue-12816的模式以夹具 meta.json 端到端校验的形式沉淀为可长期维护的测试资产。【免费下载链接】turboBuild system optimized for JavaScript and TypeScript, written in Rust项目地址: https://gitcode.com/gh_mirrors/tu/turbo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考