fix(ci): install all platform opentui bindings for cross-compilation

[lavaman131]

Summary

Fixes build failures when cross-compiling binaries for multiple platforms in the publish workflow. The workflow now installs all platform-specific @opentui/core-* native bindings before running bun build --compile for each target platform.

Problem

When using bun build --compile --target=bun-<platform>-<arch> to cross-compile for non-host platforms, Bun resolves dynamic imports like @opentui/core-${platform}-${arch} at build time (not runtime). The build was failing with:

Could not resolve: "@opentui/core-linux-arm64/index.ts"

because only the host platform's native bindings were installed by default.

Solution

• Explicitly install all 6 platform-specific native bindings as optional dependencies before the build step:
  • @opentui/core-darwin-x64@0.1.79
  • @opentui/core-darwin-arm64@0.1.79
  • @opentui/core-linux-x64@0.1.79
  • @opentui/core-linux-arm64@0.1.79
  • @opentui/core-win32-x64@0.1.79
  • @opentui/core-win32-arm64@0.1.79

This ensures the bundler can resolve all platform imports when compiling for each target.

Test plan

• Publish workflow successfully builds all 5 platform binaries (Linux x64/arm64, macOS x64/arm64, Windows x64)
• No "Could not resolve" errors during cross-compilation
• Resulting binaries contain the correct native modules for their target platforms

[claude]

PR Review: fix(ci): install cross-platform opentui bindings for build

Summary

This PR adds a step to install all platform-specific @opentui/core-* native bindings before cross-compiling binaries. This addresses the Could not resolve: "@opentui/core-linux-arm64/index.ts" error during bun build --compile for non-host targets.

---

Code Quality ✅

The change is minimal and focused - exactly 6 lines added to solve a specific problem. The step is well-named and clearly describes its purpose.

---

Potential Issues ⚠️

1. Hardcoded version 0.1.79: The opentui bindings are pinned to version 0.1.79, but package.json specifies "@opentui/core": "^0.1.79". If the core package is ever updated to a newer version (e.g., 0.1.80), these platform-specific bindings will remain at 0.1.79, potentially causing version mismatches.

   Suggestion: Consider dynamically reading the version from package.json or the lockfile:

   - name: Install all platform-specific opentui native bindings
     run: |
       OPENTUI_VERSION=$(jq -r '.dependencies["@opentui/core"] | sub("^\\^"; "")' package.json)
       bun add --optional @opentui/core-darwin-x64@$OPENTUI_VERSION ...

2. Missing Windows ARM64 build: The workflow installs @opentui/core-win32-arm64 but the build step (lines 54-67) only builds atomic-windows-x64.exe. Either the Windows ARM64 binding is unnecessary, or there's a missing build target.

---

Performance Considerations ✅

Adding packages with --optional is appropriate here since these are platform-specific native bindings only needed at build time for cross-compilation.

---

Security Considerations ✅

No security concerns. The packages are from a known source (@opentui/*) that's already a project dependency.

---

Test Coverage

The PR notes that the test plan is to verify the publish workflow builds all 5 platform binaries successfully. This is appropriate for a CI fix - manual verification of the workflow run is the right approach.

---

Overall Assessment

LGTM - This is a straightforward fix that addresses a real build issue. The hardcoded version is a minor concern for long-term maintainability but doesn't block this PR since it matches the current package.json version. Consider addressing the version syncing in a follow-up.