Vite y los orígenes cruzados

 ¿Vite introduce complejidad en todo este tema de los orígenes con la validación de sanctum?

Sí, Vite puede introducir cierta complejidad en este tema, principalmente debido a cómo maneja el entorno de desarrollo local y la seguridad de origen cruzado (CORS).

---

El problema en el desarrollo local

Cuando estás trabajando en tu máquina, tu aplicación Laravel puede estar ejecutándose en un dominio (por ejemplo, http://localhost:8000), mientras que el servidor de desarrollo de Vite se ejecuta en otro (por ejemplo, http://localhost:5173).

El navegador ve esto como dos orígenes diferentes, y por defecto, las peticiones que se hacen entre ellos están prohibidas por la política de mismo origen (Same-Origin Policy).

Cuando tu frontend, servido por Vite, intenta hacer una petición a la API de Laravel (por ejemplo, http://localhost:8000/api/user), el navegador lo bloquea, mostrando un error de CORS. Esto es un problema común al usar una SPA (como la que simulas con Inertia/React) que se comunica con un backend separado.

La solución de Sanctum y Vite

Afortunadamente, Laravel y Vite están diseñados para trabajar juntos y ya tienen una solución para esto. La clave es decirle a Laravel que confíe en el origen de Vite durante el desarrollo.

1. Configuración de Sanctum: En tu archivo de configuración de Laravel config/sanctum.php, hay una opción llamada stateful. Debes asegurarte de que tu URL de desarrollo de Vite esté en esta lista.

   PHP

   'stateful' => explode(',', env('SANCTUM_STATEFUL_DOMAINS', 'localhost,127.0.0.1')),
   

   El starter kit de Laravel ya hace esto automáticamente, tomando el dominio de tu variable de entorno SANCTUM_STATEFUL_DOMAINS en el archivo .env. Por lo general, esto es localhost:3000 o localhost:5173.

2. Configuración del archivo .env: Tu archivo .env debe incluir la URL de tu frontend.

   Code snippet

   SANCTUM_STATEFUL_DOMAINS=localhost:5173,127.0.0.1:5173
   

3. Configuración del proxy de Vite: Otra forma de manejarlo, especialmente si tienes problemas, es usar el proxy de Vite. Puedes configurar tu vite.config.js para que todas las peticiones a una URL de la API se redirijan a tu servidor de Laravel.

   JavaScript

   // vite.config.js
   import { defineConfig } from 'vite';
   import laravel from 'laravel-vite-plugin';
   import react from '@vitejs/plugin-react';
   
   export default defineConfig({
       plugins: [
           laravel({
               input: 'resources/js/app.jsx',
               refresh: true,
           }),
           react(),
       ],
       // Configuración del proxy para evitar errores CORS en desarrollo
       server: {
           proxy: {
               '/api': 'http://localhost:8000', // Redirige /api a tu backend de Laravel
               '/sanctum/csrf-cookie': 'http://localhost:8000', // También la ruta de Sanctum
           }
       }
   });
   

   Sin embargo, el starter kit de Inertia.js con Laravel no requiere esta configuración de proxy, ya que se encarga de la comunicación entre el frontend y el backend de forma nativa a través de las rutas web, no de la API. La complejidad de Vite surge cuando quieres que la API de tu aplicación sea independiente de tu frontend, por ejemplo, si desarrollas una aplicación móvil a la par.

---

Conclusión

Vite no introduce complejidad si utilizas el starter kit de Laravel e Inertia, ya que la configuración inicial está diseñada para manejar estos problemas de origen de forma transparente.

La complejidad solo se presenta si intentas configurar un proyecto desde cero sin el starter kit, o si tienes una configuración de servidor no estándar (como Docker, Valet o Nginx) donde los dominios no coinciden. En esos casos, es posible que tengas que ajustar manualmente los archivos de configuración de Sanctum o Vite para evitar los errores de CORS.

---

¿Cuál es la técnica de Vite para cambiar el servidor de desarrollo de Laravel por su propio servidor de desarrollo?

Es una excelente pregunta que va al corazón de cómo funciona el desarrollo moderno con Laravel y herramientas como Vite. La técnica que utiliza Vite para "reemplazar" el servidor de desarrollo de Laravel es a través de su servidor de desarrollo integrado (Vite Dev Server) y el uso de puntos de entrada (entrypoints).

---

El Servidor de Desarrollo de Vite

En un entorno de desarrollo tradicional con Laravel, el servidor web (como Apache, Nginx o el servidor integrado de PHP con php artisan serve) se encarga de servir tanto tus páginas web como tus activos (archivos CSS y JavaScript).

Cuando introduces Vite, la dinámica cambia. Vite lanza su propio servidor de desarrollo (npm run dev). Este servidor está especializado en una cosa: servir los archivos de tu frontend (React, Vue, JavaScript, CSS, etc.) de una manera extremadamente rápida, con características como la Recarga en Caliente de Módulos (HMR - Hot Module Replacement).

La magia sucede porque tu navegador se comunica con dos servidores al mismo tiempo:

1. El servidor de Laravel (http://localhost:8000), que sigue sirviendo las vistas de Blade (o Inertia).

2. El servidor de Vite (http://localhost:5173), que sirve tus activos de frontend.

---

La Conexión Mágica: El @vite y el Manifest

La forma en que Laravel sabe de la existencia de este segundo servidor es a través de una directiva de Blade llamada @vite.

Cuando estás en modo de desarrollo (APP_ENV=local), la directiva @vite hace dos cosas:

• Genera una etiqueta <script> que carga tu punto de entrada principal desde el servidor de desarrollo de Vite (por ejemplo, http://localhost:5173/resources/js/app.jsx).

• Inyecta un pequeño fragmento de JavaScript en tu página que establece una conexión WebSocket con el servidor de Vite. Esto es lo que permite a Vite saber cuándo has cambiado un archivo para recargarlo instantáneamente en el navegador, sin necesidad de refrescar la página completa.

Cuando pasas a producción (npm run build), el proceso es diferente. Vite compila todos tus activos en archivos estáticos (app.js, app.css, etc.) con nombres únicos y hash. También crea un archivo llamado manifest (manifest.json). El archivo manifest es un mapa que le dice a Laravel qué archivo compilado corresponde a cada uno de tus puntos de entrada originales.

En este modo, la directiva @vite en tu vista ya no apunta al servidor de desarrollo, sino que lee el manifest para generar los enlaces correctos a los archivos estáticos y versionados, asegurando que tus usuarios siempre obtengan la última versión del código.

---

En resumen, la técnica de Vite no es tanto "cambiar" el servidor de desarrollo de Laravel, sino coexistir con él. Laravel sigue siendo el "cerebro" que maneja la lógica de la aplicación, las rutas y las vistas, mientras que Vite se convierte en un "brazo" especializado y ultrarrápido que se encarga exclusivamente de compilar y servir los activos del frontend durante el desarrollo.