Laravel's official React, Vue, Svelte and Livewire starter kits now use Vite+. For new projects, that means one frontend command line and less setup to assemble. For established applications, it is a tooling decision that should preserve the checks, rules and release behaviour the team already trusts.
01
A new starter kit is not a maintenance instruction
Imagine an operations portal built with Laravel, Vue and Inertia. The application began from Laravel's Vue starter kit, then accumulated its own components, tests, CI workflow, ESLint rules and Prettier configuration. Several developers know the current commands. Deployments are repeatable and the production build is stable.
A developer creates a fresh Laravel project for a small experiment and notices that its package.json looks different. The development and build scripts use vp instead of calling Vite directly. Separate lint and format scripts have become vp check. The old ESLint and Prettier files are gone.
Nothing has broken in the established portal. Laravel still describes starter kits as optional, and the code generated from one belongs to the application. The new default tells the team where Laravel sees frontend tooling heading. It does not turn yesterday's supported Vite setup into an emergency.
02
What changed in the official Laravel starter kits
On 28 August 2026, Laravel's official starter-kit repositories were updated to Vite+. The React, Vue, Svelte and Livewire variants now run their development and production builds through the vp command.
In the Inertia kits, separate linting and formatting commands were consolidated. The current Vue starter kit, for example, includes vp dev, vp build, vp check and vp check --fix. It also keeps a dedicated vue-tsc --noEmit command for Vue-specific type checking.
Linting and formatting rules now sit inside vite.config.ts. The starter kits use Oxlint and Oxfmt through Vite+ instead of carrying ESLint, Prettier and the collection of plugins that supported them. Tailwind class sorting, ignored generated files, formatting preferences and the policy that warnings fail checks are still explicit, but they are expressed in one configuration surface.
The starter kits currently pin vite-plus at version 0.3.0. That matters because Vite+ was released in beta on 2 July 2026. Laravel has adopted it as a default for generated applications while the wider tool is still moving towards its 1.0 release.
03
Vite+ is more than a new name for Vite
Vite remains the development and build foundation, but Vite+ wraps a broader collection of tools behind one command line.
It brings together Vite and Rolldown for development and builds, Vitest for tests, Oxlint for linting, Oxfmt for formatting, tsdown for packaging libraries and Vite Task for running and caching tasks. It can also manage the Node runtime and use the package manager declared by a project, whether that is npm, pnpm, Yarn or Bun.
The attraction is consistency. A developer can use vp install, vp dev, vp check, vp test and vp build across projects instead of learning a slightly different combination of scripts and configuration files in every repository. CI can use the same commands as a local machine.
That consolidation may reduce setup and maintenance work. It also means a team is choosing an integrated toolchain rather than several tools independently. Fewer configuration files does not mean there are fewer decisions. It means those decisions have moved.
04
What the new Vite+ commands actually do
| Command | Purpose | What a Laravel team should verify |
|---|---|---|
| vp install | Install dependencies through the project's chosen package manager | Lockfile behaviour and the Node and package-manager versions used locally and in CI |
| vp dev | Run the Vite development server and hot module replacement | Laravel plugin behaviour, generated routes and frontend framework plugins |
| vp check | Format, lint and type check in one validation loop | Existing lint rules, ignored files, generated code and framework-specific type checks |
| vp check --fix | Apply safe formatting and lint fixes where possible | The size of the first formatting diff and whether generated or vendor code is excluded |
| vp test | Run tests through Vitest | Existing Vitest configuration, browser providers, coverage and test imports |
| vp build | Create the production frontend build | SSR builds, environment variables, output paths and deployment commands |
The command surface is deliberately short. The migration work is in proving that the behaviour behind those commands still matches the application.
05
Existing Vite applications can stay where they are
An application does not inherit new starter-kit files after it has been created. Existing Vite, ESLint and Prettier dependencies continue to work according to the versions in the repository and lockfile.
That is the safest default for a mature application with no tooling problem. There is no commercial value in changing a stable build because a fresh starter kit now looks different. A toolchain migration competes with product work, defect fixes, security updates and customer commitments. It needs a reason.
Good reasons may include slow or unreliable checks, repeated configuration across several Laravel applications, difficult developer setup, inconsistent local and CI commands, or a planned upgrade where the frontend tooling already needs attention.
Curiosity is a good reason to create a trial branch. It is not, by itself, a reason to replace the production toolchain.
06
The beta label deserves a calm response
VoidZero describes Vite+ as stable but not yet complete. Its beta announcement recommends adoption where the current features cover the team's needs and notes that compatibility, migrations and diagnostics will continue to improve before 1.0.
That does not make it unsuitable. Laravel has chosen it for official starter kits, its components are established open-source projects, and the integration is being developed in public. It does change the burden of proof for an established system.
A new internal tool can accept more movement in its build setup. A regulated customer portal with a carefully controlled release process may prefer to wait, or adopt only after a representative branch has passed every check. Risk is not a judgement on the quality of the tool. It is the consequence of the application, team and timing.
07
Do not let migration erase rules the team relies on
Vite+ provides vp migrate to move an existing Vite project. Its migration guide says the command updates dependencies, rewrites imports, merges tool configuration into vite.config.ts, updates scripts and formats the project. The same guide says most projects will need manual adjustments afterwards.
Before running it, inventory the current setup. Record custom ESLint rules, Prettier plugins, ignored files, import ordering, Tailwind formatting, TypeScript checks, Vitest environments, browser-test providers, Git hooks and CI commands. Some of those settings are preferences. Others prevent real defects or stop generated code creating noise.
Run the migration only on a branch with a clean working tree. Review the dependency and configuration diff before accepting the formatting changes. A large automated rewrite can hide an important change if it is mixed with application work.
Vite+ recommends upgrading to Vite 8 or later and Vitest 4.1 or later before migrating. After migration, run vp install, vp check, vp test and vp build. For a Laravel application, also run the PHP test suite and exercise the actual browser journeys that use built assets, Wayfinder routes, Inertia pages or Livewire behaviour.
08
CI is part of the migration, not an afterthought
A local build proves one machine can use the new setup. It does not prove the team can release it.
Vite+ provides setup-vp integrations for GitHub Actions and GitLab CI. The GitHub Action can install Vite+, set up Node and the chosen package manager, and cache package-manager data. Its documentation recommends pinning the action to an exact release or commit rather than relying on a floating major tag.
Compare the old and new pipeline outputs. Confirm that the same checks run on pull requests, production builds use the expected environment, caches do not hide missing dependencies and failed warnings still stop the pipeline. If the application uses SSR, confirm both browser and SSR bundles are created.
The best outcome is boring: a developer runs the same short commands locally and in CI, and both environments agree. If the migration merely moves complexity into a less familiar place, it has not yet earned its keep.
09
Choose adoption according to the application
| Situation | Sensible next step |
|---|---|
| A fresh Laravel starter-kit application | Use the generated Vite+ setup, keep the pinned version and learn the defaults before customising it |
| A small existing app with standard Vite, ESLint and Prettier | Trial vp migrate on a branch and compare checks, tests and builds before deciding |
| A mature app with custom rules, plugins, browser tests or unusual CI | Inventory every rule first, run a controlled migration and expect manual work |
| A stable app with no frontend tooling problem | Keep the current setup and revisit Vite+ when there is a clear benefit or planned tooling upgrade |
| Several Laravel apps with inconsistent frontend workflows | Use one representative project to test whether Vite+ can become a maintainable shared standard |
The table is not a timetable. Vite+ may mature quickly, and Laravel's starter kits will continue to change. Record why the team adopted, trialled or deferred it, then review that decision when the facts change.
10
The useful change is a shorter feedback loop
The most important part of this announcement is not that Laravel changed a package. It is that the framework is backing a more integrated frontend workflow.
For new applications, that can mean less time assembling linting, formatting, testing and build tools before useful work begins. For teams maintaining several Laravel projects, it may offer a common set of commands and fewer versions to align.
For an established application, the responsible response is smaller. Understand what changed, preserve the current rules, test the migration away from production and adopt it only when the team can explain the improvement.
Starter kits are there to remove repetitive setup. They should not create repetitive upgrade work.
If you are planning a Laravel and Vue application or reviewing an established frontend toolchain, I can help compare the current setup with the new starter-kit defaults, identify migration risks and leave the team with a build and release process it can support.
Useful questions
Before moving an existing Laravel app to Vite+, check:
- What problem would the migration solve for the team?
- Which lint, format and TypeScript rules protect the application today?
- Are generated routes, UI components and vendor files excluded correctly?
- Does the project already use Vite 8 or later and Vitest 4.1 or later?
- Can the migration be reviewed separately from product changes?
- Do the PHP, frontend and browser test suites still pass?
- Does the normal production build, including SSR where used, still work?
- Will local development and CI run the same commands and versions?
- Have Git hooks and pull-request checks been preserved?
- Can the team explain why adopting now is better than waiting?
