fix(release): raise package size budget to 85 MiB

[qqqys]

What this PR does

Raises the prepared npm package unpacked-size safety budget from 80 MiB to 85 MiB while retaining a hard upper bound. Adds a boundary regression test that accepts a package below 85 MiB and rejects one above it.

Why it's needed

The release workflow currently fails while building the Docker sandbox because the prepared package is 84,497,689 bytes, exceeding the existing 83,886,080-byte budget. The new limit gives the current package about 4.42 MiB of headroom without removing the package-size guard.

Reviewer Test Plan

How to verify

Run the script test suite and confirm the package-size test accepts a sparse 84 MiB payload while rejecting an 85 MiB payload plus fixture overhead with an 89,128,960-byte limit. Build, bundle, and prepare the package; the current release package should pass preparation instead of failing the size guard.

Evidence (Before & After)

N/A — non-UI release guard change.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

Node.js 22; local npm build, typecheck, bundle, package preparation, and script tests.

Risk & Scope

• Main risk or tradeoff: Releases may grow up to 5 MiB larger before the safety guard blocks them.
• Not validated / out of scope: Docker execution on Linux and reducing the existing package contents.
• Breaking changes / migration notes: None.

Linked Issues

Related failing release: https://github.com/QwenLM/qwen-code/actions/runs/29110517358/job/86421715805

中文说明

本 PR 做了什么

将 npm 发布包的解压尺寸安全上限从 80 MiB 提高到 85 MiB，同时保留明确的硬上限。新增边界回归测试，验证低于 85 MiB 的包可以通过、超过上限的包会被拒绝。

为什么需要

当前发布流程在构建 Docker sandbox 时失败，因为准备后的发布包为 84,497,689 字节，超过原有的 83,886,080 字节预算。新上限为当前包保留约 4.42 MiB 余量，同时不移除包尺寸保护。

Reviewer 测试计划

如何验证

运行脚本测试套件，确认包尺寸测试允许 84 MiB 的稀疏载荷，并在 85 MiB 载荷加 fixture 开销超过 89,128,960 字节时拒绝。执行构建、bundle 和发布包准备流程；当前发布包应通过准备步骤，不再触发尺寸门禁失败。

证据（Before & After）

N/A——非 UI 的发布门禁改动。

已测试平台

OS	状态
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境（可选）

Node.js 22；本地完成 npm build、typecheck、bundle、发布包准备和脚本测试。

风险与范围

• 主要风险或权衡：发布包在触发安全门禁前最多可以再增长 5 MiB。
• 未验证 / 不在范围内：Linux Docker 实际执行，以及缩减现有发布包内容。
• 破坏性变更 / 迁移说明：无。

关联问题

相关失败发布：https://github.com/QwenLM/qwen-code/actions/runs/29110517358/job/86421715805

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓

Problem: Observed — the linked CI run (#29110517358) fails at the Docker sandbox build step, which runs npm run prepare:package inside the Dockerfile. With the package at ~84.5 MiB and the limit at 80 MiB, this is a real release blocker.

Direction: Aligned. Keeping the release pipeline working is core infrastructure. The guard stays in place — just the ceiling moves. This is the right tradeoff.

Size: Not applicable — changes are in scripts/ (build tooling), not core paths. 1 production line changed, 28 test lines added.

Approach: Scope is right. One constant bump, one boundary test. Nothing extraneous. Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题：已观测到 — 关联的 CI 运行 (#29110517358) 在 Docker sandbox 构建步骤失败，该步骤在 Dockerfile 内执行 npm run prepare:package。包体积 ~84.5 MiB 而限制为 80 MiB，确实是发布阻塞。

方向：对齐。保持发布流水线正常工作是核心基础设施。尺寸保护仍在，只是提高上限。这是正确的权衡。

规模：不适用 — 改动在 scripts/（构建工具），不在核心路径。1 行生产代码变更，28 行测试代码新增。

方案：范围合理。一个常量调整，一个边界测试。没有多余改动。进入代码审查 🔍

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Code Review

The diff is exactly what this fix should be: one constant bump in prepare-package.js (80 → 85 MiB) and one boundary regression test. The test uses truncateSync for sparse files — fast, no actual disk allocation. The boundary assertions are correct: 84 MiB payload passes (84 MiB + fixture overhead < 89,128,960), 85 MiB payload fails (85 MiB + fixture overhead > 89,128,960 = 85 × 1024 × 1024).

No issues found. No reuse concerns — this is a single constant, not duplicated logic.

Testing

Ran vitest run scripts/tests/package-assets.test.js with the PR applied:

 ✓  scripts/tests/package-assets.test.js (17 tests) 61ms

 Test Files  1 passed (1)
      Tests  17 passed (17)
   Duration  334ms

All 17 tests pass, including the new enforces an 85 MiB default unpacked size budget test.

Tmux real-scenario testing: N/A — this is release infrastructure (package size guard), not user-visible CLI behavior.

中文说明

代码审查

diff 完全符合此类修复的预期：prepare-package.js 中一个常量调整（80 → 85 MiB）和一个边界回归测试。测试使用 truncateSync 创建稀疏文件——速度快，不实际占用磁盘。边界断言正确：84 MiB 载荷通过（84 MiB + fixture 开销 < 89,128,960），85 MiB 载荷失败（85 MiB + fixture 开销 > 89,128,960 = 85 × 1024 × 1024）。

未发现问题。无复用顾虑——这是单一常量，不存在重复逻辑。

测试

应用 PR 后运行 vitest run scripts/tests/package-assets.test.js：

 ✓  scripts/tests/package-assets.test.js (17 tests) 61ms

 Test Files  1 passed (1)
      Tests  17 passed (17)
   Duration  334ms

全部 17 个测试通过，包括新增的 enforces an 85 MiB default unpacked size budget 测试。

Tmux 真实场景测试：不适用——这是发布基础设施（包尺寸保护），非用户可见的 CLI 行为。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

This is a clean, focused fix that does exactly what it says: the package has outgrown its 80 MiB budget, so the ceiling moves to 85 MiB. The guard stays. The test proves the new boundary works. No scope creep, no drive-by changes.

The linked CI failure confirms the problem is real — the Docker sandbox build fails because prepare:package rejects the oversized package inside the Dockerfile. The fix unblocks releases.

I'd write this the same way. Approving.

中文说明

这是一个干净、聚焦的修复，完全如其所述：包体积已超过 80 MiB 预算，因此将上限提高到 85 MiB。保护机制仍在。测试验证了新边界有效。无范围蔓延，无顺手改动。

关联的 CI 失败证实了问题的真实性——Docker sandbox 构建失败，因为 Dockerfile 内 prepare:package 拒绝了超大的包。此修复解除了发布阻塞。

我会以同样的方式实现。批准。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