What the agent does
In a Laravel app like pixelfed/pixelfed, the build today is Laravel Mix 6 on webpack 5. webpack.mix.js compiles seven Sass bundles from resources/assets/sass into public/css and a page-by-page set of JavaScript entries from resources/assets/js: app.js, activity.js, components.js, discover.js, profile.js, status.js, timeline.js and more, each to its own public/js file, ending in .version() for cache busting. package.json pins vue ^2.6.14 with Vuex 3 and keeps the scripts thin: npm run development, npm run watch and npm run production all call mix. The Blade side leans on it: 70 view files under resources/views call the mix() helper to resolve versioned asset URLs, starting with layouts like spa, blank, anon, bundle and admin.
The replacement mirrors that shape in Vite terms. The agent writes vite.config.js with laravel-vite-plugin, points it at the same entry files, and because the front end stays on Vue 2 for this job, uses the Vite plugin that supports Vue 2 single-file components so components under resources/assets/js/components keep compiling. Sass compilation moves into the Vite pipeline with the same output names, and the version() behavior is replaced by Vite's manifest plus the @vite Blade directive. package.json scripts change to vite and vite build, which is the one edit the composer build script cares about: composer.json defines build as npm ci && npm run production, so that script name must keep working.
Then the helper swap. Every mix() call in the 70 Blade files becomes an @vite directive naming the right entry, and the agent works layout by layout so the shared headers convert once. Routes that render Blade directly are checked against a build that has actually run: npm run production must complete and emit the manifest before any page can load. The agent also runs the PHP checks the repo defines, composer lint (pint, preset laravel) and the Pest suite via composer test against sqlite in memory, because a Blade edit can break rendering without touching JavaScript at all.
The visual proof is the point of the job, so the agent boots the app in the sandbox's browser and loads each main page: the landing page, login, the admin layout and the compose and timeline screens that carry the heaviest bundles. For each one it reads the browser console for 404s on scripts and styles and checks that the entry actually executed. Pages with a blank console and rendered content are the acceptance evidence; any missing asset is fixed and rechecked before the pull request opens.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Replace Laravel Mix with Vite in this app: add vite.config.js and laravel-vite-plugin, move entry points, replace every mix() helper with @vite, update package.json scripts, build, and load each main page in the browser checking the console for missing assets. Open a pull request.",
"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 contains vite.config.js, the rewritten package.json scripts, the 70 converted Blade files, and the removal of webpack.mix.js and the Mix dependencies. Its description lists the entry points moved and the pages loaded in the browser, each with its console clean. npm run production completes against the new config, composer build keeps working because its npm run production step is unchanged in name, and pint plus the Pest suite pass.
A reviewer samples the converted Blade files, paying attention to pages that loaded several mix() files where one @vite directive now names a single entry, since that is where a dropped stylesheet hides. The build artifact diff, public build output versus the old public/js and public/css layout, tells you whether every old bundle has a successor. The session read returns the repository and pull request information, and the transcript holds the vite build output and the browser checks page by page.
Run it on every build tooling issue opened
When an issue proposes a build-tool change like this one, your automation sends POST /o/{org}/sessions with the issue text and this prompt, and the conversion starts without anyone installing the toolchain locally. Install the Rush GitHub App on the repository first and authenticate with an API key; an Idempotency-Key header keeps a retried submission from starting two runs.
Keep the returned execution_id and read the session when the run settles, or receive the key's completion webhook. The list of pages proven in the browser is the fast check; if a screen you care about is missing from it, send a follow-up on the finished turn naming it, and the messages endpoint wakes the parked sandbox to load it and report.
The use case this job follows, with its automation and trigger: Hand off from your terminal.
Why run it on Rush?
A Mix to Vite move is two jobs glued together: a build-tool rewrite and a manual pass through every screen that could have lost an asset. The manual half is what never happens on a laptop after the build turns green. On Rush the agent runs the production build, serves the app and drives a real browser through the pages in the same sandbox, and the transcript keeps the console output for each one, so every page-load claim is backed by evidence.
For several Laravel apps, submit one repository per run within your key's concurrency allowance and each gets the same conversion plus its own browser pass. You review the pull requests independently, and the property to hold is the same everywhere: no page gains a missing asset. The useful proof is a build log plus per-page console checks, not a green build alone.
Frequently asked questions
Does the front end have to move off Vue 2 for this?
No. This job swaps the build tool, not the framework. The Vite config uses the plugin that compiles Vue 2 single-file components, so the components under resources/assets/js/components keep working; a Vue 3 migration is a separate job on the same repository.
What happens to cache busting from mix .version()?
It is replaced by Vite's manifest and the @vite directive, which generates versioned URLs the same way. The agent checks that the built manifest exists after npm run production, because every @vite call fails loudly without it.
How do I know every page still loads?
The agent loads each main page in the sandbox's browser and reads the console for missing scripts or styles, and the transcript holds that output. A green build alone is not the claim; per-page console checks are.
Will composer build keep working?
composer.json defines build as npm ci && npm run production, so the migration keeps the production script name and points it at vite build. That contract is verified by running the build, not assumed.
What are the PHP tests for in a JavaScript migration?
The Blade files are PHP, and a bad @vite call breaks page rendering server-side. The run executes pint and the Pest suite, which exercise the views, so a Blade mistake is caught by PHP tests rather than by a user later.