laravel-vite-plugin is the thin Vite configuration Laravel applications build on

A Vite plugin whose job is to know about Laravel

Vite is a modern frontend build tool that provides a fast development environment and bundles code for production. The Laravel Vite plugin exists to configure Vite for use with a Laravel backend server, and that sentence is the whole product description.

That is a smaller job than it sounds, and it is worth being precise about what the package is not. It is not a Laravel application, a Laravel package in the Composer sense, or a set of Blade directives. It is a JavaScript package, published to npm as laravel-vite-plugin, that a Laravel project's vite.config file imports and registers.

The audience is therefore the Laravel developer who has decided to use Vite for the frontend and wants the integration to behave the way the framework expects, rather than assembling the pieces by hand. The value is in the defaults that Laravel requires: the dev server address and port that the backend has to reach, the hot file mechanism, the way Laravel's own Vite helper resolves the manifest, and the small helpers for fonts and for Inertia.

The README is deliberately short, and it says so. Documentation for the plugin is on the Laravel website at the vite documentation page, the contribution guide is in the Laravel documentation, and the code of conduct is the Laravel one. The repository README itself carries the introduction, the documentation link, the contribution note, the security policy link, and the licence. Everything else lives outside the repository, which is a deliberate choice for a package that ships in lockstep with the framework.

Three published entry points, not one

The package manifest is where the real shape of the plugin appears, and it publishes three separate entry points rather than one.

The main entry point is the plugin itself, with types at ./dist/index.d.ts and the implementation at ./dist/index.js. The second is the Inertia helpers, and the third is the fonts helper:

        "./inertia-helpers": {
            "types": "./inertia-helpers/index.d.ts",
            "default": "./inertia-helpers/index.js"
        },
        "./fonts": {
            "types": "./dist/fonts/index.d.ts",
            "default": "./dist/fonts/index.js"
        }

The published file list matches those entry points, with /dist and /inertia-helpers as the two directories that ship. The Inertia helpers are built separately, and they live in their own directory rather than inside dist, which is why the type declaration path is different from the fonts one.

The package is an ES module, with type set to module and an exports map rather than a single main field for the secondary paths. The author field reads Laravel and the licence is MIT.

The reason for the split is practical rather than cosmetic. The fonts helper is a client side module that deals with font files and it needs to end up in the browser bundle, while the Inertia helpers are used on the server side or in the Inertia specific build path, and the plugin itself runs in the Node process that runs Vite. Keeping them in separate entry points keeps each of them out of the others' dependency graph.

There is also a command in the package, defined in the bin field, which is the only executable the package ships.

The build runs three compilers for three targets

The build script shows exactly how the three targets are produced:

        "build": "npm run build-plugin && npm run build-fonts && npm run build-inertia-helpers",

The plugin itself is bundled with esbuild, targeting Node and emitting an ES module, with a set of externals that includes vite, vite-plugin-full-reload, picocolors, tinyglobby and fontaine. Those externals are the interesting part, because they are the things the plugin expects to find in the consuming project rather than shipping itself. fontaine in particular is the font processing library, and the fact that it is external explains why the fonts helper is a separate build target rather than part of the plugin bundle.

        "build-plugin-esm": "esbuild src/index.ts --bundle --platform=node --format=esm --outfile=dist/index.js --external:vite --external:vite-plugin-full-reload --external:picocolors --external:tinyglobby --external:fontaine",

The fonts helper is a second esbuild invocation with its own entry point, src/fonts/index.ts, writing to dist/fonts/index.js. The Inertia helpers are compiled with tsc against a dedicated tsconfig.inertia-helpers.json, and the directory is removed first so a stale build cannot survive.

Type declarations for the plugin come from a separate tsc invocation with --emitDeclarationOnly, and the plugin build also copies src/dev-server-index.html into dist/, which is the page Vite serves for the development server.

So there are three toolchain paths in one package: esbuild for the two browser and Node bundles, and tsc for the type definitions and for the Inertia helpers. A contributor reading the scripts learns the layout of the project quickly, because the build script is a map of it.

clean-orphaned-assets is the one command the package installs

The bin field of the manifest contains a single entry:

    "bin": {
        "clean-orphaned-assets": "bin/clean.js"
    },

