feat: fetch the per-chip macOS office bundle - #252
Merged
Conversation
codev-scripts now publishes codev-office-macos-arm64.zip and codev-office-macos-x86_64.zip (~1.7 GB each) instead of one ~3.1 GB zip carrying both chips' installers. This is codevhub's side of that contract. A new OfficeTarget type separates bundle identity (per-chip on macOS) from script identity (per-OS): officeBundleName takes a target, officeScriptName still takes a platform. There are four bundles but still three setup scripts — the one macOS script resolves its own bundle from `uname -m`. Two behaviours worth calling out: Rosetta. process.arch reports the architecture of the NODE BINARY, not of the machine — an x64 node under Rosetta on Apple Silicon says "x64". Believing it costs 3.4 GB to land 1.7: we would fetch the Intel bundle, and the setup script (native bash, `uname -m` = arm64) would find nothing it can use and download the arm64 one itself. detectArch() consults sysctl.proc_translated. --platform macos from another OS now REQUIRES --arch. On a Linux x64 host detectArch() would answer x86_64 — confident, plausible and wrong, for a 1.7 GB download. It refuses instead of guessing. --arch accepts arm64/aarch64 and x86_64/x64/intel, and is rejected for the x64-only bundles. APPROX_BUNDLE_MB is now keyed by target: macOS drops 3100 -> 1700. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
APPROX_BUNDLE_MB is the one place codevhub states a bundle size, and the README already tells the reader the command prints the approximate size before downloading. Repeating "~1.7 GB each rather than ~3.1 GB" in the README and again in the OfficeTarget comment just adds two more places to drift when the bundles are rebuilt. The remaining size references are not bundle-size documentation — they justify a specific decision (what guessing the wrong chip costs), so they stay. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
quickbeard
added a commit
that referenced
this pull request
Aug 6, 2026
* chore: correct the macOS bundle size to ~1.6 GB, bump to 0.5.15 The per-chip bundles (#252) were sized from an estimate made before they existed. They have now been built and verified — CLOSURE CLEAN, zip -t, sha256sum -c on both — and the real figures are 1637 MB arm64 and 1669 MB x86_64, so APPROX_BUNDLE_MB drops 1700 -> 1600. The prose that quotes a size does so to justify a decision — what fetching the wrong chip's bundle actually costs — so those numbers move with it rather than being dropped: 1.7 -> 1.6, and the Rosetta test's "3.4 GB to land 1.7" -> "3.2 GB to land 1.6". Matching updates in codev-scripts and codev-landing-page. * docs: drop the remaining bundle size from the --arch paragraph The reason to require --arch is that nothing on a non-Mac host implies which Mac the bundle is for; the download size was supporting colour, and the README now carries no hardcoded bundle size at all. --------- Co-authored-by: Quickbeard <quickbeard@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
codev-scripts now publishes
codev-office-macos-arm64.zipandcodev-office-macos-x86_64.zip(~1.7 GB each) instead of one ~3.1 GB zip carrying both chips' installers. This is codevhub's side of that contract.Producer PR: quickbeard/codev-scripts#27
Target vs. platform
A new
OfficeTargettype separates bundle identity (per-chip on macOS) from script identity (per-OS):officeBundleNametakes a target,officeScriptNamestill takes a platform. Four bundles, three setup scripts — the one macOS script resolves its own bundle fromuname -m.tests/lib/download.test.tsasserts that asymmetry directly:codev-office-macos-arm64.zipstaged alongside plaincodev-office-macos-setup.sh.APPROX_BUNDLE_MBis keyed by target; macOS drops 3100 → 1700.Two behaviours worth review
Rosetta.
process.archreports the architecture of the node binary, not of the machine — an x64 node under Rosetta on Apple Silicon says"x64". Believing it costs 3.4 GB to land 1.7: we fetch the Intel bundle, then the setup script (native bash,uname -m= arm64) finds nothing it can use and downloads the arm64 one itself.detectArch()consultssysctl.proc_translated, guarded so a genuine Intel Mac (or a missingsysctl) falls through tox86_64.--platform macosfrom another OS now requires--arch. On a Linux x64 hostdetectArch()would answerx86_64— confident, plausible and wrong, for a 1.7 GB download. It refuses instead of guessing.--archacceptsarm64/aarch64andx86_64/x64/intel, and is rejected outright for the x64-only bundles. On a Mac the chip is detected for you;--archis then only needed to stage a bundle for the other chip.Tests
pnpm check,pnpm typecheck,pnpm test— 1405 passed, 2 skipped (the pre-commit hook ran the same gate plusbuild).New coverage:
detectArchincluding the Rosetta override,officeTarget(including the deliberatenullfor macOS-without-arch),--archparsing and its aliases, and three end-to-endrunSkillOfficecases. The existingrunSkillOfficedescribe block computed its bundle name from the host platform, which would have broken on a Mac dev machine — it now derives the target, and the new tests are pinned tolinuxviawithPlatformso they behave the same wherever the suite runs.🤖 Generated with Claude Code