[GH-ISSUE #6953] [Design] First-class Bun runtime autonomy and avoiding single-runtime ecosystem lock-in #4244

New issue

Open

opened 2026-10-31 00:48:02 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:48:02 +00:00

Owner

Originally created by @Ercaner1988 on GitHub (Oct 24, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6953

Decision needed

Should REA explicitly support Bun as an autonomous, first-class peer runtime—decoupling runtime satisfaction and client registration from Node.js-only assumptions—and avoid entrenching a single-runtime monopoly in the JavaScript/TypeScript CLI/MCP ecosystem?

Context, Motivation, and Ecosystem Monoculture

In open-source systems engineering, monocultures inevitably produce artificial barriers to entry, brittle assumptions, and anti-competitive lock-in. Historically, the software industry observed this dynamic in operating systems: the default presumption of Microsoft Windows as the unavoidable target architecture created an ecosystem where applications became tightly coupled to Windows-specific quirks, registry mechanisms, and API models, penalizing alternative platforms until conscious architectural decoupling took hold.

A very similar dynamic currently threatens the JavaScript and TypeScript systems tooling ecosystem around Node.js:

Implicit Single-Vendor Hegemony: Treating Node.js and npm as the sole canonical execution baseline forces toolchains into Node-specific paradigms (such as Windows cmd.exe /c npx wrapper requirements, heavy process memory footprints, slow script initialization, and brittle package-lock.json dependencies).
Artificial Exclusion of Modern Runtimes: Modern, high-performance engines such as Bun (built on WebKit/JavaScriptCore, designed with instant startup, zero-dependency bundling, and memory efficiency) are often relegated to "emulators" or treated as fragile second-class citizens.
The Penalty on Open-Source Tooling: When an advanced, engine-agnostic binary analysis and reverse engineering platform like REA inadvertently couples its diagnostics, version checks, and client registrations to Node.js release cadences, it unintentionally aids and abets this market lock-in rather than providing users and AI agents with true architectural autonomy.

In demanding reverse-engineering environments, hardware constraints and rapid CLI/daemon invocations make runtime performance, memory footprint, and startup latency critical. Open-source tooling must actively resist single-runtime hegemony rather than enabling it.

Technical Evidence and Concrete Failure Modes

Recent upstream commits illustrate how tightly coupled assumptions unintentionally break valid Bun environments:

Version Floor Misclassification (src/domain/runtimeVersion.ts):
- Upstream commit 28a33cae8 bumped the supported Node range to ^22.23.4 || ^24.22.1 || >=26.12.1.
- Bun 1.4.x reports Node compatibility 26.3.0 (process.versions.node), which is maintained on Bun's own independent release track.
- Because supportsJavaScriptRuntime tested Bun's compatibility string directly against Node's patch-release floor, running rea doctor or rea --version --json under Bun classified modern Bun 1.4 as an unsupported runtime (satisfied: false), even though Bun operates flawlessly.
Client Registration Drift (src/application/ClientRegistrationIdentity.ts):
- Direct registrations generated or configured for clients (e.g. Gemini/Antigravity, Claude Code, OpenCode) with command: "bun.exe" and args ["...scripts/rea.mjs", "--mcp"] were classified as stale or unknown.
- inspectDirectRegistrationCommand strictly demanded the string "mcp" (ignoring the documented --mcp entry flag that scripts/rea.mjs explicitly accepts) and demanded interpreterIdentity === "owned" against process.execPath, falsely rejecting non-Node runtimes.
Package & Lockfile Reproducibility:
- Contributors and automation pipelines running exclusively under Bun generate bun.lock. Omitting Bun lockfile support forces environments to install npm solely to satisfy lockfile checks, reinstating unnecessary Node toolchain bloat.

Proposed Architectural Adjustments

We propose establishing first-class parity for Bun within REA:

Decouple Bun Compatibility Floors:
Introduce SUPPORTED_BUN_NODE_COMPATIBILITY_RANGE = "^22.23.4 || ^24.22.1 || >=26.0.0" so Bun's Node compatibility line is validated on its own merits while preserving strict Node.js engine security floors for Node installations.
Permissive, Runtime-Agnostic Direct Launcher Registration:
Accept --mcp alongside mcp in inspectDirectRegistrationCommand, and recognize standard JavaScript runtimes (node, bun) so alternative dispatchers remain in an aligned state.
Admit Bun Lockfiles (bun.lock):
Provide first-class reproducibility for users and workflows deploying via Bun.
Dynamic CLI Version Report Verification:
Ensure test suites dynamically validate the active runtime (node or bun) without hardcoding { id: "node" }.

A fully validated implementation addressing these points—with 0 compilation errors, full test coverage across runtimeVersion and versionReportCli, and successful rea doctor verification under Windows x64—has been submitted in pull request #6923:

PR: https://github.com/morluto/rea/pull/6923

Originally created by @Ercaner1988 on GitHub (Oct 24, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6953 ### Decision needed Should REA explicitly support Bun as an autonomous, first-class peer runtime—decoupling runtime satisfaction and client registration from Node.js-only assumptions—and avoid entrenching a single-runtime monopoly in the JavaScript/TypeScript CLI/MCP ecosystem? --- ### Context, Motivation, and Ecosystem Monoculture In open-source systems engineering, monocultures inevitably produce artificial barriers to entry, brittle assumptions, and anti-competitive lock-in. Historically, the software industry observed this dynamic in operating systems: the default presumption of Microsoft Windows as the unavoidable target architecture created an ecosystem where applications became tightly coupled to Windows-specific quirks, registry mechanisms, and API models, penalizing alternative platforms until conscious architectural decoupling took hold. A very similar dynamic currently threatens the JavaScript and TypeScript systems tooling ecosystem around Node.js: 1. **Implicit Single-Vendor Hegemony:** Treating Node.js and `npm` as the sole canonical execution baseline forces toolchains into Node-specific paradigms (such as Windows `cmd.exe /c npx` wrapper requirements, heavy process memory footprints, slow script initialization, and brittle `package-lock.json` dependencies). 2. **Artificial Exclusion of Modern Runtimes:** Modern, high-performance engines such as Bun (built on WebKit/JavaScriptCore, designed with instant startup, zero-dependency bundling, and memory efficiency) are often relegated to "emulators" or treated as fragile second-class citizens. 3. **The Penalty on Open-Source Tooling:** When an advanced, engine-agnostic binary analysis and reverse engineering platform like REA inadvertently couples its diagnostics, version checks, and client registrations to Node.js release cadences, it unintentionally aids and abets this market lock-in rather than providing users and AI agents with true architectural autonomy. In demanding reverse-engineering environments, hardware constraints and rapid CLI/daemon invocations make runtime performance, memory footprint, and startup latency critical. Open-source tooling must actively resist single-runtime hegemony rather than enabling it. --- ### Technical Evidence and Concrete Failure Modes Recent upstream commits illustrate how tightly coupled assumptions unintentionally break valid Bun environments: 1. **Version Floor Misclassification (`src/domain/runtimeVersion.ts`):** - Upstream commit `28a33cae8` bumped the supported Node range to `^22.23.4 || ^24.22.1 || >=26.12.1`. - Bun 1.4.x reports Node compatibility `26.3.0` (`process.versions.node`), which is maintained on Bun's own independent release track. - Because `supportsJavaScriptRuntime` tested Bun's compatibility string directly against Node's patch-release floor, running `rea doctor` or `rea --version --json` under Bun classified modern Bun 1.4 as an unsupported runtime (`satisfied: false`), even though Bun operates flawlessly. 2. **Client Registration Drift (`src/application/ClientRegistrationIdentity.ts`):** - Direct registrations generated or configured for clients (e.g. Gemini/Antigravity, Claude Code, OpenCode) with `command: "bun.exe"` and args `["...scripts/rea.mjs", "--mcp"]` were classified as `stale` or `unknown`. - `inspectDirectRegistrationCommand` strictly demanded the string `"mcp"` (ignoring the documented `--mcp` entry flag that `scripts/rea.mjs` explicitly accepts) and demanded `interpreterIdentity === "owned"` against `process.execPath`, falsely rejecting non-Node runtimes. 3. **Package & Lockfile Reproducibility:** - Contributors and automation pipelines running exclusively under Bun generate `bun.lock`. Omitting Bun lockfile support forces environments to install `npm` solely to satisfy lockfile checks, reinstating unnecessary Node toolchain bloat. --- ### Proposed Architectural Adjustments We propose establishing first-class parity for Bun within REA: 1. **Decouple Bun Compatibility Floors:** Introduce `SUPPORTED_BUN_NODE_COMPATIBILITY_RANGE = "^22.23.4 || ^24.22.1 || >=26.0.0"` so Bun's Node compatibility line is validated on its own merits while preserving strict Node.js engine security floors for Node installations. 2. **Permissive, Runtime-Agnostic Direct Launcher Registration:** Accept `--mcp` alongside `mcp` in `inspectDirectRegistrationCommand`, and recognize standard JavaScript runtimes (`node`, `bun`) so alternative dispatchers remain in an `aligned` state. 3. **Admit Bun Lockfiles (`bun.lock`):** Provide first-class reproducibility for users and workflows deploying via Bun. 4. **Dynamic CLI Version Report Verification:** Ensure test suites dynamically validate the active runtime (`node` or `bun`) without hardcoding `{ id: "node" }`. --- ### Related Implementation A fully validated implementation addressing these points—with 0 compilation errors, full test coverage across `runtimeVersion` and `versionReportCli`, and successful `rea doctor` verification under Windows x64—has been submitted in pull request **#6923**: - PR: https://github.com/morluto/rea/pull/6923

bsakaguchi commented

2026-10-31 00:48:03 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 24, 2026):

Supporting Bun as a first-class runtime is reasonable, but I'd suggest decoupling the version gate from Node's patch floor rather than special-casing each runtime: keep a per-runtime baseline (Node majors, Bun's own compatibility line) and treat the "Node compatibility string" as informational only. That avoids the classify-then-patch loop every time either project moves its version numbers. Also worth keeping the runtime identity explicit (bun vs node) in diagnostics and registration, so later features can branch on actual runtime capabilities instead of version strings. PR #6923's direction looks aligned with that.

@XinwangTao commented on GitHub (Oct 24, 2026): Supporting Bun as a first-class runtime is reasonable, but I'd suggest decoupling the version gate from Node's patch floor rather than special-casing each runtime: keep a per-runtime baseline (Node majors, Bun's own compatibility line) and treat the "Node compatibility string" as informational only. That avoids the classify-then-patch loop every time either project moves its version numbers. Also worth keeping the runtime identity explicit (bun vs node) in diagnostics and registration, so later features can branch on actual runtime capabilities instead of version strings. PR #6923's direction looks aligned with that.

bsakaguchi referenced this issue

2026-10-31 01:12:18 +00:00

[PR #4284] [CLOSED] fix(clients): remove a sole JSONC registration with a trailing comma #6156

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4244

No description provided.

Rows
Columns