# Upgrade Electron and npm Dependencies in an Electron App

Yes. An agent upgrades Electron and your npm packages, runs npm test, npm run package and a startup smoke test, and opens a PR without the bumps that fail.

[Run this on Rush](https://cloud.getrush.ai/run/upgrade-electron/electron/), in a Project that has your repository.

## What the agent does

An Electron app like electron-react-boilerplate/electron-react-boilerplate has more than one dependency tree. The root package.json carries the app and its build tools (electron ^44.4.0, electron-builder ^26.15.3, electron-vite ^5.0.0, React ^19.3.0, Jest ^30.5.1, TypeScript ^7.0.2) with package-lock.json beside it. release/app has its own package.json and lockfile for native modules that ship inside the packaged app, and .erb/tooling has a third, holding ts-jest, ts-node, typescript ^6.0.3 and the typescript-eslint packages. The root postinstall runs npm --prefix .erb/tooling ci, then install-electron and electron-builder install-app-deps, so the agent upgrades all three trees and keeps them installable with npm ci.

The engines and devEngines blocks require Node 24 or later and npm 10 or later with onFail set to error, so the agent installs with Node 24, the version the Test workflow uses. It runs npm outdated in each of the three directories, raises versions within their ranges with npm update, and checks Electron on its own: a new Electron major brings a new Chromium and Node inside the app, so it is a separate line in the pull request with the Electron release notes link rather than a routine bump.

Verification follows the Test workflow in .github/workflows/test.yml. After npm ci, the agent runs npm run package (electron-vite build followed by electron-builder build --publish never), npm run lint, npm exec tsc -- --noEmit and npm test. Jest picks up src/__tests__/App.test.tsx and src/__tests__/updates.test.ts; the second mocks electron, electron-updater and electron-log and checks that a development start never contacts the update service. Those mocks mean Jest alone does not prove the new Electron starts, so the agent also runs npm run test:smoke under xvfb-run, the same way the workflow does on Linux: .erb/scripts/smoke-test.cjs starts the app with npm start and attaches to it over a remote debugging port, so it proves the new Electron actually boots.

When a step fails, the agent splits the updated packages into halves, reinstalls and re-runs the failing step until one package is left, then pins it back to its locked version and keeps the error. A package that breaks only the smoke test, such as an electron-updater release that changes startup, is reported with the smoke script's output. The final state is checked again from a clean npm ci in all three directories before the pull request opens.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "codex",
  "input": "Upgrade Electron and the npm dependencies in this app to the latest compatible versions with npm. There are three lockfiles: the root, release/app and .erb/tooling; update each one and keep npm ci working in all three. Use Node 24 as the engines field requires. Before changing anything, run npm ci, npm run package, npm run lint, npm exec tsc -- --noEmit, npm test and xvfb-run --auto-servernum npm run test:smoke for a baseline. After the upgrade run the same commands. Leave out any upgrade that breaks one of them that passed in the baseline, and say why with the failing command and its error. Treat a new Electron major as its own line with a link to its release notes. Open a pull request with one line per bump.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The pull request changes package.json and package-lock.json at the root, and the lockfiles under release/app and .erb/tooling when those trees moved. The description has one line per bumped package with old and new version, grouped by directory, and an Electron line at the top that names the Chromium and Node versions the new release bundles if it is a major. Below that is the list of upgrades left out, each with the command that failed (npm test, npm run package or test:smoke) and the first lines of its output.

A reviewer installs the build from the branch and opens the app on a Mac or Windows machine, because the sandbox runs only the Linux smoke test and the workflow's macOS and Windows jobs only start the app. They also check whether @electron/notarize or electron-builder moved, since signing and notarizing are configured through them and are not exercised by publish never. The run's transcript has every command and its output for reference.

## Run it on every new Electron stable release

Electron publishes a new stable major on a regular cadence, and each one moves Chromium. A small job that watches the electron package on the npm registry, or a weekly cron, can send POST /o/{org}/sessions with this request whenever the latest tag changes. Use the Electron version as part of the Idempotency-Key so the same release never starts two runs.

Set a webhook on the key to receive run.completed. Your handler reads the session, takes the pull request link, and posts it to the desktop team with the Electron version in the message, so the review starts the same day the release lands rather than when someone notices it.

## Why run it on Rush?

Packaging an Electron app downloads the Electron binary, builds the main and renderer bundles, and runs electron-builder, and the smoke test needs a display server. That is a lot of state to set up and tear down on a developer's laptop each time an upgrade is checked. The agent does it in its own Rush sandbox, runs xvfb-run for the smoke test, and the output of every command is kept in the session.

Bots that open one pull request per package cannot tell whether an Electron bump also needs a newer electron-builder, and a red Electron pull request tends to sit open. The agent's run tries the bumps together, drops the ones that break packaging or startup, and explains each, so the pull request is one a reviewer can install and try. Several desktop apps can be checked at once within the key's concurrency limit.

## Frequently asked questions

### Does it build installers for macOS and Windows?

No. The sandbox is Linux, so npm run package produces the Linux build and the smoke test starts the app under xvfb. Your existing Test workflow still runs on macos-latest and windows-latest for the pull request, and that is where those platforms are checked.

### Why are there three lockfiles?

The root holds the app and build tools, release/app holds native modules that are rebuilt against Electron's Node, and .erb/tooling holds lint and TypeScript tooling the root postinstall installs with npm ci. The agent updates each so all three postinstall steps succeed.

### Will a new Electron major be applied?

The prompt asks for the latest compatible versions, and the root range ^44.4.0 stays within Electron 44. If a newer major exists, the agent lists it as its own line with release notes rather than editing the range, unless you change the prompt to ask for it.

### Is npm test enough to trust the upgrade?

Not on its own. updates.test.ts mocks electron and electron-updater, so it checks the app's code, not the new Electron. The smoke test starts the real Electron process and connects to it, and the pull request says whether it passed.