Los starter kits de Laravel simplifican el frontend con Vite+Los starter kits de Laravel simplifican el frontend con Vite+

Menos piezas que mantener en cada proyecto

Cuando inicio un proyecto Laravel con Inertia, una parte del trabajo siempre acaba en el mismo sitio: scripts de package.json, reglas de ESLint, configuración de Prettier y comprobaciones de TypeScript. No son herramientas malas, pero juntas añaden ficheros, dependencias y decisiones que hay que mantener. Los starter kits de Laravel pasan ahora a usar Vite+, con una idea sencilla: concentrar ese flujo de frontend bajo el comando vp. (laravel-news.com)

El cambio importa especialmente en los kits con React, Vue o Svelte, donde el frontend ya forma parte del esqueleto del proyecto desde el primer commit. En vez de recordar comandos distintos para servir la aplicación, construirla y validarla, el equipo puede trabajar con una superficie más reducida. Para un proyecto nuevo, eso no elimina las decisiones técnicas, pero sí reduce el trabajo mecánico de ensamblar herramientas.

Un comando para las comprobaciones habituales

La pieza más práctica es vp check. Según la documentación oficial, ejecuta formato, lint y comprobación de tipos en una sola orden, y vp check --fix aplica correcciones cuando puede hacerlo. (viteplus.dev)

En un repositorio Laravel, yo lo dejaría visible en los scripts del proyecto para que el comando local y el de CI sean el mismo. No hay magia en el nombre del script: lo útil es que cualquier persona sepa qué se ejecuta antes de abrir una pull request. Esta es una configuración mínima y válida para ese punto de entrada:

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

vp dev inicia el servidor de desarrollo, vp build genera la compilación de producción y vp test ejecuta las pruebas JavaScript. No sustituye las pruebas PHP de Laravel, por supuesto; son capas distintas y deben seguir ejecutándose en la pipeline que corresponda. (viteplus.dev)

La configuración se queda junto a Vite

Vite+ usa vite.config.ts como punto central de configuración. Ahí pueden convivir los ajustes habituales de Vite, como server y build, con los bloques fmt, lint y check. (viteplus.dev)

Esto tiene una ventaja concreta: al revisar un cambio de tooling, la configuración relevante está en un lugar predecible. También obliga a tratar ese archivo como código de proyecto, no como un detalle que se copia sin leer. Por ejemplo, estas opciones están documentadas para formato y lint:

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

Activar typeAware y typeCheck permite que vp lint y vp check recorran la ruta de análisis con tipos. Conviene hacerlo de forma consciente: comprobar tipos aporta señal, pero también significa que el tsconfig y los tipos generados deben estar bien resueltos en local y en CI. (viteplus.dev)

Un flujo razonable para el homelab

En una instancia de CI autoalojada, lo importante no es que el runner tenga muchos comandos instalados, sino que ejecute siempre la misma secuencia. Vite+ separa su CLI global, vp, del paquete local vite-plus que vive en el proyecto. La documentación ofrece setup-vp para preparar CI y admite caché de dependencias, pero la versión de la herramienta y el lockfile siguen siendo responsabilidad del repositorio. (viteplus.dev)

Para una aplicación Laravel, la parte de frontend puede validarse con una secuencia deliberadamente corta:

vp install
vp check
vp test
vp build

Después añadiría las comprobaciones PHP que ya use el proyecto, como tests, análisis estático o formato. El beneficio no es tener menos calidad, sino evitar que formato, lint y tipos se conviertan en tres pasos divergentes entre el portátil y el runner del homelab. (viteplus.dev)

Migrar no significa aceptar el diff a ciegas

Para proyectos existentes está vp migrate, y también se puede ejecutar sin preguntas con vp migrate --no-interactive. La herramienta actualiza dependencias, adapta scripts, mueve configuración hacia vite.config.ts y puede reescribir importaciones cuando sea necesario. (viteplus.dev)

Aun así, la propia documentación avisa de que la mayoría de proyectos necesitarán ajustes manuales posteriores. Antes de migrar hay que revisar la configuración actual y, después, ejecutar instalación, comprobaciones, tests y build. En un monorepo la migración debe lanzarse desde la raíz del workspace, porque afecta a configuraciones y lockfiles compartidos. (viteplus.dev)

La letra pequeña

Vite+ no convierte automáticamente cualquier configuración de ESLint o Prettier en una equivalencia perfecta. Oxlint ofrece compatibilidad con muchas reglas de ESLint y soporte para plugins JavaScript, pero eso no garantiza que un conjunto de reglas muy específico se comporte igual sin revisión. Si el proyecto depende de plugins críticos, configuraciones heredadas o excepciones poco habituales, hay que probarlas antes de borrar nada. (viteplus.dev)

Tampoco conviene vender vp check como sustituto de todas las validaciones. No cubre las pruebas de PHP, las migraciones de base de datos, el análisis de seguridad ni una revisión funcional de una pantalla Inertia. Es una simplificación del toolchain de JavaScript, no una excusa para reducir la disciplina del proyecto.

Para los nuevos starter kits, el cambio tiene sentido porque parte de una base conocida y reduce el número de decisiones iniciales. Para aplicaciones ya vivas, yo lo trataría como una migración de tooling: rama propia, diff revisado, CI verde y posibilidad de volver atrás. Esa cautela cuesta menos que descubrir en producción que una regla importante dejó de ejecutarse.

• Fuente: Laravel News (laravel-news.com)
• Documentación oficial de Vite+ (viteplus.dev)