Skip to content
Back to blog
LaravelDevOpsBuenas prácticas

Laravel starter kits simplify frontend tooling with Vite+

Vite+ brings development, builds, formatting, linting, and type checks into one configuration and a simpler command flow.

Ismael Catala5 min read

Fewer moving parts in every project

When I start a Laravel project with Inertia, frontend tooling usually ends up in the same place: package.json scripts, ESLint rules, Prettier settings, and TypeScript checks. None of those tools is a problem on its own, but together they bring extra files, dependencies, and maintenance decisions. Laravel starter kits now use Vite+ to put that frontend workflow behind the vp command. (laravel-news.com)

The change matters most for the React, Vue, and Svelte kits, where the frontend is part of the application skeleton from the first commit. Instead of remembering separate commands for serving, building, and validating an app, the team gets a smaller command surface. A new project still needs technical decisions, but it needs less tooling assembly work.

One command for routine checks

The most useful piece is vp check. The official documentation says it runs formatting, linting, and type checking together, while vp check --fix applies fixes where it can. (viteplus.dev)

In a Laravel repository, I would expose it through project scripts so local development and CI use the same command. The script name itself is not important; what matters is that everyone knows what runs before opening a pull request. This is a small, valid setup for that workflow:

{
  "scripts": {
    "dev": "vp dev",
    "build": "vp build",
    "check": "vp check",
    "check:fix": "vp check --fix",
    "test": "vp test"
  }
}

vp dev starts the development server, vp build creates a production build, and vp test runs JavaScript tests. It does not replace Laravel's PHP test suite, of course; those are separate layers and should remain part of the relevant pipeline. (viteplus.dev)

Configuration stays next to Vite

Vite+ uses vite.config.ts as its central configuration file. Standard Vite settings such as server and build can live alongside fmt, lint, and check blocks. (viteplus.dev)

That has a practical advantage: when tooling changes, the relevant configuration is in one predictable place. It also means treating that file as application code rather than copied boilerplate. These formatting and linting options are documented by Vite+:

import { defineConfig } from 'vite-plus';
 
export default defineConfig({
  fmt: {
    ignorePatterns: ['dist/**'],
    singleQuote: true,
    semi: true,
  },
  lint: {
    ignorePatterns: ['dist/**'],
    options: {
      typeAware: true,
      typeCheck: true,
    },
  },
});

Enabling typeAware and typeCheck lets vp lint and vp check use the type-aware path. That should be intentional: type checking is useful, but it also means the tsconfig and generated types must resolve correctly both locally and in CI. (viteplus.dev)

A sensible homelab CI flow

On a self-hosted CI runner, the important thing is not installing a long list of commands. It is running the same sequence every time. Vite+ separates its global CLI, vp, from the local vite-plus package installed in the project. Its documentation provides setup-vp for CI and dependency caching, but pinning tool versions and maintaining the lockfile are still repository responsibilities. (viteplus.dev)

For a Laravel application, the frontend part of the pipeline can be kept deliberately short:

vp install
vp check
vp test
vp build

I would then add whichever PHP checks the project already relies on, including tests, static analysis, or formatting. The point is not reducing quality gates; it is preventing formatting, linting, and type checks from becoming different processes on a laptop and on the homelab runner. (viteplus.dev)

Migration does not mean accepting the diff blindly

Existing projects can use vp migrate, including the non-interactive vp migrate --no-interactive mode. The command updates dependencies, adapts scripts, moves relevant configuration into vite.config.ts, and can rewrite imports where needed. (viteplus.dev)

Still, the official documentation says that most projects will need manual follow-up after migration. Review the current setup before migrating, then run installation, checks, tests, and a build afterwards. In a monorepo, migration must run from the workspace root because shared configuration and lockfiles are affected. (viteplus.dev)

The fine print

Vite+ does not automatically turn every ESLint or Prettier configuration into a perfect equivalent. Oxlint supports many ESLint-compatible rules and JavaScript plugins, but that does not guarantee identical behaviour for a highly customised rule set. If a project depends on critical plugins, legacy configuration, or unusual exceptions, test them before removing anything. (viteplus.dev)

It is also a mistake to present vp check as a replacement for every validation step. It does not cover PHP tests, database migrations, security analysis, or functional checks for an Inertia screen. It simplifies the JavaScript toolchain; it is not a reason to lower the project's engineering standards.

For new starter kits, the move makes sense because it starts from a known baseline and removes initial tooling choices. For established applications, I would treat it as a tooling migration: use a dedicated branch, review the diff, keep CI green, and retain a clear rollback path. That caution is cheaper than learning in production that an important check stopped running.

Keep reading