Skip to content

setup: WSL installer picks Windows Bun and produces a non-working binary / Node launcher #36

Description

@li-xiu-qi

Problem

On WSL, if the user has installed Bun from Windows (e.g. via npm i -g bun on Windows), the bun executable appears first on PATH as /mnt/c/.../bun. scripts/setup.sh currently runs command -v bun, finds this Windows binary, and then:

  1. Calls pnpm build:bin, which invokes the Windows Bun to compile dist/bin/step. The resulting binary is a Windows PE executable that cannot run in WSL, or fails with DLL / loader errors.
  2. If no Bun is found at all, it installs the Node-based launcher. OpenTUI packages (@opentui/core, @opentui/react) rely on Bun-specific module resolution (bun: protocol imports and extensionless subpath imports), so step voice fails on Node with errors like:
    • Cannot find module 'react-reconciler/constants'
    • Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'bun:'

Environment

  • step-realtime-cli version: 1.0.0
  • OS: WSL (Ubuntu on Windows)
  • which bun returns a path under /mnt/c/...
  • A Linux-native Bun is installed at e.g. ~/.bun/bin/bun

Expected behavior

bash scripts/setup.sh should build / install a launcher that works on WSL. It should prefer a Linux-native Bun over a Windows Bun and, when available, install the native Bun binary launcher.

Actual behavior

Setup either builds a broken Windows binary or falls back to a Node launcher that cannot run OpenTUI.

Root cause

scripts/setup.sh resolves Bun unconditionally via command -v bun. It does not distinguish Windows (/mnt/) and Linux-native executables, and it does not honor STEP_BUN_BIN.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions