# Migrate a Laravel Front End from Vue 2 to Vue 3 Send Rush a Laravel repository to move its Vue 2 front end to Vue 3 and Vite component by component, and get a pull request with screenshots of the main screens. [Run this on Rush](https://cloud.getrush.ai/run/migrate-vue-2-to-vue-3/laravel/), in a Project that has your repository. ## What the agent does In a Laravel app like pixelfed/pixelfed, the front end is Vue 2.6 pinned as ^2.6.14 with Vuex 3, Bootstrap 4, and dozens of single-file components under resources/assets/js/components, each page booting from its own entry file: app.js, compose.js, discover.js, timeline.js, profile.js and the rest. The build is Laravel Mix 6 on webpack 5, so the migration is two moves at once: the bundler becomes Vite with laravel-vite-plugin and Vue 2 compilation, and the framework becomes Vue 3 through the official migration build. The agent reads webpack.mix.js and the entry list first, because every entry that exists today must exist after the move. The agent stages it with the migration build, @vue/compat, so the app boots under Vue 3 while incompatibilities surface as runtime warnings instead of compile errors. Component by component it works through the deprecations the build flags: filters, which Vue 3 removed and which must become computed properties or method calls; the v-model default and modifiers, whose argument and modifier syntax changed; Vue.set and the array mutation helpers the Vue 2 reactivity system no longer needs; event listeners registered through $on and $off, removed in Vue 3, which must move to an external emitter; and slot syntax updates in the layout components the other views inherit. Vuex 3 stays on its Vue 2 API surface during the compat phase, so store files are touched only where the compat build complains. Each screen is proved as it lands. The agent runs npm run production to rebuild, boots the app in the sandbox and loads the screen that owns the migrated component, starting with the heaviest: compose, timeline, discover and profile. A screen that renders with zero compat warnings is done; a screen that logs warnings gets those fixes before the next component. When the whole app is clean, the compat build comes out: @vue/compat and its aliases are removed from the Vite config, vue is pinned at 3, and any warning that reappears without the shim is fixed for real rather than suppressed. The backend contract is held throughout: composer.json defines build as npm ci && npm run production, so the production script keeps its name as it moves to Vite; the 70 Blade files calling mix() convert to @vite alongside the entries; and composer lint (pint) plus the Pest suite under composer test pass, because Blade and view rendering are PHP-side and a bad @vite call fails there first. The pull request lists every component migrated, every deprecation fixed, and anything deliberately left, such as a dependency that has no Vue 3 release yet. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "claude", "input": "Migrate this app's front end from Vue 2 to Vue 3 and from Laravel Mix to Vite. Use the migration build first, fix each deprecation, then remove it. Build, load the main screens in the browser and screenshot them, and open a pull request listing what changed and anything left.", "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 contains the Vite config, the Vue 3 dependencies with the compat build removed, the migrated components, the converted Blade files and the new package.json scripts. Its description lists each screen loaded in the browser with a screenshot attached, and names what is left, if anything. npm run production builds clean, pint and Pest pass, and composer build keeps working because the production script name survived the move. A reviewer reads the compat-removal commit first: after it, vue is pinned at 3 with no @vue/compat alias, which is the proof the migration is real rather than shimmed. The screenshots are the behavioral evidence, worth checking on compose and timeline where the interactive components live. The session read returns the repository and pull request information, and the transcript holds every build and every browser load, including the console warnings the compat phase produced and where each was fixed. ## Run it on every framework EOL issue opened When an issue tracks the end of life of a front-end framework, your automation sends POST /o/{org}/sessions with the issue text and this prompt, and the migration starts as tracked work rather than an intention. 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. Because a migration this size is component by component, the pull request description is the tracking artifact; a follow-up on the finished turn can ask the agent to continue with a specific component batch or to re-verify a screen whose screenshot looked off. ## Why run it on Rush? A Vue 2 to Vue 3 migration fails in the gaps between compile-green and actually-renders: a screen that builds but shows nothing, a store that works until the compat layer comes off. Doing it on Rush means each screen is loaded in a real browser in the same sandbox where the code changed, and the screenshots plus console output land in the transcript beside the commits. The work also runs to completion without occupying your machine for the days it takes. For a portfolio of Laravel apps on Vue 2, submit one repository per run within your key's concurrency allowance and the migrations proceed in parallel, each with its own component inventory and screenshot set. You review the pull requests independently. The useful proof is compat-build removal plus screenshots of the main screens, not a dependency bump alone. ## Frequently asked questions ### Why use the migration build at all? Because a big Vue 2 app does not compile-error its way to Vue 3; it warns its way there. @vue/compat lets the app boot under Vue 3 so each deprecation appears as a runtime warning on the screen that owns it, and the agent fixes them component by component before removing the shim. Removing it is what makes the migration verifiable. ### What are the common breakages in an app like this? The ones Vue 3 removed outright: filters, the $on/$off event API, Vue.set and the array mutation helpers, and the old v-model and slot syntax. Vuex 3 code mostly survives the compat phase, so the store is touched only where the build complains. Each category is listed in the pull request with the components it touched. ### How is correctness proven beyond the build? Every migrated screen is loaded in the sandbox's browser and screenshotted, with the console read for warnings. The build passing is a precondition, not the claim; the screenshots and clean consoles on compose, timeline, discover and profile are the claim. ### What if a dependency has no Vue 3 version? It is named in the pull request under what is left, with the agent's assessment of the replacement. The migration build can keep a Vue 2-only leaf working for a while, but anything left on compat is a known debt, not a silent one. ### Does the PHP side change? Only at the seams: the Blade files move from mix() to @vite as entries move to Vite, and the composer build script keeps its npm run production name. pint and Pest pass before the pull request opens, since Blade breakage fails server-side, not in the browser.