feat: single apify-cli bundle + native Windows ARM64 (supersedes #1057)

[vladfrangu]

What & why

Reworks how the CLI bundles are built, installed, and upgraded, and adds native Windows ARM64 support.

Previously the bundle install shipped three full ~70 MB binaries (apify, actor, apify-cli) — the same binary dropped three times into the install dir. This builds one apify-cli bundle; apify and actor become tiny wrapper scripts that invoke it with APIFY_CLI_ENTRYPOINT set, which the entrypoint uses to pick the command set.

Note

This supersedes #1057 (native Windows ARM bundles) — those changes are included here, adapted on top of the single-bundle work. See the "Windows ARM64" section for one deliberate deviation.

Single-bundle layout

• Build (build-cli-bundles.ts): build only the apify-cli entrypoint; additionally publish apify-*/actor-* copies as backwards-compatible backups so installs using the old two-bundle upgrade flow can still pull the new bundle during the transition.
• Entrypoint: new single apify-cli.ts entrypoint + resolveEntrypoint() (reads APIFY_CLI_ENTRYPOINT, falls back to the executable's basename).
• Install (install.sh / install.ps1): drop the apify-cli binary and generate apify/actor (.cmd on Windows) wrapper scripts instead of three binaries.
• Self-migration (bundleMigration.ts): on the first run after upgrading from a legacy 3-bundle install, copy the running bundle to apify-cli and replace apify/actor with wrapper scripts. Writes are atomic (temp + rename) so we never truncate a running executable — an in-place overwrite fails with ETXTBSY on Linux (verified in a container; this matters because the actor CLI runs in Linux Actor images). On Windows the running .exe is renamed (can't be deleted) and cleaned up on a later run.
• Upgrade (upgrade.ts): download the single apify-cli bundle, write it + the wrappers atomically.

Windows ARM64 (supersedes #1057)

Bun now ships native Windows ARM64 builds, so the old hack (compile an x64 bundle on the ARM runner and relabel it arm64) is gone.

• Build a native bun-windows-arm64 target; drop the pwsh SystemType detection + APIFY_BUNDLE_ARCH override.
• install.ps1: detect arch from PROCESSOR_ARCHITECTURE; ARM64 never downloads a -baseline bundle (baseline is x64/AVX2-only).
• useCLIVersionAssets: Windows ARM64 now matches the native (non-baseline) asset — a fix chore: native windows arm bundles #1057 lacks; without it the upgrade command finds zero assets on Windows ARM64.
• CI (check/pre_release/release): build on windows-11-arm with native setup-bun (dropped the manual install workaround) via a bun-target-arch matrix var.

Deviation from #1057: asset names keep the arm64 suffix (matching the produced artifacts, useCLIMetadata's process.arch, and the asset matcher) rather than renaming to aarch64, which in #1057 mismatches the -arm64 artifacts the build actually emits.

Bundle target cleanup

• Removed the as never casts on the bun compile targets. Per Bun's supported-targets matrix, @types/bun's CompileTarget only accepts the SIMD-then-libc order, so bun-linux-x64-musl-baseline → bun-linux-x64-baseline-musl (bun accepts either order at build time). The target parser now reads the trailing modifiers order-independently and still emits the canonical -musl-baseline asset suffix, so every published asset name is unchanged.
• Stopped building bun-{darwin,linux}-arm64-baseline (and the arm64 musl-baseline): baseline is x64-only, so these just duplicated the non-baseline arm64 builds. They're unreachable via the install/upgrade path, and download counts confirm no real usage (~205 total / max 3 per release — scraper-noise floor — vs darwin-arm64 at 1557 / max 260).

Testing

• pnpm run build, oxlint, oxfmt, and the local test suite all pass.
• Verified the full legacy→migrated flow end-to-end on Linux (arm64 container): 3 binaries → single apify-cli + wrapper scripts, idempotent, actor runs in actor mode.
• Confirmed ETXTBSY on in-place overwrite vs success with atomic rename on Linux.
• Confirmed Bun accepts bun-windows-arm64 and the reordered bun-linux-x64-baseline-musl targets and appends .exe for Windows.

Added dev-test-install-legacy.sh to reproduce the old 3-binary layout locally for testing the migration.

closes #1221

[Copilot]

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[l2ysho]

LGTM. Just question if we want to ship this as a part of 1.6.2. or we rather wait? cc @patrikbraborec

[patrikbraborec]

Thanks, looks cool. I would wait, and not ship it as part of 1.6.2.

[l2ysho]

1.6.2 out so we can merge this cc @vladfrangu

[vladfrangu]

The public install/upgrade scripts (install.sh, install.ps1, upgrade.ps1) have been split out into #1219, stacked on this branch for isolated review. This PR no longer touches those three files; merge this one first, then #1219.

[vladfrangu]

Update: #1219 now targets master directly (no longer stacked on this branch), per the plan to merge it once a release containing this PR's apify-cli bundle is out. This PR still excludes those three install scripts.

[DaveHanns]

Nit: we should probably mention the var in docs/vars.md.

[vladfrangu]

No, this is an internal env var. Users shouldn't mess with it unless they know what they're doing

[DaveHanns]

Nit: having apify.ts and actor.ts "serving" apify, apify-cli and actor scripts, name of this one seems a bit missleading. Maybe bundle.ts would be more fitting as it indicates this is the main entrypoint for the bundle (and is dynamic).

[vladfrangu]

Renamed to bundle.ts in 7ab7739 — the published asset prefix stays apify-cli (the build script now sets it explicitly instead of deriving it from the entrypoint file name).

[DaveHanns]

The requiresBaseline branch is a little too permissive, specifically its first clause:

return assetBaseline === 'baseline' || assetBaselineOrMusl === 'baseline';
//     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this one

Since the split is positional, baseline only lands in assetBaseline (slot 4) when musl occupies slot 3, so assetBaseline === 'baseline' is effectively "this asset is -musl-baseline". And we only reach this branch when requiresMusl is false, so that clause can only ever let a wrong-libc asset through. Alpine machines get -musl-baseline from the requiresMusl branch above, so nothing needs it.

Effect: a glibc machine without AVX2 matches both -baseline and -musl-baseline, both download to the same apify-cli path, and the musl one wins alphabetically, which then can't start on glibc.

Pre-existing and effectively never hit, so not a blocker.

Fix: the build script in this PR already parses these suffixes into booleans, and mirroring it makes the match exact (it also tightens requiresMusl, which currently accepts both -musl and -musl-baseline) and collapses all four ifs into one expression:

const [_version, assetOs, assetArch, ...modifiers] = asset.name
    .slice('apify-cli-'.length)
    .replace(versionWithoutV, 'version')
    .replace('.exe', '')
    .split('-');

return (
    assetOs === metadata.platform &&
    assetArch === metadata.arch &&
    modifiers.includes('musl') === requiresMusl &&
    modifiers.includes('baseline') === requiresBaseline
);

[vladfrangu]

Fixed in bc69583 with exactly the suggested shape — the matcher now splits the trailing modifiers and requires an exact boolean match on both musl and baseline, mirroring the build script. Verified with a truth-table over all 9 published asset shapes: every (platform, arch, musl, baseline) combination now matches exactly one asset, including the glibc-no-AVX2 case.

[DaveHanns]

Great job 🚀. Sorry it took so long to review; I have used it to learn the mechanics of CLI bundling in depth.