Consider running llmlake under Node (keep writing Bun, ship a Node-runnable build)

Aperta
  • Qualcosa non va?
#2 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
bun, node.js, typescript
Ambito
cli, tooling

Direzione di ricerca

Inizia esaminando gli entry point specifici di Bun indicati in build.ts, build-one.ts, status.ts, parse-session.ts, sync-pricing.ts e collect.ts, quindi confronta i quattro approcci candidati con gli obiettivi dichiarati per contributori e utenti. Il lavoro è completato quando il repository ha preso una decisione chiara tra il supporto a Node e un binario autonomo, e sono stati considerati i prerequisiti del runtime e di DuckDB.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

Today llmlake is Bun-only. Every *.ts entry point has a #!/usr/bin/env bun shebang and the llmlake dispatcher runs them with bun run. The shebang itself isn't the blocker — the scripts use Bun-native globals that simply don't exist in Node, so they'd throw Bun is not defined under node.

This issue is to consider whether we want a path to run under Node (lower barrier for contributors/users who don't have Bun), ideally without giving up writing Bun-style source.

What's Bun-specific today

The surface is small and well-contained:

  • Bun.spawn / Bun.spawnSync — duckdb processes (build.ts, build-one.ts, status.ts)
  • Bun.file(...).text() / .size — reading session/query files (parse-session.ts, build.ts, status.ts, sync-pricing.ts)
  • Bun.write — writing parquet temp JSON / pricing (build.ts, sync-pricing.ts)
  • Bun.Glob(...).scan(...) — finding jsonl files (parse-session.ts, build.ts)
  • Bun.hash — row ids (parse-session.ts)
  • Bun.$ shell — running collect scripts (collect.ts)
  • import.meta.dir — script-relative paths (most files; Node spells this import.meta.dirname)
  • navigator.hardwareConcurrency — build concurrency default (build.ts)

Candidate approaches

  1. Do nothing (status quo). Keep Bun as the documented prerequisite. It's a local dev tool and Bun install is one line. Lowest effort; this issue may just close as "won't do".

  2. Ship a standalone binary via bun build --compile. Bundles the Bun runtime into a single executable — users need neither Bun nor Node. Doesn't make it "run on Node" but solves the underlying "I don't have Bun" pain. Cost: per-platform builds + a release step.

  3. Bundle for a Node target + a thin Bun shim. Build with bun build --target=node (or esbuild) and provide a small compatibility module mapping the APIs above onto Node built-ins:

    • Bun.spawn/spawnSync → node:child_process
    • Bun.file().text()/.size → node:fs/promises
    • Bun.write → node:fs/promises
    • Bun.Glob().scan → node:fs glob / fast-glob
    • Bun.hash → node:crypto
    • Bun.$ → node:child_process (or drop in favor of plain spawns)
    • import.meta.dir → import.meta.dirname
    • navigator.hardwareConcurrency → node:os cpus().length

    Keeps the source Bun-flavored; the shim absorbs the difference. This is the "keep writing Bun but compile to Node" path.

  4. Refactor the Bun surface behind an internal runtime.ts with two implementations (Bun-native + Node) chosen at load. Cleaner than scattering shims, but more upfront refactor.

Notes / open questions

  • This is a deliberate, repo-wide decision, not a one-file change — status.ts just surfaced it.
  • DuckDB is an external prerequisite either way, so neither runtime removes that dependency.
  • Worth deciding the actual goal first: "contributors can use Node" (→ option 3/4) vs "users don't need a runtime at all" (→ option 2).

Low priority — capturing for later consideration.

Lingua principale
TypeScript
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.