Improve Studio packaging build performance

[bcotrim]

Related issues

• Inspired by pgle0O-1Gf-p2

How AI was used in this PR

Codex inspected the packaging flow, implemented and measured a build-time optimization, trimmed the first cache-heavy version after review, and then addressed CI/reviewer feedback around omitted bundle patches and local-build tradeoffs.

Proposed Changes

• Speeds up local Studio packaging by avoiding duplicate dependency setup in isolated packaging and keeping bundled installs focused on production dependencies.
• Local staging installs the build toolchain with a lockfile-accurate npm ci --ignore-scripts and reuses existing bundled WordPress/server files instead of re-downloading them on every build.
• Adds STUDIO_PACKAGE_FRESH=1 for release-grade local builds that should use the slower fresh staging install/download path.
• Applies only bundle patches whose target packages are present after production-only installs, and uses that helper for both Studio and CLI bundles.
• Per review feedback, the initial symlink-based reuse of the developer's node_modules was replaced with a real npm ci in staging — npm lays out the workspace dependency tree itself, so staging can't drift from the real repo's layout. CI E2E exercises the prePackage bundle install (including the win32 path-length guard) on macOS and Windows.

Testing Instructions

• Green CI
• Confirm builds completed in Buildkite (manual trigger)

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 2655694 vs trunk

app-size

Metric	trunk	2655694	Diff	Change
App Size (Mac)	1354.75 MB	1328.20 MB	26.54 MB	🟢 -2.0%

site-editor

Metric	trunk	2655694	Diff	Change
load	1655 ms	1688 ms	+33 ms	⚪ 0.0%

site-startup

Metric	trunk	2655694	Diff	Change
siteCreation	9066 ms	9029 ms	37 ms	⚪ 0.0%
siteStartup	4415 ms	4418 ms	+3 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[fredrikekelund]

I haven't tested this, but just to make sure we aren't missing anything: there's no guarantee that a clean npm install from the repo root places all dependencies in /node_modules. Depending on whether there are version conflicts, npm may also place dependencies in /apps/cli/node_modules, /apps/studio/node_modules, etc.

It looks like this PR assumes that /apps/cli/node_modules and /apps/studio/node_modules are non-existent or empty by default, which isn't necessarily true.

If my understanding of how this works is correct, then there's no guarantee that this approach will continue to work in the future, even if it does now. If there are version conflicts for dependencies across different workspaces, it might break when we link in /node_modules to /apps/cli/node_modules, /apps/studio/node_modules, etc.

Let me know if I'm misunderstanding the approach

[sejas]

The changes look good to me. I triggered the Buildkite CI to confirm that the builds are still working correctly.

[bcotrim]

I haven't tested this, but just to make sure we aren't missing anything: there's no guarantee that a clean npm install from the repo root places all dependencies in /node_modules. Depending on whether there are version conflicts, npm may also place dependencies in /apps/cli/node_modules, /apps/studio/node_modules, etc.

It looks like this PR assumes that /apps/cli/node_modules and /apps/studio/node_modules are non-existent or empty by default, which isn't necessarily true.

If my understanding of how this works is correct, then there's no guarantee that this approach will continue to work in the future, even if it does now. If there are version conflicts for dependencies across different workspaces, it might break when we link in /node_modules to /apps/cli/node_modules, /apps/studio/node_modules, etc.

Let me know if I'm misunderstanding the approach

Nice catch! 🙌 You were right, npm does place conflicting versions in per-workspace node_modules (live example: tools/common has ignore@7.0.5 while the hoisted root copy is 5.3.2), so mirroring that layout with symlinks was fragile.

I removed the symlink logic in 2655694