Skip to content

testing bun as a node replacement#341

Open
b-u-g-g wants to merge 1 commit into
AOSSIE-Org:mainfrom
b-u-g-g:feat/replace-node-with-bun
Open

testing bun as a node replacement#341
b-u-g-g wants to merge 1 commit into
AOSSIE-Org:mainfrom
b-u-g-g:feat/replace-node-with-bun

Conversation

@b-u-g-g
Copy link
Copy Markdown

@b-u-g-g b-u-g-g commented Apr 27, 2026

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

  • Chores
    • Migrated the project's complete tooling stack from Node.js/npm to Bun, updating all development and build scripts across CI/CD pipelines and configuration files.
    • Updated packaging and runtime commands to use Bun's tooling instead of npm equivalents.
    • Revised all developer documentation and setup instructions to reflect the new Bun-based environment.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 27, 2026

Walkthrough

The 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

Cohort / File(s) Summary
Package Manager Configuration
.cta.json, package.json
Switches declared package manager from npm to bun; updates electron script invocation from npx to bunx and disables npm rebuild in Electron Builder config.
CI/CD Workflows
.github/workflows/build.yml, .github/workflows/ci.yml
Replaces Node setup with Bun setup; updates all npm commands (npm install, npm run build) to bun equivalents (bun install, bun run build); converts npx to bunx for tool invocation.
Documentation
README.md, CONTRIBUTING.md
Updates development instructions and prerequisites to use bun instead of npm; replaces all npm command references with bun equivalents.
Development Environment
shell.nix, electron/main.cjs
Removes Node.js from Nix shell dependencies and adds Bun; updates shellHook commands to use bun; changes Electron server spawn executable from node to bun.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested labels

Typescript Lang, Documentation

Poem

🐰 Hop, hop, the runtime's switched with glee,
From npm's node to Bun so spry and free,
CI workflows leap, scripts now dash about,
With bunx and bun, there's no more doubt!
Our little project's tooling shines anew,

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description clearly explains the changes and implications but does not follow the repository's required template structure with sections like 'Addressed Issues', 'Functional Verification', and checklist items. Fill in the required template sections including 'Addressed Issues' (link relevant issue), 'Description', 'Functional Verification' (check applicable boxes), and complete the 'Checklist' section.
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title 'testing bun as a node replacement' accurately summarizes the main change: replacing Node.js with Bun throughout the project.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 | 🟡 Minor

Add a Bun installation prerequisite to Quick Start.

The Quick Start now jumps straight into bun install / bun run dev without telling first-time users that Bun must be installed (and Node is no longer required). CONTRIBUTING.md mentions this prereq, but README.md is 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 | 🔴 Critical

Spawning bun will 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 with ENOENT on end-user machines. This breaks production builds at startup.

Mitigations:

  1. Bundle Bun as an extraResource and resolve its absolute path here.
  2. Compile the server to a self-contained executable via bun build --compile and spawn that instead.
  3. Keep Node as the runtime for the spawned server (simplest option).

On Windows, spawning 'bun' without shell: true can 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 | 🔵 Trivial

Same pin/frozen-lockfile concern as ci.yml.

This workflow runs across windows-latest, ubuntu-latest, and macos-latest, which amplifies the risk of an unpinned oven-sh/setup-bun@v2 plus non-frozen bun install: a single upstream Bun change can red the entire matrix simultaneously, and lockfile drift in bun.lockb would silently differ between OSes.

Apply the same fix recommended on ci.yml here (pin bun-version and use bun 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

📥 Commits

Reviewing files that changed from the base of the PR and between 1ae4791 and e4e4b15.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (8)
  • .cta.json
  • .github/workflows/build.yml
  • .github/workflows/ci.yml
  • CONTRIBUTING.md
  • README.md
  • electron/main.cjs
  • package.json
  • shell.nix

Comment thread .github/workflows/ci.yml
Comment on lines +15 to +19
- name: Setup Bun
uses: oven-sh/setup-bun@v2

- name: Install dependencies
run: npm install
run: bun install
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 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:


Pin the Bun version and use --frozen-lockfile for reproducible CI.

Two reproducibility issues with the current setup:

  1. oven-sh/setup-bun@v2 will default to the latest Bun release if your package.json doesn't specify a version via the packageManager field or engines.bun. This means a future Bun release can silently break CI without any code change in this repo.

  2. bun install will update bun.lockb if it drifts from package.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-lockfile

Alternatively, 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.

Comment thread package.json
"package.json"
],
"npmRebuild": true,
"npmRebuild": false,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 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:


🏁 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
fi

Repository: 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 -50

Repository: 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.json

Repository: 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.

@github-actions
Copy link
Copy Markdown

⚠️ This PR has merge conflicts.

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:
https://www.youtube.com/watch?v=Sqsz1-o7nXk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant