Sitios Estáticos

Vela puede generar un proyecto solo de frontend, prerenderizado con @sveltejs/adapter-static y listo para desplegar en cualquier alojamiento estático.

Sintaxis

$ vela create my-site --template static

La plantilla estática se distribuye sin directorio data, así que no hay ningún PocketBase que ejecutar. Compílala como cualquier otro proyecto:

$ vela build

El adaptador se configura en vite.config.ts con un fallback 200.html, de modo que el enrutado en el cliente funciona en alojamientos que sirven un único documento de respaldo.

El nombre y la URL del sitio están en src/lib/site.ts. Define ahí url con la dirección donde se servirá el sitio antes de compilar para producción: todas las páginas se prerenderizan, y su enlace canónico y la URL de su imagen Open Graph se construyen a partir de ella.

Desplegar

Sube el directorio build a cualquier alojamiento estático. vela deploy no lo despliega: ejecuta la aplicación como un servidor Node, y se detiene en un proyecto compilado con @sveltejs/adapter-static. Para servir el sitio desde tu propio servidor, cambia el adaptador a @sveltejs/adapter-node. Para eso no hace falta backend.

Convertir un proyecto existente

Un proyecto creado con la plantilla por defecto puede prescindir de su backend, lo que elimina la base de datos, las migraciones y el middleware de PocketBase, y cambia el adaptador a @sveltejs/adapter-static:

$ vela disable backend

vela enable backend lo vuelve a añadir.

Comandos sin backend

Los comandos que necesitan la base de datos se detienen y lo indican, remitiendo a vela enable backend. Un proyecto tiene backend cuando tiene un directorio data y depende de pocketbase-sveltekit o de @velastack/pocketbase. Estos funcionan sin ella:

  • vela dev, vela build y vela preview
  • vela ui, vela legal, vela routes y vela i18n
  • vela generate schema y vela generate form, y vela destroy para ambos
  • vela enable para ai, analytics, backend, blog, cms, content-negotiation e i18n
  • vela disable para ai, analytics, content-negotiation e i18n
  • vela cms, y los comandos de cuenta: signup, login, logout y whoami
  • vela deploy, una vez que el proyecto usa adapter-node, y los comandos de servidor, como provision, env, status y logs

Limitaciones

Las acciones de formulario no están soportadas

Las acciones de formulario necesitan un servidor. Cualquier formulario generado que haga POST a +page.server.ts tiene que sustituirse por un envío desde el cliente a un endpoint externo.

La autenticación de usuarios no está soportada

Las compilaciones estáticas no admiten renderizado dinámico en el servidor, así que el módulo de autenticación y su grupo de rutas protegidas no tienen dónde ejecutarse.

Sin base de datos en tiempo de petición

Los datos pueden leerse en tiempo de compilación e incrustarse en las páginas prerenderizadas, pero no hay base de datos que consultar una vez desplegado el sitio.