So installing the package puts one executable on your path, and it is not a build tool. It cleans up assets, which is the kind of command that matters more than it sounds in a Vite based project, where every build writes hashed files into the public directory and the old hashed files stay behind.

The mechanism is the usual Vite one. A production build emits assets with a content hash in the file name, and the Laravel side of the integration reads the manifest to find out which hashed file corresponds to which logical asset. When a file is renamed because its content changed, the previous file is no longer referenced but is still on disk, and the directory keeps growing. A command that removes those orphans is a small convenience, and it is the kind of thing the framework team would rather provide than have every application write for itself.

The repository has a bin/ directory at the root, and the build-plugin script copies a file into dist, so the command is compiled along with the rest of the package rather than being a loose script that only works from a checkout.

Worth noting for anyone evaluating: the package ships no other executables. There is no init command, no scaffold, no configuration generator. The integration with a Laravel application is done by importing the plugin in a vite.config file and by whatever the Laravel documentation tells you to add on the PHP side.

Versioning, branches and the upgrade path

The default branch is 3.x, which tells you the current major line and that earlier majors are still around. The recent releases are v3.2.0 on 2026-08-11, v3.1.3 on 2026-07-13 and v3.1.2 on 2026-07-13, and the last push was on 2026-10-14.

The pattern in the patch releases is a little unusual and worth noting. v3.1.2 and v3.1.3 were published about a minute apart, which usually means a packaging or publishing fix rather than a code change, and then the minor moved to 3.2.0 a month later. Whatever the cause, it means the version number alone is a weak signal about what changed, which is exactly why the repository keeps a CHANGELOG.md.

The repository root is arranged for that. There is CHANGELOG.md for the history, UPGRADE.md for the notes you need before moving between major versions, and RELEASE.md, which presumably describes how releases are cut. A release.sh script sits alongside them, and the presence of a separate release document is a good sign that the process is written down rather than living in one maintainer's head.

There is also a tsconfig.inertia-helpers.json next to the main tsconfig.json, which confirms that the Inertia helpers are compiled as their own project with their own compiler settings, and that the two are expected to evolve independently.

For a team running this in production, the practical takeaway is that the package follows the framework's own cadence, and the upgrade notes in UPGRADE.md are the place to look before moving an application onto a new major line.

MIT, and the conventions the repository enforces

The licence is MIT, and the README states that the plugin is open sourced software licensed under the MIT license, with the text in LICENSE.md at the repository root. For a package that is distributed as part of the framework toolchain, permissive licensing keeps it usable in closed source applications without friction, and there is no copyleft obligation to reason about when you vendor it into a build.

The repository is small and tidy. There is an .editorconfig for whitespace rules, a .styleci.yml for the PHP style checker even though the source is TypeScript, an eslint.config.cjs for the JavaScript linting, a .gitattributes file, and a .github/ directory for the workflows, with a build status badge for the tests workflow in the README.

The src/ and tests/ directories hold the implementation and the test suite, and the whole thing is written in TypeScript with the type declarations emitted by tsc as described earlier.

One last practical note about how this project documents itself. The security policy is a repository link rather than a paragraph, and the contribution guide is on the Laravel documentation site. Everything a new contributor needs is reachable, but none of it is in the repository. For a package this small that is a sensible division of labour, since the documentation has to be correct for every Laravel version at once, and the framework documentation site is the only place that can do that. The cost is that you cannot answer a question about this package from the repository alone, and you have to be online with the Laravel documentation open.

Editorial conclusion

Adopt laravel-vite-plugin if you are running a Laravel application and want Vite configured the way the framework expects, with the dev server, the hot file, the font handling and the Inertia helpers already wired up, and if you are willing to read the Laravel documentation for the configuration side. Do not adopt it if you are not using Laravel, since the package exists to serve a Laravel backend, and do not expect it to configure more than the frontend build. Before you upgrade a project onto the 3.x line, read UPGRADE.md and the CHANGELOG.md, confirm the version of Vite your application expects, and check the fonts and inertia-helpers entry points, since the package publishes them separately from the main plugin and they are the parts most likely to need attention after a major upgrade.

Frequently asked questions

Official sources

1. Issues
2. laravel/vite-plugin on GitHub
3. License: MIT
4. README
5. Releases