testing bun as a node replacement#341
Conversation
WalkthroughThe pull request migrates the project's development and CI/CD infrastructure from Node.js/npm to Bun as the primary runtime and package manager. Changes span configuration files, GitHub workflows, development documentation, build scripts, and the Electron main process bootstrap logic. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
README.md (1)
32-42:⚠️ Potential issue | 🟡 MinorAdd a Bun installation prerequisite to Quick Start.
The Quick Start now jumps straight into
bun install/bun run devwithout telling first-time users that Bun must be installed (and Node is no longer required).CONTRIBUTING.mdmentions this prereq, butREADME.mdis the entry point most contributors land on first.📝 Suggested addition
### Quick Start +0. Install [Bun](https://bun.sh/) (v1.0+). Node.js is no longer required. 1. Install dependencies: ```bash bun install ```🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` around lines 32 - 42, Update the Quick Start section in README.md to add a prerequisite note that Bun must be installed (Node is not required), referencing the Quick Start block so it's obvious to first-time users; include a brief install instruction (e.g., "Install Bun: follow https://bun.sh or run the Bun installer") and mention that after installing Bun they should run `bun install` and `bun run dev` as currently shown in the Quick Start.electron/main.cjs (1)
55-63:⚠️ Potential issue | 🔴 CriticalSpawning
bunwill fail in packaged distributions—Bun is not bundled by electron-builder.The packaged app will not have Bun on the runtime PATH, so
spawn('bun', [serverPath])will fail withENOENTon end-user machines. This breaks production builds at startup.Mitigations:
- Bundle Bun as an
extraResourceand resolve its absolute path here.- Compile the server to a self-contained executable via
bun build --compileand spawn that instead.- Keep Node as the runtime for the spawned server (simplest option).
On Windows, spawning 'bun' without
shell: truecan also fail if Bun is only available as a shim; resolving an absolute path avoids this.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@electron/main.cjs` around lines 55 - 63, The current spawn call spawn('bun', [serverPath], ...) will fail in packaged builds because Bun is not guaranteed on PATH; replace this by resolving and using an absolute runtime path or a self-contained server binary: either (A) bundle Bun as an extraResource and resolve that absolute path and use spawn(resolvedBunPath, [serverPath], { windowsHide: true, stdio, env }), or (B) compile the server into a standalone executable (bun build --compile) and spawn(compiledServerPath, ...), or (C, simplest) run the server with the packaged Node runtime using spawn(process.execPath, [serverPath], ...) so you call Node instead of 'bun'; ensure you preserve serverProcess, serverPath, serverHost, serverPort and the env spread and consider shell: true on Windows if Bun is only available as a shim.
♻️ Duplicate comments (1)
.github/workflows/build.yml (1)
32-46: 🧹 Nitpick | 🔵 TrivialSame pin/frozen-lockfile concern as
ci.yml.This workflow runs across
windows-latest,ubuntu-latest, andmacos-latest, which amplifies the risk of an unpinnedoven-sh/setup-bun@v2plus non-frozenbun install: a single upstream Bun change can red the entire matrix simultaneously, and lockfile drift inbun.lockbwould silently differ between OSes.Apply the same fix recommended on
ci.ymlhere (pinbun-versionand usebun install --frozen-lockfile).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build.yml around lines 32 - 46, The workflow currently uses oven-sh/setup-bun@v2 without a pinned bun-version and runs "bun install" permissively; update the "Setup Bun" step to include an explicit bun-version input (pin to the tested Bun release) and change the "Install dependencies" step to run "bun install --frozen-lockfile" so installs are reproducible across windows-latest, ubuntu-latest and macos-latest; adjust the step names "Setup Bun" and "Install dependencies" accordingly to locate the edits.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 15-19: Pin the Bun setup action and make installs reproducible:
change the GitHub action step using oven-sh/setup-bun@v2 to pin a specific Bun
release (e.g., set the action's input like bun-version or switch to
oven-sh/setup-bun@v2 with a fixed version tag) or add "packageManager":
"bun@<major>.<minor>.x" to package.json so the action detects the version, and
modify the Install dependencies step to run bun install --frozen-lockfile
instead of bun install to fail on lockfile drift.
In `@package.json`:
- Line 84: The package.json currently sets "npmRebuild": false which skips
native-module rebuilding during packaging and can cause local builds (when
running "dist") to include unrebuilt natives; add a "predist" script that runs
the electron-builder install-app-deps command (e.g., "predist": "bunx
electron-builder install-app-deps") so that "npm run dist" will invoke that step
automatically before packaging, and ensure the "dist" script remains the
electron-builder invocation (e.g., "dist": "electron-builder") so local and CI
workflows rebuild native modules consistently.
---
Outside diff comments:
In `@electron/main.cjs`:
- Around line 55-63: The current spawn call spawn('bun', [serverPath], ...) will
fail in packaged builds because Bun is not guaranteed on PATH; replace this by
resolving and using an absolute runtime path or a self-contained server binary:
either (A) bundle Bun as an extraResource and resolve that absolute path and use
spawn(resolvedBunPath, [serverPath], { windowsHide: true, stdio, env }), or (B)
compile the server into a standalone executable (bun build --compile) and
spawn(compiledServerPath, ...), or (C, simplest) run the server with the
packaged Node runtime using spawn(process.execPath, [serverPath], ...) so you
call Node instead of 'bun'; ensure you preserve serverProcess, serverPath,
serverHost, serverPort and the env spread and consider shell: true on Windows if
Bun is only available as a shim.
In `@README.md`:
- Around line 32-42: Update the Quick Start section in README.md to add a
prerequisite note that Bun must be installed (Node is not required), referencing
the Quick Start block so it's obvious to first-time users; include a brief
install instruction (e.g., "Install Bun: follow https://bun.sh or run the Bun
installer") and mention that after installing Bun they should run `bun install`
and `bun run dev` as currently shown in the Quick Start.
---
Duplicate comments:
In @.github/workflows/build.yml:
- Around line 32-46: The workflow currently uses oven-sh/setup-bun@v2 without a
pinned bun-version and runs "bun install" permissively; update the "Setup Bun"
step to include an explicit bun-version input (pin to the tested Bun release)
and change the "Install dependencies" step to run "bun install
--frozen-lockfile" so installs are reproducible across windows-latest,
ubuntu-latest and macos-latest; adjust the step names "Setup Bun" and "Install
dependencies" accordingly to locate the edits.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3892651b-de88-4fe6-ba3f-2c9a73b3580b
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (8)
.cta.json.github/workflows/build.yml.github/workflows/ci.ymlCONTRIBUTING.mdREADME.mdelectron/main.cjspackage.jsonshell.nix
| - name: Setup Bun | ||
| uses: oven-sh/setup-bun@v2 | ||
|
|
||
| - name: Install dependencies | ||
| run: npm install | ||
| run: bun install |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
🌐 Web query:
oven-sh/setup-bun action default version and bun install --frozen-lockfile flag
💡 Result:
The oven-sh/setup-bun GitHub Action's default version is v2 (latest release v2.2.0 as of March 2026). When no bun-version is specified in the workflow, it checks package.json for "packageManager" (e.g., "[email protected]") or "engines.bun", falling back to the latest Bun version if neither is found or package.json is absent. The bun install --frozen-lockfile flag ensures reproducible installs by using exact versions from bun.lockb or bun.lock. It fails if package.json disagrees with the lockfile and does not update the lockfile. This is recommended for CI and equivalent to bun ci. It is not enabled by default; bun install normally updates the lockfile. There is an open proposal for a flag to disable frozen-lockfile behavior (e.g., --no-frozen-lockfile), but none exists currently.
Citations:
- 1: https://github.com/oven-sh/setup-bun
- 2: https://github.com/oven-sh/setup-bun/tree/refs/heads/main
- 3: https://github.com/marketplace/actions/setup-bun
- 4: https://bun.sh/docs/pm/cli/install
- 5: https://bun.com/docs/guides/runtime/cicd
Pin the Bun version and use --frozen-lockfile for reproducible CI.
Two reproducibility issues with the current setup:
-
oven-sh/setup-bun@v2will default to the latest Bun release if yourpackage.jsondoesn't specify a version via thepackageManagerfield orengines.bun. This means a future Bun release can silently break CI without any code change in this repo. -
bun installwill updatebun.lockbif it drifts frompackage.json. In CI, you want a strict, lockfile-faithful install that fails on drift rather than silently mutating dependencies.
♻️ Suggested change
- name: Setup Bun
uses: oven-sh/setup-bun@v2
+ with:
+ bun-version: 1.2.x
- name: Install dependencies
- run: bun install
+ run: bun install --frozen-lockfileAlternatively, add "packageManager": "[email protected]" to package.json to let the action detect the version automatically.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml around lines 15 - 19, Pin the Bun setup action and
make installs reproducible: change the GitHub action step using
oven-sh/setup-bun@v2 to pin a specific Bun release (e.g., set the action's input
like bun-version or switch to oven-sh/setup-bun@v2 with a fixed version tag) or
add "packageManager": "bun@<major>.<minor>.x" to package.json so the action
detects the version, and modify the Install dependencies step to run bun install
--frozen-lockfile instead of bun install to fail on lockfile drift.
| "package.json" | ||
| ], | ||
| "npmRebuild": true, | ||
| "npmRebuild": false, |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
electron-builder npmRebuild option Bun package manager compatibility
💡 Result:
The npmRebuild option in electron-builder controls whether native dependencies are rebuilt before packaging the app (default: true). It is a boolean configuration in the build section of package.json. electron-builder has partial compatibility with Bun as the package manager. It detects Bun usage and falls back to manual node_modules traversal or NPM tools since Bun lacks certain CLI support for dependency tree extraction (e.g., no equivalent to npm ls). This can lead to warnings like "bun does not support any CLI for dependency tree extraction, falling back to NPM node module collector" and potential issues such as failed production dependency validation (e.g., ignoring overrides) or path resolution errors. npmRebuild itself functions during the packaging process regardless of the package manager, as rebuilding uses electron-rebuild (or similar), which is Node-based. However, if your workflow involves electron-builder install-app-deps in postinstall (recommended for native deps), it may fail with Bun due to missing "rebuild" scripts or CLI incompatibilities. Workarounds: - Use npmRebuild: false to skip rebuild during packaging if prebuilt binaries are compatible. - Manually run native rebuilds: "postinstall": "bun x @electron/rebuild" or specify modules. - For dependency issues, use patch-package or switch to npm/yarn/pnpm for building. - Recent electron-builder versions (26+) improve Bun support via fallbacks, but open issues persist as of 2026. Bun native modules may have compatibility gaps, but electron-builder proceeds with manual handling.
Citations:
- 1: https://www.electron.build/configuration.html
- 2: Not compatible with Bun electron-userland/electron-builder#9434
- 3: Does not work with electron-builder oven-sh/bun#9895
- 4: electron-builder Bun node-modules traversal ignores overridden dependency resolution and fails production dependency validation electron-userland/electron-builder#9641
- 5:
npmRebuild: falsewill skip dependency installation altogether electron-userland/electron-builder#9395 - 6: https://electron.build/electron-builder/index.html
🏁 Script executed:
#!/bin/bash
# Check build.yml for the install-app-deps command
if [ -f ".github/workflows/build.yml" ]; then
echo "=== build.yml (lines 40-60) ==="
sed -n '40,60p' .github/workflows/build.yml
elif [ -f "build.yml" ]; then
echo "=== build.yml (lines 40-60) ==="
sed -n '40,60p' build.yml
else
echo "=== Searching for build.yml ==="
find . -name "build.yml" -type f 2>/dev/null | head -5
fiRepository: AOSSIE-Org/Rein
Length of output: 647
🏁 Script executed:
#!/bin/bash
# Check package.json for scripts and dependencies
echo "=== package.json scripts section ==="
jq '.scripts' package.json 2>/dev/null || cat package.json | grep -A 30 '"scripts"'
echo ""
echo "=== package.json dependencies section (native modules) ==="
jq '.dependencies, .devDependencies' package.json 2>/dev/null | head -50Repository: AOSSIE-Org/Rein
Length of output: 1882
🏁 Script executed:
#!/bin/bash
# Check electron-builder configuration and version
echo "=== electron-builder version ==="
jq '.devDependencies."electron-builder"' package.json
echo ""
echo "=== electron-builder build config ==="
jq '.build' package.jsonRepository: AOSSIE-Org/Rein
Length of output: 601
Add a predist script to ensure consistent native-module rebuild across local and CI workflows.
Setting npmRebuild: false skips native-module rebuilding during packaging. This works in CI because build.yml explicitly runs bunx electron-builder install-app-deps before bun run dist, but local builds lack this safety mechanism—users running bun run dist directly will package unbuilt natives, creating silent breakage on end-user machines.
Add a predist script in package.json to enforce the step:
"predist": "bunx electron-builder install-app-deps",
"dist": "electron-builder"This ensures local and CI workflows behave identically and prevents accidental packaging of un-rebuilt native modules (particularly relevant if future dependencies without prebuilts are added).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 84, The package.json currently sets "npmRebuild": false
which skips native-module rebuilding during packaging and can cause local builds
(when running "dist") to include unrebuilt natives; add a "predist" script that
runs the electron-builder install-app-deps command (e.g., "predist": "bunx
electron-builder install-app-deps") so that "npm run dist" will invoke that step
automatically before packaging, and ensure the "dist" script remains the
electron-builder invocation (e.g., "dist": "electron-builder") so local and CI
workflows rebuild native modules consistently.
|
Please resolve the merge conflicts before review. Your PR will only be reviewed by a maintainer after all conflicts have been resolved. 📺 Watch this video to understand why conflicts occur and how to resolve them: |
This PR replaces Node.js with Bun across the whole project. After this change, anyone cloning or forking the repo only needs Bun installed, no Node.js required. All npm commands are replaced with bun, CI is updated to use Bun, and the lockfile is switched from package-lock.json to bun.lockb.
nut-js works fine as well since it ships prebuilt binaries for Windows, Linux and Mac so no compilation or node-gyp is needed at all.
Note: this is safe for all developers cloning or forking the repo. However if someone ever packages this as an exe or AppImage for end users, they will need to bundle Bun with the app or change the server spawn approach in electron/main.cjs.
Summary by CodeRabbit