Ir al contenido

El medio de los artesanos de la web viernes, 2 de octubre de 2026

MailStudio
Front-end

SvelteKit 3.0 llega a versión estable

SvelteKit 3.0 dejó el estado de release candidate el 1 de octubre de 2026, confirmando los cambios de ruptura anunciados desde el verano: Node 22.17, TypeScript 6 y Vite 8 pasan a ser obligatorios, y el alias $lib desaparece en favor de…

SvelteKit 3.0 está disponible en el registro de npm desde el 1 de octubre de 2026, tras varias semanas como release candidate seguidas en mail-studio.com. La versión estable confirma todos los cambios de ruptura anunciados durante la fase de pruebas: nuevos requisitos de entorno, reorganización de los módulos internos y retirada de varias API históricas. Para los equipos que aún mantenían un proyecto en SvelteKit 2, la ventana de migración queda abierta de forma definitiva.

Una versión que cierra el ciclo de la release candidate

La release candidate cubierta a finales de agosto ya anticipaba lo esencial: la configuración pasa a Vite, el alias $lib es sustituido y el nivel técnico mínimo sube. La versión estable no cambia esa trayectoria, la confirma. No se prevé ningún periodo de gracia adicional para las API retiradas.

Los requisitos que cambian

El nivel técnico mínimo sube en varios frentes a la vez, lo que obliga a revisar toda la cadena de herramientas antes de lanzar una migración.

RequisitoSvelteKit 2.xSvelteKit 3.0
Node.js18.13 o superior22.17 o superior
TypeScript5.x6.0 o superior
Vite5.x o 6.x8.0.12 o superior
Svelte4.x o 5.x5.56.4 o superior
Archivo de configuraciónsvelte.config.jsvite.config.ts

El salto a TypeScript 6 se suma a una tendencia más amplia del ecosistema JavaScript, donde los frameworks dejan de garantizar la compatibilidad con versiones de TypeScript de más de un año.

Importaciones que hay que corregir en el código existente

El módulo $app/stores se retira por completo, en favor de $app/state, basado en los runes de Svelte 5. El alias $lib, presente en prácticamente todos los proyectos SvelteKit, se sustituye por la exportación de subruta #lib.

- import { page } from '$app/stores';
+ import { page } from '$app/state';

- import Button from '$lib/components/Button.svelte';
+ import Button from '#lib/components/Button.svelte';

Una herramienta de migración para absorber lo esencial

El equipo de Svelte ofrece un comando de migración automatizado, capaz de tratar la mayoría de los cambios mecánicos (importaciones, configuración, opciones renombradas) sin intervención manual completa en cada archivo.

npx sv@next migrate sveltekit-3 --tasks all --confirm

El resultado sigue requiriendo revisión: los cambios de comportamiento, como el valor por defecto de la ruta de las cookies ahora fijado en / o la fusión de las opciones noScroll y keepFocus en un único parámetro reset, no siempre se detectan con un simple reemplazo de texto.

SvelteKit 3.0 cierra un ciclo de release candidate iniciado a finales del verano, sin ninguna etapa de transición adicional para los proyectos que aún dependían de $app/stores.

Los proyectos que siguen en Node 20 LTS deben planificar una actualización del runtime antes de intentar la migración: SvelteKit 3.0 se niega a arrancar bajo Node 22.17. Los pipelines de integración continua fijados en una imagen de Node antigua son el error más citado por las primeras migraciones.

Lo que hay que recordar

SvelteKit 3.0 formaliza una modernización ya anunciada: configuración centrada en Vite, importaciones reorganizadas y un nivel técnico alineado con las versiones recientes de Node, TypeScript y Vite. El comando sv migrate se encarga de la mayor parte del trabajo mecánico, pero sigue siendo necesaria una revisión manual de los cambios de comportamiento, en particular en torno a la navegación y las cookies.

El traslado de la configuración a vite.config.ts me parece el cambio más estructural, más incluso que la retirada de $app/stores, cuya migración es casi mecánica. Confirma que SvelteKit ya no tiene un sistema de configuración propio y depende por completo del de Vite, una decisión coherente con el resto del ecosistema, pero que conviene anticipar en los monorepos grandes donde ya conviven varios plugins de Vite. En los proyectos que ya se gestionan desde la línea de comandos, conviene probar la migración en una rama dedicada antes de lanzarla sobre el repositorio principal. — Simon Janvier

Para saber más: notas de versión completas de SvelteKit en GitHub.

Compartir LinkedIn Bluesky Hacker News E-mail

Leer también