What the agent does
In chibat/chrome-extension-typescript-starter the agent reads package.json and the package-lock.json beside it: react and react-dom ^18.2.0 as the only runtime dependencies, and on the dev side webpack ^5.94.0 with webpack-cli ^4.0.0 and webpack-merge ^5.0.0, ts-loader ^8.0.0, typescript ^5.0.4, jest ^29.5.0 with ts-jest and @types/jest, prettier ^2.2.1, copy-webpack-plugin ^14.0.0, glob ^7.1.6, rimraf ^3.0.2 and @types/chrome pinned at 0.0.158. Several of those ranges are a major or more behind their current releases, and the pinned Chrome types are the one place a pin rather than a range decides what moves.
The build is webpack/webpack.common.js merged with webpack.prod.js in production mode: four entries, popup.tsx, options.tsx, background.ts and content_script.tsx, emitted to dist/js, a vendor chunk split from every entry except background because a service worker cannot load a second script, and copy-webpack-plugin copying public, with manifest.json, popup.html, options.html and the icon, to dist. public/manifest.json is Manifest V3 with js/background.js as the service worker, js/vendor.js and js/content_script.js injected on all URLs, the storage permission and host permissions for all URLs. tsconfig.json compiles with strict, target es6, moduleResolution bundler and jsx react, with noEmitOnError, so a type error from a new @types/react or @types/chrome stops the build rather than warning.
The checks are the two scripts build.yml runs on Node 20 and 22: npm ci, npm run build and npm test, where test is npx jest with jest.config.js rooted at src and ts-jest reading tsconfig.test.json. The only test is src/tests/sum.ts over src/sum.ts, so the agent treats the production build as the real check and reads the webpack output for the vendor split and the four entries. It runs the baseline, then npm outdated, then npm update to move every caret range to its newest version, and runs build and test again. Majors are tried one at a time: webpack-cli 4 to its current major, ts-loader 8 to 9, prettier 2 to 3, glob 7 and rimraf 3 to their current lines, and @types/chrome from its pin to the newest, each kept only if the build and tests pass.
A failure goes back to the previous version with the error recorded. React 19 and its types are listed but not applied, because the popup, options page and content script are small React 18 trees and a React major deserves its own review. The pull request commits package.json and package-lock.json, and its description notes the change in the vendor chunk or in dist file sizes when a bump altered them, since those are what a store listing will ship.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade the npm dependencies to the latest compatible versions with npm. Before changing anything run npm ci, npm run build and npm test for a baseline and keep the webpack output. Run npm update so each caret range moves to its newest version, then run npm run build and npm test again. Try the majors one at a time, including webpack-cli, ts-loader, prettier, glob, rimraf and the pinned @types/chrome, keeping each only when the production build and the tests pass. Leave React on its current major and list the newer one. Leave out any upgrade that breaks the build or tests and say why with the error. Commit package.json and package-lock.json and open a pull request with one line per bump.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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.
- 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.
- 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-lock.json and package.json, with one line per package in the description showing the old and new version, runtime dependencies first. The majors applied are marked as such, the bumps left out follow with the command and error, and React 19 appears in a short list of majors not applied. If the vendor chunk or an entry file changed size noticeably in the production build, the description says so with the before and after values from the webpack output.
A reviewer checks that build.yml passes on both Node versions, loads dist as an unpacked extension in Chrome and opens the popup and options page, since the Jest suite covers only sum.ts. The session record holds the baseline build, each npm install and each build and test run, so an excluded bump can be retried in a follow-up message to the same session.
Run it on every Monday morning
A scheduled workflow sends POST /o/{org}/sessions with this request and your repository in resources, with the org key as the bearer token and an Idempotency-Key built from the repository and the week, so a re-run of the workflow returns the run already started rather than a second pull request.
Put a webhook URL on the key. When the turn ends your endpoint receives run.completed with session_url, reads the pull request link from the session and posts it where extension releases are reviewed.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
An extension starter with a years-old toolchain needs several majors tried one by one, each with a full webpack build and a check of the emitted chunks. On a laptop that competes with the watch build a developer has running. In a Rush sandbox the agent has its own install and runs the build as many times as the majors need, with every output kept.
A per-package bot would open a pull request for each of those majors and leave the team to work out which combination of webpack-cli and ts-loader builds. The agent opens one pull request with the combination that passed, the ones that failed named with their errors, and the same request can run against every extension repository at once, up to the key's concurrency limit.
Frequently asked questions
The only test is sum.ts. What actually checks the upgrade?
The production webpack build with noEmitOnError in tsconfig.json, which fails on any type error from new React, Jest or Chrome types, and the shape of the output: four entries in dist/js, a vendor chunk, and the public files copied beside them. The pull request also suggests a smoke test for the popup when you want one.
Will it update @types/chrome?
Yes, it tries, because the version is pinned at 0.0.158 and a pin never moves on its own. The bump is kept only if background.ts, content_script.tsx and the React pages still compile; a change in the typed chrome namespace is reported with the error otherwise.
Why not React 19?
The popup, options page and content script are React 18 trees, and a React major changes rendering APIs and types together. The agent lists the available version so the team can take it in a dedicated pull request with a manual check in the browser.
Does it commit the lockfile?
Yes. The repository has a package-lock.json and the workflow installs with npm ci, which requires the lockfile to match package.json, so the pull request includes both files.