fix(ci): force-install cross-platform opentui native bindings

[lavaman131]

Summary

Fixes cross-platform compilation in the publish workflow by bypassing npm's platform filtering for OpenTUI native bindings. The previous approach using bun add --optional failed because platform-specific packages have os/cpu fields that prevent installation on foreign platforms.

Changes

• Replaced bun add --optional with a custom installation script using npm pack + tar
• Downloads tarballs for all 5 platform-specific OpenTUI bindings (darwin-x64, darwin-arm64, linux-arm64, win32-x64, win32-arm64)
• Extracts packages directly into node_modules/@opentui/core-*, bypassing platform checks
• Enables bun build --compile cross-compilation for all target platforms from a single x64 Linux runner

Technical Details

The workflow now:

1. Uses npm pack to download package tarballs without triggering platform compatibility checks
2. Extracts each tarball directly into the appropriate node_modules directory
3. Skips already-installed packages to optimize repeated runs
4. Preserves the version pinning (currently 0.1.79) for reproducible builds

Test Plan

• Verify the publish workflow builds all 5 platform binaries successfully:
  • atomic-linux-x64
  • atomic-linux-arm64
  • atomic-darwin-x64
  • atomic-darwin-arm64
  • atomic-windows-x64.exe
• Confirm binaries are uploaded as artifacts and included in GitHub releases

[claude]

PR Review: fix(ci): force-install cross-platform opentui native bindings

Summary

This PR changes the approach for installing cross-platform native bindings in the CI publish workflow. Instead of using bun add --optional (which respects platform restrictions), it now uses npm pack + tar to directly extract packages, bypassing platform checks.

---

✅ What Works Well

1. Problem solving approach: The tarball extraction method is a valid workaround for platform-restricted packages when cross-compiling
2. Conditional installation: The if [ ! -d "$dest" ] check prevents redundant downloads if packages already exist
3. Clear comments: Good explanation of why this approach is needed

---

⚠️ Potential Issues & Suggestions

1. Missing linux-x64 platform

The loop includes:

for platform in darwin-x64 darwin-arm64 linux-arm64 win32-x64 win32-arm64; do

But linux-x64 is missing. Since the CI runs on ubuntu-latest (x64 Linux), this package is already installed by bun ci, but it's worth noting for clarity.

2. Error handling is suppressed

npm pack "${pkg}@${OPENTUI_VERSION}" --pack-destination /tmp 2>/dev/null

Redirecting stderr to /dev/null masks potential failures. If npm pack fails (network issue, package not found, etc.), the workflow will continue and likely fail later with a confusing error during the build step.

Suggestion: Remove 2>/dev/null or add explicit error checking:

npm pack "${pkg}@${OPENTUI_VERSION}" --pack-destination /tmp || { echo "Failed to pack ${pkg}"; exit 1; }

3. Tarball filename assumption

The code assumes the tarball will be named:

/tmp/opentui-core-${platform}-${OPENTUI_VERSION}.tgz

However, npm pack names tarballs based on the package name with @ replaced by an empty string and / replaced by -. For scoped packages like @opentui/core-darwin-x64, the actual filename is likely opentui-core-darwin-x64-0.1.79.tgz which appears correct, but this is fragile if naming conventions change.

Suggestion: Consider using the output of npm pack which prints the filename:

tarball=$(npm pack "${pkg}@${OPENTUI_VERSION}" --pack-destination /tmp)
tar -xzf "/tmp/${tarball}" -C "$dest" --strip-components=1

4. No cleanup of downloaded tarballs

The tarballs accumulate in /tmp. Not critical for CI (ephemeral runners), but worth noting.

5. Hardcoded version

OPENTUI_VERSION="0.1.79" requires manual updates. Consider reading from package.json or lockfile for consistency.

---

🔒 Security Considerations

• The packages are downloaded from the public npm registry over HTTPS
• No additional security concerns introduced by this change

---

🧪 Test Coverage

The test plan indicates manual verification via "Publish workflow builds all platform binaries successfully" - this is reasonable for CI workflow changes.

---

📝 Verdict

The approach is sound and solves a real problem. The main concerns are:

1. Error suppression - could mask issues and make debugging harder
2. Tarball filename fragility - using npm pack output would be more robust

Consider addressing the error handling issue before merging. The other items are nice-to-haves.