morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #1735] [MERGED] feat(update): update Bun global installations #4785

New issue

Closed

opened 2026-10-31 00:55:01 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:55:01 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1735
Author: @xeropresence
Created: 10/11/2026
Status: ✅ Merged
Merged: 10/11/2026
Merged by: @morluto

Base: main ← Head: feat/update-bun-installs

📝 Commits (2)

e1111b5 feat(update): update Bun global installations
5963280 fix(update): gate Bun self-updates on supported CLI versions

📊 Changes

8 files changed (+492 additions, -51 deletions)

View changed files

📝 README.md (+5 -2)
📝 docs/installation.md (+16 -4)
📝 src/application/Update.test.ts (+120 -8)
📝 src/application/Update.ts (+53 -22)
📝 src/application/UpdateRuntime.release.test.ts (+2 -1)
📝 src/application/UpdateRuntime.ts (+154 -12)
📝 src/cliLogging.test.ts (+2 -1)
📝 tests/process-global/updateMaintenance.test.ts (+140 -1)

📄 Description

Summary

rea update only knew npm global installs. If you installed REA with bun add --global rea-agents on a machine that has Bun but no npm, it stopped right away:

{"status":"failed","currentVersion":"6.4.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: spawn npm ENOENT..."}

With this PR, rea update recognizes a Bun global installation of the running package. It looks up the latest release with Bun, installs it with Bun into the same global directory, checks the installed entry point's version, and plans integration maintenance the same way it does for npm. npm installations use the same commands and messages as before.

No linked issue. The problem was seen on a Bun-only Windows machine.

Problem and expected behavior

Trigger: run rea update from a bun add --global install ($BUN_INSTALL/install/global/node_modules/rea-agents, with ~/.bun as the default BUN_INSTALL).
Before: detectNpmInstallation recognizes only npm's global root or a <prefix>/lib/node_modules/rea-agents layout. A Bun install becomes "unknown", so the release lookup falls back to npm view. Without npm, that fails with spawn npm ENOENT. With npm present, the update can only fail with unknown-install-method.
Expected: a Bun global install updates itself with Bun, under the same guarantees as npm: exact resolved version, installed into the directory that owns the running package, verified by running that package's entry point, and a maintenance plan that is not applied.

Change and scope

Update.ts (workflow): an installation is now NpmInstallation | BunInstallation, with a manager discriminant. installMethod reports "npm", "bun", or "unknown". For Bun, updateInstallCommand returns bun add --global --ignore-scripts rea-agents@<version>. Install and verification remediation messages name the manager and its location; for npm the text is unchanged.
UpdateRuntime.ts (system host):
- bunGlobalDirectory follows Bun's precedence for the global project directory: BUN_INSTALL_GLOBAL_DIR, then $BUN_INSTALL/install/global, then $XDG_CACHE_HOME/.bun/install/global, then ~/.bun/install/global. The home directory comes from the existing homeDirectoryFromEnvironment, so it is USERPROFILE on Windows. I checked each step with throwaway roots under Bun 1.4.2 on Windows.
- detectBunInstallation matches only when the canonical package root equals <globalDir>/node_modules/rea-agents and <globalDir>/package.json exists. It is location-based, so a Bun global install running under Node is still detected. It runs before npm detection, so Bun installs don't spawn npm. npm detection is unchanged.
- Release lookup for Bun uses bun info rea-agents dist-tags.latest --json, which honors Bun's registry configuration. Its output (a JSON string) goes through the existing npmReleaseLookup parser.
- Bun subprocesses (bun info and bun add) run with cwd set to the owning global directory and BUN_INSTALL_GLOBAL_DIR set to that same directory. This plays the role of npm's --prefix. runUpdateCommand got an optional working-directory parameter for this. npm subprocesses keep the caller's working directory and environment as before.
Hazard and guard. Under Bun 1.4.2 on Windows, if Bun's global directory has no package.json, bun add --global walks up to the nearest ancestor package.json and installs into that project. I hit this while probing: with BUN_INSTALL pointed at a temp directory under C:\Users\<user>\AppData\Local\Temp, bun add -g rea-agents@6.3.0 rewrote C:\Users\<user>\package.json, bun.lock and node_modules (restored right away). Also, bun info refuses to run unless its working directory is inside a project. Guards:
1. Detection requires <globalDir>/package.json. Without it, the installation is not treated as Bun-owned, so rea update never runs bun add there.
2. Bun commands run inside the owning global directory with that directory pinned, so the shell's current directory and any project it belongs to are never selected.
Not included: Bun global directories set only through bunfig.toml install.globalDir, which REA cannot see without parsing bunfig; layouts where Bun already installed into an ancestor project because of the walk-up above; bunx invocations (still "unknown", as npx is); and the release lookup for unknown installations, which still uses npm as before.

