build: adopt Bun --bytecode + --splitting once the next Bun release ships (smaller binary, faster startup)

[vibexp-agent]

WHAT

Adopt Bun's --bytecode (together with --splitting) in scripts/build.ts once the next Bun release ships it, and bump the Bun version pinned in CI.

WHY

Today scripts/build.ts compiles with --compile --minify and deliberately no --bytecode. That was the correct trade-off: bytecode used to cost ~7x the source size on disk and ~4x in memory in exchange for faster startup.

Bun announced (@bunjavascript, 24 Aug 2026) that in the next version, bytecode is now mmap'd and read in place, so compiled executables built with bun build --compile --bytecode --splitting get, measured against Bun v1.4.0:

• 34% smaller binary (428 MB → 284 MB in their benchmark)
• 17% faster startup (458 ms → 382 ms)
• 32% less RAM on start (383 MB → 260 MB)

Their follow-up: bytecode now costs ~3x on disk instead of ~7x, and is "almost free in memory". For a CLI that a user (and AI agents scripting it) invokes over and over, startup time is the metric that matters most, and it now comes with a smaller binary rather than a bigger one.

This is not actionable yet — it is a "keep an eye on it" item — hence this tracking issue.

HOW

1. Wait for the release. As of 2026-08-25 the latest Bun release is v1.4.0 (2026-08-20); the announcement benchmarks against v1.4.0, so these gains land in the next release (presumably v1.4.1). Watch https://github.com/oven-sh/bun/releases.
2. Bump the pinned Bun version. All three workflows pin bun-version: 1.3.13 — .github/workflows/ci.yml, .github/workflows/test.yml, .github/workflows/release.yml. Nothing changes until these are bumped. Keep the three in lockstep.
3. Add the flags to the bun build invocation in scripts/build.ts, alongside the existing --compile --minify.
4. Verify before committing to it — the announced numbers are for a 57-npm-package / 36 MB bundle on Linux x64, not for this project. Measure our own:
   • binary size for each build:linux / build:macos / build:windows target;
   • cold-start time of slackcli --help before vs. after;
   • that the binary size stays under the 150MB cap enforced in ci.yml, which bytecode still grows relative to no bytecode.
5. Check cross-compilation. Confirm --bytecode behaves for every --target= we ship (bun-linux-x64, bun-darwin-x64, bun-windows-x64) — bytecode is tied to the Bun/JSC version, so the release build must be produced by the same Bun that CI pins.
6. Sanity-check the built binary, not just that it compiles: run the test suite plus a real command against a workspace, since bytecode + --splitting changes the module wiring.

If any of the above regresses (size cap, cross-compile, runtime), the right outcome is to close this without the change and revisit on a later Bun release.

[github-actions]

This issue has had no activity for 7 days and is now marked Stale. It will receive one reminder at 14 days and be closed after 21 days of inactivity. Any comment or update removes the Stale label and resets the clock.