Laravel Vite

When to use

• The user needs to compile, bundle, or serve frontend CSS and JavaScript assets in a Laravel 10+ application.
• The user wants live reloading or hot module replacement of assets during local Laravel development.
• The user needs to build minified, versioned (cache-busted) frontend assets for a production Laravel deploy.

When NOT to use

• Do not use this skill when the task is to maintain an existing webpack.mix.js Laravel Mix pipeline that cannot yet migrate; use the laravel/mix skill instead.
• Do not use this skill for API-only or server-rendered work that ships no CSS or JavaScript bundle.

Core guidance

• Run the dev server locally and build for production — Use npm run dev for local work so Vite serves assets with hot module reload; run npm run build in CI or on deploy to emit hashed files plus a manifest.
• Load bundles through the @vite Blade directive — Reference entry points with the @vite([...]) Blade directive rather than hardcoding <script> or <link> tags. Pass the exact entry paths declared in vite.config.js, for example @vite(['resources/css/app.css', 'resources/js/app.js']).

Quick recipe

1. In vite.config.js, register the laravel() plugin with an input array listing resources/css/app.css and resources/js/app.js and set refresh: true. (verify: npm run build emits files under public/build with a manifest.json)
2. In the Blade layout <head>, add @vite(['resources/css/app.css', 'resources/js/app.js']) so both entry points are loaded through the directive. (verify: The rendered page includes the CSS and JS tags Vite generates)
3. Run npm run dev while developing for hot module reload, and run npm run build in the deploy pipeline to produce the versioned production bundle. (verify: Local edits hot-reload; a production deploy serves hashed files with no dev server)

Best practices

• List each CSS and JS entry point in the laravel() plugin input array inside vite.config.js; the @vite directive can only load paths declared there
• Import stylesheets from a JS entry (for example import '../css/app.css' in resources/js/app.js) so Vite processes them, or list the CSS file directly in the plugin input array
• Set refresh: true on the laravel() plugin in vite.config.js so edits to Blade views and routes trigger a full-page reload through the Vite dev server

Anti-patterns

See references/anti-patterns.md.

Common mistakes

1. Stale hot file makes production point at the dev server — A leftover public/hot file makes the @vite directive emit dev-server URLs in production, so assets fail to load. Fix: Delete public/hot on deploy (it is written by npm run dev and removed on shutdown) and add it to .gitignore.
2. Deploying without running the production build — Deploying without npm run build leaves no manifest, so the @vite directive throws a "Vite manifest not found" error. Fix: Add npm ci && npm run build to the deploy pipeline and commit or ship the generated public/build output.
3. Referencing public assets by literal build path — Hardcoding a hashed path like /build/assets/app-4f3a.js breaks on the next build because the hash changes. Fix: Always resolve asset URLs through the @vite directive (or Vite::asset() for static files) so the current manifest hash is used.

Version notes

• Vite is the default bundler from Laravel 9.19+ — Vite ships as the default frontend bundler in Laravel 9.19+ and is the only bundler scaffolded in Laravel 10 and 11.

Security

• Not applicable — no I/O, auth, or untrusted input.

Testing

• Activation and decision behavior are verified in eval/scenarios/laravel/vite.yaml.

Additional resources

• references/anti-patterns.md
• references/core.md
• references/examples.md
• references/pitfalls.md
• references/recipes.md
• references/version-differences.md

Knowledge graph

Supersedes: laravel/mix