Contract and boundary impact

Semantic owner and earliest changed stage: src/application/Update.ts (installation model, install command) and src/application/UpdateRuntime.ts (detection and package-manager effects).
CLI and MCP/tool-catalog contract: the rea update JSON result can now report installMethod: "bun", with a Bun command. No other fields changed and no MCP tools changed.
Provider, bridge, target-format, or platform compatibility: not applicable to providers. Bun global layout detection follows Bun's documented environment variables on every platform. Only Windows x64 was exercised with real Bun.
Evidence, artifact, provenance, or reconstruction contract: none.
Process execution, authorization, cleanup, or containment impact: rea update can now spawn bun info and bun add --global --ignore-scripts, always with the owning Bun global directory as cwd and BUN_INSTALL_GLOBAL_DIR. Arguments go through cross-spawn as literals, like the npm path.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: no generated metadata or package changes. Updated README.md (Update section and bug FAQ) and docs/installation.md (update behavior and the "Diagnose, update, and remove" section).

Evidence and regression coverage

Tests added or updated:
- tests/process-global/updateMaintenance.test.ts › "updates a Bun global installation from inside its global project": runs runUpdate with the real systemUpdateHost and real subprocesses. A recording bun executable (bun.cmd on Windows, a shell script elsewhere) on PATH plays the registry and installer. The test checks installMethod: "bun", the exact bun add command, the verified version read back from the package's own scripts/rea.mjs, and that both bun info and bun add ran with cwd and BUN_INSTALL_GLOBAL_DIR equal to the owning global directory. Mutation check: when I removed the working-directory pin, this test failed because the recorded cwd was the repository root.
- src/application/Update.test.ts: Bun update and current paths through runUpdate; Bun ownership (match, missing global package.json, package roots outside the global project, unresolvable path); bunGlobalDirectory precedence, including Windows USERPROFILE. Existing npm ownership assertions now include manager: "npm".
- src/application/UpdateRuntime.release.test.ts, src/cliLogging.test.ts: fixtures updated for the manager discriminant.
Base reproduction or other evidence: the base failure above was observed on Windows with Bun and no npm. Bun behavior I observed under Bun 1.4.2 on Windows x64, using throwaway roots outside the home tree:
- bun add -g from a cwd inside an unrelated project with its own package.json left that project untouched.
- bun add -g with an empty global directory below an ancestor package.json installed into the ancestor (the hazard above).
- bun info rea-agents dist-tags.latest --json printed "6.4.0" inside the global directory. Outside any project it printed error: Bun could not find a package.json file to install from.
- BUN_INSTALL_GLOBAL_DIR and XDG_CACHE_HOME were both honored for the global directory.
User-visible CLI/MCP output: real end-to-end smoke on Windows x64, Bun 1.4.2, no Node.js or npm.
1. Created a temp root C:\rea-bun-smoke-<random> (outside the user's home tree), with BUN_INSTALL=<root>\bun and HOME/USERPROFILE=<root>\home. Ran bun add -g rea-agents@6.3.0 from <root>.
2. Overlaid this branch's compiled dist/, scripts/ and package.json onto <root>\bun\install\global\node_modules\rea-agents, then set its package.json version and dist/generatedPackageMetadata.js version to 6.3.0. bun <pkg>\scripts\rea.mjs --version printed 6.3.0.
3. Created an unrelated project <root>\project\package.json and recorded its hash, plus hashes and mtimes of the real ~/package.json, ~/bun.lock, ~/node_modules/rea-agents, ~/.bun/bin/*, ~/.bun/install/global, and the worktree's git status.
4. From cwd=<root>\project, ran bun <root>\bun\install\global\node_modules\rea-agents\scripts\rea.mjs update --format json. It exited 0, wrote nothing to stderr, and printed:
```
{"status":"updated","previousVersion":"6.3.0","latestVersion":"6.4.0","installedVersion":"6.4.0","installMethod":"bun","command":["bun","add","--global","--ignore-scripts","rea-agents@6.4.0"],"maintenance":{"status":"current","plannedActions":[]},"remediation":"REA is updated. Restart agents running this installation to load the new version."}
```
5. Afterwards: <root>\bun\install\global\package.json lists "rea-agents": "6.4.0". The installed package is the registry 6.4.0 (the overlay is gone and generatedPackageMetadata.js says 6.4.0). The regenerated shim <root>\bun\bin\rea.exe --version printed 6.4.0. <root>\project still held only its original package.json with the same hash. The before/after snapshot of everything outside the temp root was identical. I deleted the temp root.
Remaining proof gaps: real Bun was exercised only on Windows x64. Linux and macOS Bun global layouts are covered only by the recorder test and bunGlobalDirectory unit cases. The Node-runtime-with-Bun-install combination was not run (Node is not installed here); detection does not depend on the runtime. Bun's walk-up was observed only on Windows. bunfig.toml install.globalDir is not detected.

For evidence-bearing changes: not applicable (no Evidence records change).

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Local validation ran under Bun 1.4.2 on Windows x64 without Node.js or npm, on this commit rebased onto main at e36c82be. CI covers Node.

bun --bun run compile and every artifacts:* generator (skills, mcp-catalog, product-catalog, managed-evidence, error-schema): succeeded.
bun --bun run test:local -- src/application/Update.test.ts src/application/UpdateRuntime.release.test.ts src/cliLogging.test.ts: 3 files, 50 tests passed.
bun --bun node_modules/vitest/vitest.mjs run tests/process-global/updateMaintenance.test.ts: 18 tests passed. Before the rebase, removing the working-directory pin made the new Bun test fail on the recorded cwd; it passed again after restoring the pin.
bun --bun node_modules/vitest/vitest.mjs run tests/boundary/cli/cliStartupImports.test.ts (covers the deferred update command loading on main): 2 passed, 3 failed. The same 3 fail on main under Bun: the test records imports through --import hooks from node:module, and under Bun the recorded lists come back empty.
bun --bun run typecheck: passed.
bun --bun run lint (oxlint plus module-boundary check): exit 0, no warnings in changed files.
bun --bun node_modules/.bin/oxfmt --check on LF-normalized copies of all 8 changed files: passed. (The Windows checkout uses CRLF, which oxfmt flags in every file.)
bun --bun run docs:check:built: exit 0. The docs:check wrapper could not run because it requires npm's node_modules/.package-lock.json.
Real Bun end-to-end smoke as described above, rerun on the rebased commit with the same result: rea update exited 0 with the JSON shown, the global package.json lists rea-agents 6.4.0, the shim prints 6.4.0, the unrelated project was untouched, and the snapshot outside the temp root was identical.

Compatibility, safety, and release

Breaking changes or migration steps: none. The rea update result type gains installMethod: "bun". npm installs keep the same detection, commands, and message text. NpmInstallation gains a manager: "npm" field; it is internal and not part of the CLI/MCP contract.
Real Hopper/Ghidra, browser, or OS coverage: no providers involved. Real Bun on Windows x64 only.
Package or release metadata impact: none.
Security, privacy, process, or containment review: bun add --global runs with --ignore-scripts. It is confined to the detected Bun global directory by cwd and BUN_INSTALL_GLOBAL_DIR, and it never runs when that directory lacks package.json, which would otherwise let Bun modify an ancestor project such as the user's home directory. The environment override applies only to that child process and is not persisted.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1735 **Author:** [@xeropresence](https://github.com/xeropresence) **Created:** 10/11/2026 **Status:** ✅ Merged **Merged:** 10/11/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `feat/update-bun-installs` --- ### 📝 Commits (2) - [`e1111b5`](https://github.com/morluto/rea/commit/e1111b5f2e1cc82566424a01612bc0a0252c550a) feat(update): update Bun global installations - [`5963280`](https://github.com/morluto/rea/commit/5963280de94622d5a5380ff6607f8bc6a94d8ad3) fix(update): gate Bun self-updates on supported CLI versions ### 📊 Changes **8 files changed** (+492 additions, -51 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+5 -2) 📝 `docs/installation.md` (+16 -4) 📝 `src/application/Update.test.ts` (+120 -8) 📝 `src/application/Update.ts` (+53 -22) 📝 `src/application/UpdateRuntime.release.test.ts` (+2 -1) 📝 `src/application/UpdateRuntime.ts` (+154 -12) 📝 `src/cliLogging.test.ts` (+2 -1) 📝 `tests/process-global/updateMaintenance.test.ts` (+140 -1) </details> ### 📄 Description ## Summary `rea update` only knew npm global installs. If you installed REA with `bun add --global rea-agents` on a machine that has Bun but no npm, it stopped right away: ```json {"status":"failed","currentVersion":"6.4.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: spawn npm ENOENT..."} ``` With this PR, `rea update` recognizes a Bun global installation of the running package. It looks up the latest release with Bun, installs it with Bun into the same global directory, checks the installed entry point's version, and plans integration maintenance the same way it does for npm. npm installations use the same commands and messages as before. No linked issue. The problem was seen on a Bun-only Windows machine. ## Problem and expected behavior - Trigger: run `rea update` from a `bun add --global` install (`$BUN_INSTALL/install/global/node_modules/rea-agents`, with `~/.bun` as the default `BUN_INSTALL`). - Before: `detectNpmInstallation` recognizes only npm's global root or a `<prefix>/lib/node_modules/rea-agents` layout. A Bun install becomes "unknown", so the release lookup falls back to `npm view`. Without npm, that fails with `spawn npm ENOENT`. With npm present, the update can only fail with `unknown-install-method`. - Expected: a Bun global install updates itself with Bun, under the same guarantees as npm: exact resolved version, installed into the directory that owns the running package, verified by running that package's entry point, and a maintenance plan that is not applied. ## Change and scope - `Update.ts` (workflow): an installation is now `NpmInstallation | BunInstallation`, with a `manager` discriminant. `installMethod` reports `"npm"`, `"bun"`, or `"unknown"`. For Bun, `updateInstallCommand` returns `bun add --global --ignore-scripts rea-agents@<version>`. Install and verification remediation messages name the manager and its location; for npm the text is unchanged. - `UpdateRuntime.ts` (system host): - `bunGlobalDirectory` follows Bun's precedence for the global project directory: `BUN_INSTALL_GLOBAL_DIR`, then `$BUN_INSTALL/install/global`, then `$XDG_CACHE_HOME/.bun/install/global`, then `~/.bun/install/global`. The home directory comes from the existing `homeDirectoryFromEnvironment`, so it is `USERPROFILE` on Windows. I checked each step with throwaway roots under Bun 1.4.2 on Windows. - `detectBunInstallation` matches only when the canonical package root equals `<globalDir>/node_modules/rea-agents` **and** `<globalDir>/package.json` exists. It is location-based, so a Bun global install running under Node is still detected. It runs before npm detection, so Bun installs don't spawn `npm`. npm detection is unchanged. - Release lookup for Bun uses `bun info rea-agents dist-tags.latest --json`, which honors Bun's registry configuration. Its output (a JSON string) goes through the existing `npmReleaseLookup` parser. - Bun subprocesses (`bun info` and `bun add`) run with `cwd` set to the owning global directory and `BUN_INSTALL_GLOBAL_DIR` set to that same directory. This plays the role of npm's `--prefix`. `runUpdateCommand` got an optional working-directory parameter for this. npm subprocesses keep the caller's working directory and environment as before. - **Hazard and guard.** Under Bun 1.4.2 on Windows, if Bun's global directory has no `package.json`, `bun add --global` walks up to the nearest ancestor `package.json` and installs into that project. I hit this while probing: with `BUN_INSTALL` pointed at a temp directory under `C:\Users\<user>\AppData\Local\Temp`, `bun add -g rea-agents@6.3.0` rewrote `C:\Users\<user>\package.json`, `bun.lock` and `node_modules` (restored right away). Also, `bun info` refuses to run unless its working directory is inside a project. Guards: 1. Detection requires `<globalDir>/package.json`. Without it, the installation is not treated as Bun-owned, so `rea update` never runs `bun add` there. 2. Bun commands run inside the owning global directory with that directory pinned, so the shell's current directory and any project it belongs to are never selected. - Not included: Bun global directories set only through `bunfig.toml` `install.globalDir`, which REA cannot see without parsing bunfig; layouts where Bun already installed into an ancestor project because of the walk-up above; `bunx` invocations (still "unknown", as `npx` is); and the release lookup for unknown installations, which still uses npm as before. ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/application/Update.ts` (installation model, install command) and `src/application/UpdateRuntime.ts` (detection and package-manager effects). - CLI and MCP/tool-catalog contract: the `rea update` JSON result can now report `installMethod: "bun"`, with a Bun `command`. No other fields changed and no MCP tools changed. - Provider, bridge, target-format, or platform compatibility: not applicable to providers. Bun global layout detection follows Bun's documented environment variables on every platform. Only Windows x64 was exercised with real Bun. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: `rea update` can now spawn `bun info` and `bun add --global --ignore-scripts`, always with the owning Bun global directory as `cwd` and `BUN_INSTALL_GLOBAL_DIR`. Arguments go through `cross-spawn` as literals, like the npm path. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: no generated metadata or package changes. Updated `README.md` (Update section and bug FAQ) and `docs/installation.md` (update behavior and the "Diagnose, update, and remove" section). ## Evidence and regression coverage - Tests added or updated: - `tests/process-global/updateMaintenance.test.ts` › "updates a Bun global installation from inside its global project": runs `runUpdate` with the real `systemUpdateHost` and real subprocesses. A recording `bun` executable (`bun.cmd` on Windows, a shell script elsewhere) on `PATH` plays the registry and installer. The test checks `installMethod: "bun"`, the exact `bun add` command, the verified version read back from the package's own `scripts/rea.mjs`, and that both `bun info` and `bun add` ran with `cwd` and `BUN_INSTALL_GLOBAL_DIR` equal to the owning global directory. Mutation check: when I removed the working-directory pin, this test failed because the recorded `cwd` was the repository root. - `src/application/Update.test.ts`: Bun update and current paths through `runUpdate`; Bun ownership (match, missing global `package.json`, package roots outside the global project, unresolvable path); `bunGlobalDirectory` precedence, including Windows `USERPROFILE`. Existing npm ownership assertions now include `manager: "npm"`. - `src/application/UpdateRuntime.release.test.ts`, `src/cliLogging.test.ts`: fixtures updated for the `manager` discriminant. - Base reproduction or other evidence: the base failure above was observed on Windows with Bun and no npm. Bun behavior I observed under Bun 1.4.2 on Windows x64, using throwaway roots outside the home tree: - `bun add -g` from a cwd inside an unrelated project with its own `package.json` left that project untouched. - `bun add -g` with an empty global directory below an ancestor `package.json` installed into the ancestor (the hazard above). - `bun info rea-agents dist-tags.latest --json` printed `"6.4.0"` inside the global directory. Outside any project it printed `error: Bun could not find a package.json file to install from`. - `BUN_INSTALL_GLOBAL_DIR` and `XDG_CACHE_HOME` were both honored for the global directory. - User-visible CLI/MCP output: real end-to-end smoke on Windows x64, Bun 1.4.2, no Node.js or npm. 1. Created a temp root `C:\rea-bun-smoke-<random>` (outside the user's home tree), with `BUN_INSTALL=<root>\bun` and `HOME`/`USERPROFILE=<root>\home`. Ran `bun add -g rea-agents@6.3.0` from `<root>`. 2. Overlaid this branch's compiled `dist/`, `scripts/` and `package.json` onto `<root>\bun\install\global\node_modules\rea-agents`, then set its `package.json` version and `dist/generatedPackageMetadata.js` version to `6.3.0`. `bun <pkg>\scripts\rea.mjs --version` printed `6.3.0`. 3. Created an unrelated project `<root>\project\package.json` and recorded its hash, plus hashes and mtimes of the real `~/package.json`, `~/bun.lock`, `~/node_modules/rea-agents`, `~/.bun/bin/*`, `~/.bun/install/global`, and the worktree's `git status`. 4. From `cwd=<root>\project`, ran `bun <root>\bun\install\global\node_modules\rea-agents\scripts\rea.mjs update --format json`. It exited 0, wrote nothing to stderr, and printed: ```json {"status":"updated","previousVersion":"6.3.0","latestVersion":"6.4.0","installedVersion":"6.4.0","installMethod":"bun","command":["bun","add","--global","--ignore-scripts","rea-agents@6.4.0"],"maintenance":{"status":"current","plannedActions":[]},"remediation":"REA is updated. Restart agents running this installation to load the new version."} ``` 5. Afterwards: `<root>\bun\install\global\package.json` lists `"rea-agents": "6.4.0"`. The installed package is the registry 6.4.0 (the overlay is gone and `generatedPackageMetadata.js` says `6.4.0`). The regenerated shim `<root>\bun\bin\rea.exe --version` printed `6.4.0`. `<root>\project` still held only its original `package.json` with the same hash. The before/after snapshot of everything outside the temp root was identical. I deleted the temp root. - Remaining proof gaps: real Bun was exercised only on Windows x64. Linux and macOS Bun global layouts are covered only by the recorder test and `bunGlobalDirectory` unit cases. The Node-runtime-with-Bun-install combination was not run (Node is not installed here); detection does not depend on the runtime. Bun's walk-up was observed only on Windows. `bunfig.toml` `install.globalDir` is not detected. For evidence-bearing changes: not applicable (no Evidence records change). - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Local validation ran under Bun 1.4.2 on Windows x64 without Node.js or npm, on this commit rebased onto `main` at e36c82be. CI covers Node. - `bun --bun run compile` and every `artifacts:*` generator (`skills`, `mcp-catalog`, `product-catalog`, `managed-evidence`, `error-schema`): succeeded. - `bun --bun run test:local -- src/application/Update.test.ts src/application/UpdateRuntime.release.test.ts src/cliLogging.test.ts`: 3 files, 50 tests passed. - `bun --bun node_modules/vitest/vitest.mjs run tests/process-global/updateMaintenance.test.ts`: 18 tests passed. Before the rebase, removing the working-directory pin made the new Bun test fail on the recorded `cwd`; it passed again after restoring the pin. - `bun --bun node_modules/vitest/vitest.mjs run tests/boundary/cli/cliStartupImports.test.ts` (covers the deferred `update` command loading on `main`): 2 passed, 3 failed. The same 3 fail on `main` under Bun: the test records imports through `--import` hooks from `node:module`, and under Bun the recorded lists come back empty. - `bun --bun run typecheck`: passed. - `bun --bun run lint` (oxlint plus module-boundary check): exit 0, no warnings in changed files. - `bun --bun node_modules/.bin/oxfmt --check` on LF-normalized copies of all 8 changed files: passed. (The Windows checkout uses CRLF, which oxfmt flags in every file.) - `bun --bun run docs:check:built`: exit 0. The `docs:check` wrapper could not run because it requires npm's `node_modules/.package-lock.json`. - Real Bun end-to-end smoke as described above, rerun on the rebased commit with the same result: `rea update` exited 0 with the JSON shown, the global `package.json` lists `rea-agents` 6.4.0, the shim prints `6.4.0`, the unrelated project was untouched, and the snapshot outside the temp root was identical. ## Compatibility, safety, and release - Breaking changes or migration steps: none. The `rea update` result type gains `installMethod: "bun"`. npm installs keep the same detection, commands, and message text. `NpmInstallation` gains a `manager: "npm"` field; it is internal and not part of the CLI/MCP contract. - Real Hopper/Ghidra, browser, or OS coverage: no providers involved. Real Bun on Windows x64 only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: `bun add --global` runs with `--ignore-scripts`. It is confined to the detected Bun global directory by `cwd` and `BUN_INSTALL_GLOBAL_DIR`, and it never runs when that directory lacks `package.json`, which would otherwise let Bun modify an ancestor project such as the user's home directory. The environment override applies only to that child process and is not persisted. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 00:55:01 +00:00

closed this issue
added the
pull-request
label

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#4785

No description provided.

Rows
Columns