# Bless Convierte un proyecto SvelteKit existente y sin modificar en un proyecto VelaStack — el equivalente de [`vela create`](/es/docs/create) para un repositorio que ya existe. Hay dos caminos hacia un proyecto existente. `vela bless` es la conversión completa: Tailwind, shadcn-svelte y su `components.json`, el layout y las rutas de Vela, y el backend de PocketBase. [`vela enable backend`](/es/docs/enable/backend) añade solo PocketBase y la infraestructura de tests de servidor, y deja todo lo demás tal cual. Buena parte de Vela no necesita ninguno de los dos; consulta *Sin bendecir* más abajo. ### Sintaxis ``` $ vela bless [path] ``` ``` $ vela bless # el proyecto en el directorio actual $ vela bless ./my-app ``` Se te pedirá el correo electrónico y la contraseña del administrador para la nueva base de datos PocketBase. Bendecir un proyecto que ya ha sido bendecido se rechaza. El proyecto tiene que estar en SvelteKit 3. Un proyecto de SvelteKit 2, uno que declara `@sveltejs/kit` 2 o que todavía tiene un `svelte.config.js`, se rechaza con el comando que lo actualiza: [`vela migrate sveltekit-3`](/es/docs/migrate/sveltekit-3). ### Opciones - `--template ` - Plantilla desde la que generar, por defecto `minimal`. Solo se pueden usar plantillas con backend — bendecir es lo que añade PocketBase a un proyecto. - `--email ` - Correo electrónico del usuario administrador - `--password ` - Contraseña del usuario administrador, de al menos 8 caracteres - `--install ` - Instala las dependencias con el gestor de paquetes indicado, o `--no-install` para omitirlo - `--skip-routes` - Conserva `src/routes` aunque parezca intacto - `--force-routes` - Reemplaza `src/routes` con la plantilla de Vela sin detección `--skip-routes` y `--force-routes` son mutuamente excluyentes. ### Qué añade Los archivos que Vela posee por completo se escriben directamente. Si tu proyecto ya tiene uno, se conserva y se te indica qué habría contenido la copia de Vela: ``` src/hooks.server.ts el hook handlePocketbase src/lib/server/workflows.ts el cliente de workflows y el worker que inicia hooks.server.ts src/app.css importaciones de Tailwind y tokens del tema src/lib/utils.ts el helper cn y utilidades de tipos de componentes src/lib/index.ts el marcador de posición al que resuelve #lib src/lib/site.ts el nombre de la aplicación, tomado de package.json, y su URL components.json la configuración de shadcn-svelte que lee `vela ui add` .npmrc engine-strict=true .ignore exclusiones de búsqueda para archivos generados vitest.config.ts el proyecto de tests de servidor que ejecuta `vela test:server` ``` Los directorios se añaden junto a los que ya tienes: `src/lib/components`, `src/lib/workflows`, `data`, `test` y `static`. La configuración se fusiona en lugar de sobrescribirse: ``` vite.config.ts tsconfig.json package.json src/env.ts .gitignore src/app.d.ts ``` Las opciones del compilador de Svelte van a la llamada a `sveltekit()` de `vite.config.ts`, donde SvelteKit 3 lee su configuración. `package.json` recibe las importaciones `#lib`, y `src/env.ts` declara las variables que lee Vela, como `POCKETBASE_URL`. El adaptador de SvelteKit de tu proyecto se conserva: si `package.json` ya incluye uno, no se añade el `@sveltejs/adapter-node` de la plantilla. `.gitignore` solo recibe las entradas que le faltan, entre ellas `/data/*` para la base de datos local (sin dejar de versionar `data/fixtures`, `data/seeds` y `data/hooks`) y `/backups`. ### Rutas Vela examina `src/routes` para decidir si sigue siendo el marcador de posición intacto de `npx sv create`. Si lo es, se reemplaza con las rutas de la plantilla; si has escrito algo real, se deja tal cual. Anula la detección en cualquier sentido con `--skip-routes` o `--force-routes`. ### Sin bendecir Esto funciona en un proyecto recién salido de `npx sv create`, sin ninguna preparación: - [`vela generate schema`](/es/docs/generate/schema) y [`vela generate form`](/es/docs/generate/form). Sin shadcn-svelte el formulario se escribe en HTML plano. - [`vela enable`](/es/docs/enable) para `i18n`, `ai`, `analytics`, `content-negotiation` y `cms` - [`vela legal privacy`](/es/docs/legal/privacy) y [`vela legal terms`](/es/docs/legal/terms), [`vela routes`](/es/docs/routes) y [`vela i18n`](/es/docs/i18n) - [`vela deploy`](/es/docs/deploy) y los comandos de servidor: `env`, `status`, `logs` y `rollback` Las rutas generadas van directamente bajo `src/routes` en un proyecto sin los grupos `(public)` y `(app)` de Vela. Estos escriben marcado de shadcn-svelte o manejan shadcn-svelte directamente, así que necesitan un `components.json` y el paquete shadcn-svelte: - [`vela ui`](/es/docs/ui) - [`vela enable blog`](/es/docs/enable/blog) - [`vela enable auth`](/es/docs/enable/auth) y lo que se construye sobre él: `api-keys`, `notifications`, `teams`, `payments` y `subscriptions` - [`vela generate scaffold --remote`](/es/docs/generate/scaffold) En un proyecto que no los tiene se niegan antes de cambiar nada, e imprimen los dos comandos que lo preparan: ``` $ npx sv add tailwindcss $ npx shadcn-svelte@latest init ``` Los comandos que necesitan una base de datos lo dicen del mismo modo, y remiten a [`vela enable backend`](/es/docs/enable/backend). Una vez ejecutado, [`vela generate scaffold`](/es/docs/generate/scaffold) también funciona sin shadcn-svelte, con sus páginas en HTML plano.