Cambios de Meeko

1.9.0 — 2026-11-05#

Credenciales configurables en los clientes API y RPC. ClientOptions.credentials acepta same-origin, include u omit y conserva same-origin por defecto. Permite usar cookies HttpOnly con una API en otro origen desde el navegador sin reemplazar el fetch del cliente. El servidor debe configurar CORS y proteger las mutaciones contra CSRF; esta opción no reenvía automáticamente las cookies de una petición SSR.

1.8.0 — 2026-11-04#

defineModel también como prop y evento. Un componente con defineModel sólo aceptaba una señal escribible, y quien venía de Vue o tenía el valor en un objeto (bind="option.props") no podía pasarlo. Ahora, sin cambiar el hijo, acepta también bind:modelValue con on:update:modelValue, bind:nombre con on:update:nombre y la prop dentro de bind="objeto". Con prop y evento, el padre decide cada escritura y el control vuelve al valor de la prop si no la cambia; con sólo la prop, la escritura se queda en el hijo hasta que la prop cambie; con sólo el evento, se queda en el hijo y además llama al evento. El HTML del servidor sale con el valor de la prop, que no viaja en el estado del hijo. ComponentProps, <Nombre>Props, <Nombre>Emits, meeko check y el editor los conocen, y next tiene el tipo del modelo. model junto a bind:modelValue u on:update:modelValue es MEEK066, y declarar la prop o el evento del modelo en el script es MEEK063.
Un padre con await ya no pierde lo que se escribe. Si el manejador de on:update:modelValue devuelve una promesa, el hijo conserva lo escrito hasta que termine la última escritura, y entonces vuelve a seguir a la prop. El cursor no salta, una escritura anterior que termina después no pisa el valor y un rechazo llega al manejador de errores en lugar de quedar sin capturar. Un manejador síncrono no cambia.
Un modelo obligatorio que falta se explica. meeko check y el editor decían Property '"default"' is missing in type '{}', con un nombre interno. Ahora dicen cómo pasarlo: model="señal" o bind:modelValue="valor", y el código sigue siendo TS2741.
bind="{ … }" en una etiqueta de componente ya no ofrece en el editor las claves on*, que luego daban MEEK113.
MEEK101 ya no avisa de una prop leída en el default de defineModel. defineModel<string>({ default: props.initial ?? "" }) la lee una vez a propósito, como signal(props.initial).
Atrás y adelante devuelven al lector a donde estaba. Al volver de una página corta a una larga, el navegador restauraba el desplazamiento sobre la corta y lo recortaba: de scrollY 100.000 se acababa en 6.226. Ahora cada entrada del historial recuerda su posición, que se aplica junto con el DOM de la página, también dentro de una View Transition, y espera al contenido que aún no ha llegado sin quitarle la página a quien la mueva. Una entrada con fragmento vuelve a su posición, no al ancla. Meeko pone history.scrollRestoration en manual y añade meekoEntry a history.state, donde ya no borra lo que guarde otro código.
Un módulo de componente en un signal o en useState ya no llega al 500 sin aviso. signal([{ component: AppCard }]) pasaba meeko check y fallaba en cada render de servidor, porque el estado se envía al navegador como JSON. Ahora es MEEK136 donde se escribe el valor, en meeko check y en el editor, con la salida: guardar en el estado qué entradas se pintan y leerlas con un computed. Mira el valor inicial, no el tipo de la señal, así que signal<ResolvedComponent<"AppCard"> | undefined>(undefined), que se llena en el navegador, sigue siendo válido. Un componente que nunca se renderiza en el servidor también recibe el error, aunque ahí no fallaría. El error de ejecución nombra también la señal, o la clave de useState, y el camino hasta el módulo.
type X = keyof typeof entries con una constante del setup explica el problema. Daba TS2304 y dejaba detrás un any con errores confusos en la plantilla. Ahora meeko check da MEEK137, una sola vez, con la salida. La compilación no cambia: los tipos se borran, así que sigue funcionando en ejecución.
Un componente genérico en una lista de módulos distintos ya no da un falso MEEK113. Con is="option.component" bind="option.props", una prop como format: (item: number) => string se comparaba con T en unknown. De un genérico en esa lista se comprueban sus nombres y sus props obligatorias.
<component is> con módulos que llegan en los datos y bind. is="option.component" bind="option.props" daba MEEK113: placeholder no es un atributo de la etiqueta, porque el objeto se comprobaba también como atributos de una etiqueta que ese is nunca podía ser; pasaba lo mismo con una prop, un computed o el parámetro de un snippet. Ahora cada clave se comprueba contra lo que is puede ser, una prop de sus componentes o un atributo de sus etiquetas. Con una lista de módulos distintos, cada entrada se comprueba contra su propio componente sin tipos auxiliares: unas props equivocadas dan MEEK113 en bind, con la prop que sobra o falta, en lugar de un TS2345 sobre la intersección de todas. Basta con que is y bind lean el mismo objeto. En ejecución no cambia nada. Véase la lista de <component is>.
TS2367 falso en is="option.kind === 'a' ? 'AppA' : 'AppB'". El código de comprobación repetía la condición de is dentro de su propia rama y TypeScript la comparaba consigo misma. Cada rama sigue estrechando sus props.
MEEK112 explica qué hacer con el nombre de un componente que llega como texto. Con component: "AppSelect" en los datos, el mensaje ofrece el literal en la plantilla, el módulo importado o resolveComponent, en meeko check, en el editor y en el TypeError de ejecución. is sigue sin interpretar nunca un texto, y el error ya no viene acompañado de un TS2345 sobre el objeto de bind. Además, MEEK113 por una clave on* propone el alias AppInputProps si el componente usa ComponentProps<'AppInput'>, que incluye los eventos.
Navegar desde o hacia una página muy larga ya no la congela. Con viewTransitions, una página de más de 4.000 elementos, de origen o de destino, navega sin transición. En una guía de 24.000 elementos con DPR alto o en un móvil, cada frame de la transición bloqueaba la página durante segundos. isTooLargeToAnimate(), nuevo en @meekojs/meeko, es la misma comprobación para quien llame a document.startViewTransition() por su cuenta.
@meekojs/meeko/i18n pide a la vez los catálogos de una página. Cada namespace esperaba al anterior, así que cada uno costaba al visitante una ida y vuelta antes de hidratar. Ahora se piden juntos, también al navegar. No cambian la API ni el orden de fusión. Si falla un catálogo, el error sigue siendo el del primero de la lista que falla, lo anterior se conserva y lo posterior no se fusiona, aunque ya se ha pedido.
Un schema con un import sin resolver ya no se confunde con un schema sin tipos. Con moduleResolution: "NodeNext", un import relativo sin extensión deja el schema en any, y la generación de contratos de API, RPC y Socket pedía «tipos de Standard Schema concretos» sin nombrar la causa. Ahora dice qué import no se resuelve y remite a la ruta y a moduleResolution.
documentHtml: el HTML de una página viaja una vez. Un dato que se pinta con html="..." llegaba dos veces en la primera carga: en el HTML del documento y, más pesado por el escape de JSON, en el payload de hidratación. En la guía más grande de meekojs.com eran 1,8 MiB de 3,3. documentHtml(trustHtml(html)), de @meekojs/meeko/framework, deja en el payload un marcador: la hidratación adopta el contenido sin leerlo ni reescribirlo, una navegación sigue recibiendo el valor, y volver a pintar el elemento lo pide al servidor, nunca al DOM, e inserta sólo lo que esa respuesta declara marcado; si ya no está, carga el documento de nuevo. Hay que marcarlo a propósito, porque en esa primera carga el navegador ve el marcador y no el valor: sólo sirve para lo que nada más lee. Sin la marca nada cambia. Véase documentHtml.
Con cualquier htmlWhitespaceSensitivity, también la de por defecto y en el editor sin configuración de proyecto, formatear un .meeko ya no cambia lo que se renderiza. Partir <li each:of="a" each:as="b">{b}</li> en varias líneas o separar <button>a</button><button>b</button> añadía nodos de texto, también en los bordes de <template>, y Hi<b> you</b> perdía su espacio. Ahora ningún espacio aparece ni desaparece en el límite entre dos nodos, en el plugin del núcleo y en @meekojs/prettier-plugin; sólo puede cambiar de forma, de un espacio a un salto de línea con sangría, que se pinta igual salvo con white-space: pre. El compilador no cambia, así que el HTML de una aplicación tampoco, y un archivo ya formateado conserva sus espacios y casi siempre queda igual. La salida del formato sí cambia en lo que no tenía espacios: los saltos de línea quedan dentro de las etiquetas (>{b}</li\n>). Véase editors.md.
El texto tras el salto de línea inicial de <pre>, <listing> o <textarea> ya no pierde caracteres. El compilador lee el texto de la fuente, y parse5 lo situaba después del primer carácter que producía: <textarea> &x</textarea> se pintaba ;x, y `</p> </li> </ul> ` perdía el `<`. Le ocurría también al código escrito a mano, y al que el formato parte con ese salto. <ul> <li> <p><strong>Formatear un <code>.meeko</code> conserva también los espacios junto a un <code><snippet></code>, el contenido de <code><pre></code> y <code><textarea></code> y un <code>}}</code> en un texto</strong>, en el plugin que usa el servidor de lenguaje, igual que en <code>@meekojs/prettier-plugin</code>. Sus cambios de salida están en <a href="https://github.com/meekojs/meeko/blob/main/packages/prettier-plugin/CHANGELOG.md">el registro de ese paquete</a>.</p> </li> <li> <p><strong>Un <code>meeko dev</code> que arranca ya no recarga las páginas abiertas.</strong> Cada arranque reescribía las entradas de <code>.meeko/generated</code>, aunque no cambiaran, y Vite recargaba toda página abierta en ese proyecto, también las de otro <code>meeko dev</code>: se perdía su estado, como un formulario recién enviado. Ahora sólo se escribe una entrada que falta o que cambió.</p> </li> <li> <p><strong><code>addPublicFile(path, contents, { headers })</code>.</strong> Un módulo no podía dar cabeceras a un archivo público: en <code>meeko dev</code> esos archivos no pasan por la aplicación, y <code>server.headers</code> es de cada web. Ahora el archivo las lleva en <code>meeko dev</code> y en los adaptadores con servidor, también si su nombre necesita codificarse en la URL (<code>font test.woff2</code>, <code>fuente-ñ.woff2</code>). Un patrón de <code>server.headers</code> que alcance esa ruta sustituye sólo las cabeceras que fija, sin distinguir mayúsculas de minúsculas, y conserva el resto; viajan en el nuevo <code>AppManifest.publicFileHeaders</code>. El adaptador <code>static</code> no las escribe.</p> </li> <li> <p><strong><code>useHead</code> en una página de error fija su título.</strong> El título <code>Error</code> entraba como <code>head</code> de la ruta, que gana a todo, así que <code>useHead({ title })</code> en <code>app/error.meeko</code> o <code>+error.meeko</code> no tenía efecto, ni en el SSR ni al navegar: las webs que traducían el título del 404 mostraban <code>Error</code>. Ahora <code>Error</code> es el título por defecto de esas páginas, por encima de sus layouts y por debajo de ellas. El <code>head</code> del payload de una URL sin ruta deja de llevarlo.</p> </li> <li> <p><strong><code>model</code> en un <code><input type="range"></code> con una señal numérica.</strong> Daba <code>TS2322</code>, y un envoltorio con un rango tenía que escribir <code>bind:value</code> y <code>on:input</code>, que no recogen lo que el usuario movió antes de hidratar. Ahora una señal que guarda un número recibe números, y una con texto sigue recibiendo texto. Además, un valor que sólo ha saneado el navegador (un rango que recorta su <code>value</code> a <code>max</code>, un correo sin espacios) ya no cuenta como una edición anterior a la hidratación: la señal conserva lo que le dio la aplicación.</p> </li> <li> <p><strong>Lo que el usuario movió antes de hidratar ya no se pierde en una lista.</strong> Si hidratar volvía a ejecutar el <code>model</code> de un control, como un radio dentro de un <code>each:</code> cuyas filas reciben un objeto nuevo, se escribía en él el valor anterior de la señal y lo editado se perdía en silencio, en el control y en el modelo. Ahora se lee primero lo que hizo el usuario.</p> </li> <li> <p><strong><code>model</code> en una casilla o un radio deja pasar el <code>value</code> del spread.</strong> <code><input type="checkbox" model="on" bind="rest"></code> descartaba el <code>value</code> de <code>rest</code>, así que el formulario enviaba <code>on</code> en lugar de ese valor. El modelo sólo controla <code>checked</code>. En un control de texto, el modelo sigue decidiendo <code>value</code>.</p> </li> <li> <p><strong><code>meeko dev</code> ya no termina si su primer servidor falla en plena reconstrucción de un paquete enlazado.</strong> La escritura sólo contaba tras 100 ms sin eventos, así que durante una ráfaga el supervisor creía que no se había escrito nada y salía con el código del servidor. Ahora compara los archivos antes de decidir, y vuelve a arrancarlo cuando el paquete deja de escribirse. Un evento que no escribió nada, como una lectura en Windows, sigue sin contar: el servidor roto termina con su código.</p> </li> <li> <p><strong><code>meeko dev</code> con un Meeko enlazado ya no avisa ni se reinicia sin un build.</strong> El vigilante de <code>dist</code> llamaba a <code>change()</code> ante un <code>rename</code>, un evento sin nombre, un archivo que desaparecía o un error del vigilante, aunque nada se hubiera escrito: con <code>MEEKO_LINK_WATCH=0</code> salía «Meeko enlazado cambió» sin que nadie compilara, y el supervisor del modo normal reiniciaba un servidor sano. Ahora, pasado un periodo de calma, compara una huella de las rutas, fechas de modificación y tamaños de <code>dist</code> y de <code>package.json</code> con la última conocida, y sólo si difiere avisa o reinicia; sigue valiendo borrar y recrear <code>dist</code>, y un build que escribe mientras se compara se detecta con su propio evento. La huella inicial se toma al empezar a vigilar, antes de lanzar el servidor; en el modo sin supervisor, un build escrito después de arrancar el proceso y antes de vigilar se avisa una vez. Vale también para los demás paquetes enlazados que vigila el supervisor.</p> </li> <li> <p><strong>La primera navegación desde un 404 de una URL con ruta.</strong> Tras hidratar la página de error de <code>notFound()</code>, o el <code>404.html</code> de un host estático en una ruta dinámica, el navegador creía tener los layouts de esa ruta en lugar de los de la página de error: podía pintar la página siguiente dentro del layout equivocado. Ahora parte de los layouts que hidrató.</p> </li> <li> <p><strong><code>meeko check</code> y los autoimports de navegador en un <code>.ts</code> de <code>app/</code>.</strong> <code>resolveComponent</code>, <code>useHead</code>, <code>useSeoMeta</code>, <code>useTheme</code>, <code>useLayout</code>, <code>useForm</code>, <code>useStorage</code>, <code>ClientError</code> e <code>isClientError</code> daban <code>TS2304</code> en un módulo de <code>app/composables</code> o <code>app/utils</code>, aunque ahí están permitidos y funcionan: el módulo también entra en el programa de <code>tsconfig.server.json</code>, donde esos nombres no existen. <code>meeko check</code> ya no da por buenos sus diagnósticos en ese proyecto, y el código de servidor que los usa sigue fallando. <code>tsc -p .meeko/tsconfig.server.json</code> a mano los sigue mostrando.</p> </li> <li> <p><strong><code>.mts</code> en los autoimports.</strong> Sus exports se recogían y se declaraban, pero el import generado apuntaba a <code>.js</code>, así que usarlos daba <code>TS2307</code> en <code>meeko check</code> y <code>meeko build</code> y un <code>500</code> en <code>meeko dev</code>. Ahora funcionan como un <code>.ts</code>. Un <code>.cts</code> sólo sirve para tipos: un valor con <code>export</code> sigue dando <code>TS1287</code>.</p> </li> <li> <p><strong><code>Button/Index.meeko</code> es <code><Button></code>.</strong> Una carpeta con su <code>Index.meeko</code> (o <code>index.meeko</code>) se llamaba <code><ButtonIndex></code>. Ahora se llama como la carpeta, con <code>ButtonProps</code>, <code>ButtonEmits</code>, <code>ButtonSnippets</code> y demás, en <code>app/components</code>, en los layers y en las carpetas de los módulos con su prefijo, y también en <code>resolveComponent</code> e <code>is</code>. <code>Index.meeko</code> en la raíz sigue siendo <code><Index></code>. El nombre anterior y sus tipos funcionan en <code>1.x</code> con el aviso <code>MEEK134</code> en <code>meeko check</code>, <code>meeko build</code> y el editor, y se retiran en <code>2.0</code>. Si <code>Button.meeko</code> y <code>Button/Index.meeko</code> existen a la vez, también en fuentes distintas, nada cambia de archivo: conservan <code><Button></code> y <code><ButtonIndex></code>, con el aviso <code>MEEK135</code> en el <code>Index.meeko</code>. Tampoco cambia de archivo un nombre con un <code>Index</code> anidado: con <code>Button/Index.meeko</code> y <code>Button/Index/Index.meeko</code>, <code><ButtonIndex></code> sigue siendo del primero y el segundo sigue siendo <code><ButtonIndexIndex></code>, con <code>MEEK135</code>. Fuera de un <code>.meeko</code>, <code>meeko check</code> no avisa del nombre anterior: <code>ButtonIndexProps</code> en un <code>.ts</code> compila sin <code>MEEK134</code>.</p> </li> <li> <p><strong>El editor formatea igual que <code>prettier --check</code>.</strong> <code>@meekojs/meeko/prettier</code>, el plugin que usa el servidor de lenguaje, ordena con <code>meekoSortClasses</code> el <code>class</code> de una etiqueta de componente y las cadenas de <code>bind:class</code>, y añade <code>meekoClassFunctions</code> (<code>tv</code>, <code>clsx</code>, <code>cn</code>…), como <code>@meekojs/prettier-plugin</code>. Antes, al guardar quedaban sin ordenar y la comprobación de Prettier fallaba justo después. Quien ya use <code>meekoSortClasses</code> verá ordenados esos valores al guardar; con <code>"off"</code> no cambia nada. Con <code>htmlWhitespaceSensitivity: "ignore"</code>, tampoco añade ya un espacio visible entre un texto y un elemento en línea (<code><code>x</code>.</code>).</p> </li> <li> <p><strong>El <code>404</code> de una página en el servidor lleva layout.</strong> <code>notFound()</code> en SSR respondía la página de error sola: sin cabecera, pie, <code><main></code> ni enlace para saltar, aunque en una navegación de cliente sí iba dentro del layout. Ahora da el mismo documento que una URL sin ruta, con los layouts raíz, y se hidrata; con un <code>+error.meeko</code> más cercano, va dentro de los layouts de la página, sin hidratar. Si un layout falla al pintarlo sigue saliendo la página de error sola, y con otros errores no cambia nada, porque un layout puede ser lo que ha fallado.</p> </li> <li> <p><strong><code>layoutProps</code> con <code><script server></code> de nivel superior: <code>data</code> tipado y <code>export const layoutProps</code>.</strong> <code>layoutProps: ({ data }) => …</code> tenía <code>data</code> como <code>unknown</code>, aunque la guía decía que son los exports; ahora lo son también para los tipos, si las opciones son un objeto literal sin spread. Además, un dato para el layout sólo llegaba allí exportándolo a la página, así que viajaba dos veces. Con <code>export const layoutProps</code>, como <code>head</code>, las props se tipan con sus valores, se comprueban contra el layout, también el heredado (<code>MEEK_PAGE_LAYOUT_PROPS</code>), y no entran en los datos de la página. Con las dos formas a la vez es <code>MEEK072</code>.</p> </li> <li> <p><strong>Cambio incompatible de tipos, excepción aprobada: <code><Nombre>Props</code> ya no incluye los callbacks de <code>defineEmits</code>.</strong> Un envoltorio de un componente no se podía escribir: <code>BaseButtonProps</code> traía <code>onClick</code>, que chocaba con su <code>defineEmits</code> (<code>TS2344</code>) o llegaba a <code>bind="rest"</code> (<code>MEEK113</code>). Ahora <code>BaseButtonProps</code> son sólo las props, <code>BaseButtonEmits</code> es el mapa de <code>defineEmits</code>, y <code>ComponentProps<"BaseButton"></code> y el <code>ComponentProps</code> del módulo siguen con todo. Quien lea o escriba <code>onX</code> en <code>BaseButtonProps</code> cambia ese tipo por <code>ComponentProps<"BaseButton"></code>. Sólo cambian los tipos, no el SSR ni la hidratación. Un paquete publicado antes no hay que republicarlo: Meeko lee lo que exporta su <code>.d.meeko.ts</code>, así que su <code><Nombre>Props</code> sigue siendo su <code>ComponentProps</code> y no tiene <code><Nombre>Emits</code>. Véanse <a href="/docs/stability#excepciones-aprobadas">excepciones aprobadas</a> y la <a href="/docs/migration-1.8">migración</a>.</p> </li> <li> <p><strong><code>bind</code> con el resto de una unión de props en un componente.</strong> El resto llegaba aplanado al hijo (<code>to?: string; href?: string</code>), y un reenvío correcto daba <code>TS2345</code> o <code>TS2379</code>. Ahora se conservan las variantes, y la exclusión entre ellas llega al padre.</p> </li> <li> <p><strong><code>defineEmits</code> con un mapa importado no deja sus callbacks en el resto.</strong> Con <code>defineEmits<BaseButtonEmits>()</code> el compilador no conoce los eventos, así que <code>onClick</code> seguía en <code>rest</code> y <code>bind="rest"</code> lanzaba <code>MEEK113</code> en el SSR cuando el padre usaba <code>on:click</code>, con los tipos correctos. Ahora toda clave <code>onX</code> queda fuera de la enumeración de <code>props</code> y del resto en ese caso; <code>props.onX</code> sigue leyéndose.</p> </li> <li> <p><strong>Un mensaje útil para <code>TS2312</code>.</strong> <code>interface Props extends X</code> con unas props que son una unión da, en <code>meeko check</code> y en el editor, una propuesta: <code>type Props = X & { … }</code>. Con unas props que son un objeto ya funcionaba, también con <code>defineEmits</code>: lo impide la unión, no los callbacks.</p> </li> <li> <p><strong><code>meeko dev</code> sobrevive a una reconstrucción del workspace.</strong> Al reconstruir, el reinicio llegaba mientras otro paquete enlazado, como <code>packages/ui</code>, escribía su <code>dist</code>, fallaba con <code>El componente externo … necesita una declaración adyacente .d.meeko.ts</code> y se quedaba parado hasta el siguiente cambio de <code>@meekojs/meeko</code>. Ahora vigila también los demás paquetes enlazados que usan Meeko: un reinicio pendiente espera a que se estabilicen, un servidor que falló vuelve cuando cambian y, si se escribieron después de arrancarlo, reintenta hasta 6 veces, con esperas que se doblan. Si no se escribió nada, el fallo es real y se informa como antes. Compilar esos paquetes no reinicia un servidor sano.</p> </li> <li> <p><strong><code>defineExpose</code> en un componente genérico ya no rompe su <code>.d.meeko.ts</code>.</strong> La declaración incluía todo lo que devuelve el setup, y los parámetros de <code>generic</code> dentro de un argumento de tipo, como los de <code>defineEmits</code> y <code>defineSnippets</code>, salían como <code>T_1</code> y <code>T_2</code>, que no existen (<code>TS2304</code>). Ahora sólo queda lo que lee <code>ComponentExposed</code>. El tipo expuesto sigue siendo <code>any</code> en la declaración, como en cualquier componente.</p> </li> <li> <p><strong><code>class</code>, <code>bind:class</code> y <code>bind="obj"</code> se combinan siempre.</strong> Con un spread, el último de <code>class</code> y <code>bind:class</code> sustituía al otro, y lo mismo con <code>style</code>, aunque sin spread se unían y la documentación decía que se combinan. Ahora dan una sola clase en cualquier orden, en SSR, hidratación y actualizaciones, en un elemento y en <code><component is></code> con etiqueta.</p> </li> <li> <p><strong>Aviso <code>MEEK133</code>: el mismo atributo como texto y con <code>bind:</code>.</strong> <code>id="a" bind:id="b"</code> escribía los dos en el HTML, el navegador se quedaba con el primero y, en ese orden, la hidratación fallaba con <code>Hydration mismatch</code>. Ahora vale <code>bind:id</code> en cualquier orden, sin ese fallo, y <code>meeko check</code>, <code>meeko build</code> y el editor lo avisan. <code>class</code> y <code>style</code> no cuentan, porque se combinan; en un componente sigue siendo <code>MEEK090</code>.</p> </li> <li> <p><strong>Un <code>aria-current</code> propio gana a la ruta en <code><MeekoLink></code>.</strong> <code>bind:aria-current</code> escribía el atributo junto al de la ruta, y en un enlace activo el servidor y el cliente no coincidían: <code>Hydration mismatch ... (attribute aria-current)</code>, y la página dejaba de hidratar. Un <code>aria-current</code> escrito salía dos veces y uno en <code>bind</code> se ignoraba. Ahora los tres ganan a la ruta en SSR, hidratación y actualizaciones, también en <code><component is="'MeekoLink'"></code> y en <code>resolveComponent("MeekoLink")</code>: <code>false</code> quita el atributo y <code>null</code> o <code>undefined</code> dejan decidir a la ruta, que sigue comparando el <code>href</code> resuelto. Sin <code>aria-current</code> propio nada cambia. Un <code>aria-current</code> y un <code>bind:aria-current</code> en el mismo enlace son <code>MEEK105</code>. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/components/meekolink.md"><code><MeekoLink></code></a>.</p> </li> <li> <p><strong><code><component is></code> con un valor de ejecución pasa <code>aria-*</code> y <code>data-*</code> a un componente.</strong> Como en su etiqueta desde <code>1.8</code>. Antes sólo llegaban a un elemento: <code><component is="form.value" bind:aria-label="…"></code>, con el componente de <code>resolveComponent</code>, los perdía. Si el componente no declara el atributo, <code>meeko check</code> da <code>TS2353</code> en él, como en su etiqueta, en lugar de <code>MEEK112</code>.</p> </li> <li> <p><strong><code><MeekoLink></code> acepta <code>params</code> en <code>undefined</code> en una ruta estática.</strong> Un componente que reenvía <code>bind:params</code>, como <code>UIButton</code>, <code>UILink</code> o <code>UILinkCard</code>, daba <code>TS2379</code> en <code>meeko check</code> y <code>meeko build</code> si la aplicación tenía una sola ruta y era estática, como una aplicación nueva. Unos <code>params</code> reales en una ruta estática siguen siendo un error.</p> </li> <li> <p><strong><code><select></code> con contenido rico.</strong> parse5 eliminaba sin avisar <code><button></code>, <code><selectedcontent></code>, <code><div></code>, <code><legend></code> y <code><span></code> dentro de un <code><select></code>, una opción con <code><span></code> publicaba <code></span><span></code> como texto visible y una con <code><svg></code> daba <code>MEEK001</code>. Ahora el compilador lee el <code><select></code> como los navegadores actuales y conserva ese contenido. La salida de un <code><select></code> sin contenido rico no cambia. Como el navegador cierra el <code><select></code> al encontrar <code><input></code> u otro <code><select></code>, dentro de él esas dos etiquetas son ahora <code>MEEK008</code>; antes compilaban a un <code><select></code> vacío seguido de sus opciones sueltas.</p> </li> <li> <p><strong>La hidratación ya no se engancha al clon de <code><selectedcontent></code>.</strong> Chromium y WebKit copian ahí la opción elegida, con sus <code>data-meeko</code> y sus marcadores, y la hidratación encontraba antes la copia: con una opción estática enlazada y elegida al cargar, señales y eventos iban al clon y no a la opción.</p> </li> <li> <p><strong>El router da a su View Transition el tipo <code>meeko-route</code>.</strong> <code>html:active-view-transition-type(meeko-route)</code> distingue una navegación de una transición propia de un componente. Sin tipos de transición en el navegador, la navegación se anima igual, con el callback solo.</p> </li> <li> <p><strong><code>on:command</code> recibe un <code>CommandEvent</code>.</strong> <code>on:command="(event: CommandEvent) => …"</code> daba <code>TS2345</code>, porque los mapas de eventos de TypeScript dicen <code>Event</code>. Vale para <code>meeko check</code>, el editor y su hover.</p> </li> <li> <p><strong><code>interestfor</code> en los datos HTML.</strong> El atributo (<code><a></code>, <code><area></code>, <code><button></code>) y los eventos <code>interest</code> y <code>loseinterest</code> constan como experimentales, según <code>@mdn/browser-compat-data</code>: aún no están en el estándar.</p> </li> <li> <p><strong>Un <code><component is="'select'" bind:value></code> explica qué hacer.</strong> Sigue siendo <code>MEEK112</code>, porque <code><select></code> no tiene ese atributo, pero el mensaje indica que se marque la opción con <code>bind:selected</code> o se escriba <code><select></code> en la plantilla con <code>model</code>.</p> </li> <li> <p><strong>Los saltos de línea que formatean un <code><snippet></code> ya no son contenido.</strong> Prettier deja <code><snippet name="code" params="text"></code> en varias líneas, y esos espacios llegaban adonde el hijo pinta el snippet: dentro de una frase, <code><code>.meeko</code>.</code> se veía como <code>.meeko .</code>, y entre elementos en línea aparecía un hueco. Ahora el compilador quita, en los dos extremos de un <code><snippet></code>, el texto que sólo tiene espacios y al menos un salto de línea, en SSR, hidratación y actualizaciones. Un espacio en la misma línea (<code><snippet name="a"> <b>x</b> </snippet></code>) sigue siendo contenido, igual que el texto. Un snippet que contaba con ese espacio para separarse de sus vecinos debe escribirlo en una sola línea o separarlos con CSS. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/syntax/snippet-tag.md"><code><snippet></code></a>.</p> </li> <li> <p><strong><code>sitemapXml</code> es público.</strong> Una aplicación que sirve el sitemap desde una base de datos (<code>sitemap: false</code>) tenía que escribir a mano el XML y sus <code>xhtml:link</code>. Ahora <code>@meekojs/meeko/framework</code> exporta <code>sitemapXml(origin, urls)</code>, la misma función con la que <code>meeko build</code> escribe <code>sitemap.xml</code>: rutas o URL con <code>lastmod</code>, <code>changefreq</code>, <code>priority</code> y <code>alternates</code>, con el XML escapado y los mismos errores de <code>hreflang</code> y <code>pathname</code>. No usa APIs de Node, así que también funciona en Workers. Véase <a href="/docs/framework#sitemap-servido-desde-una-base-de-datos">Sitemap servido desde una base de datos</a>.</p> </li> <li> <p><strong>Resolvedores de enlaces: <code>app.resolveLink</code> y <code><MeekoLink bind:resolve></code>.</strong> Con rutas localizadas, <code><MeekoLink to></code> necesitaba el ID con el prefijo (<code>/en/guide</code>), así que los enlaces de una web multilingüe acababan en <code><a href={i18n.localePath(…)}></code>. Ahora un plugin o módulo registra <code>app.resolveLink(({ to, href, hreflang }) => …)</code> y cada <code><MeekoLink></code> (la etiqueta, la rama <code>'MeekoLink'</code> de <code><component is></code> y el componente de <code>resolveComponent("MeekoLink")</code>) pasa su <code>href</code> por él en el SSR, el prerender, la hidratación y la navegación del cliente; <code>aria-current</code> se calcula con el <code>href</code> resuelto. <code>hreflang</code> (escrito, con <code>bind:hreflang</code> o en <code>bind</code>) llega al resolvedor y sigue en el <code><a></code>; <code>bind:resolve="false"</code> deja el <code>href</code> de <code>href()</code>. Sin resolvedores, el HTML no cambia. Un enlace estático sigue sin enlace reactivo de <code>href</code> en la hidratación. Tipos nuevos <code>LinkResolver</code> y <code>LinkResolveInput</code> en <code>@meekojs/meeko/framework</code> y la prop <code>resolve</code> en <code>MeekoLinkProps</code>.</p> </li> <li> <p><strong><code>meeko.extendRoutes</code> y el hook <code>sitemap:resolved</code> para los módulos.</strong> Un módulo no podía añadir rutas que reutilizaran el archivo de una página, así que <code>@meekojs/i18n</code> obligaba a duplicar páginas en <code>app/pages/[locale]/…</code> para servir <code>/en/…</code>. Ahora <code>meeko.extendRoutes((routes) => [...])</code> transforma el manifiesto descubierto (aplicación, layers y módulos) antes de que lo usen el SSR, el navegador, el prerender, el sitemap, los tipos de rutas y el editor: la función devuelve la lista completa, se aplica en el orden de los módulos y su resultado se valida y ordena como un manifiesto (una colisión de URL es un error con el nombre del módulo). El hook <code>sitemap:resolved</code> recibe las URL de <code>sitemap.xml</code> antes de escribirlo; cada URL admite <code>alternates: [{ hreflang, pathname }]</code>, que se escriben como <code><xhtml:link rel="alternate" hreflang></code> con el espacio de nombres <code>xhtml</code> (un <code>hreflang</code> o un <code>pathname</code> inválidos detienen el build). Tipos públicos nuevos: <code>SitemapAlternate</code> y <code>SitemapResolvedUrl</code>. <code>meeko check</code> comprueba cada ruta añadida contra sus propios <code>params</code> y las <code>layoutProps</code> de la página que comparten una sola vez por archivo (antes, una página con <code><script server></code> que heredaba un layout daba <code>TS2300 Duplicate identifier</code> en <code>page-contracts.server.ts</code>), y <code>usePage()</code> de su <code><script server></code> se tipa con los <code>params</code> de la ruta que corresponde a su archivo, como en el editor, sea cual sea el orden de las rutas. Véase <a href="/docs/framework#el-objeto-meeko">El objeto <code>meeko</code></a>.</p> </li> <li> <p><strong><code>'MeekoLink'</code> y nombres de componente en <code><component is></code>.</strong> Un botón que es ruta, enlace externo o <code><button></code> necesitaba dos ramas con <code>if:when</code>, porque <code><MeekoLink></code> es una etiqueta del compilador y <code>is="x ? MeekoLink : 'a'"</code> era <code>TS2304</code>. Ahora un literal en PascalCase dentro de <code>is</code> nombra <code><MeekoLink></code> o un componente importado, autoimportado (<code>'UICard'</code>) o declarado en el script, y se combina con etiquetas HTML: <code>is="to !== undefined ? 'MeekoLink' : href !== undefined ? 'a' : 'button'"</code>. El compilador resuelve cada nombre como su etiqueta, sin promesas: una región <code>if:when</code> por nombre, cuya condición es el camino de <code>?:</code> hasta su literal, y otra para las etiquetas, con el SSR, la hidratación y las actualizaciones de <code>if:when</code>. Cada atributo va sólo a las ramas que lo admiten: <code>to</code>, <code>params</code>, <code>search</code> y <code>match</code> a <code>'MeekoLink'</code> (con su <code>href</code> tipado y <code>aria-current</code>, nunca <code>href</code>), los atributos HTML a las etiquetas que los aceptan y las props a los componentes. <code>meeko check</code> y el editor comprueban cada rama tras su condición, que la estrecha, cada componente con sus props sin tratar como sobrante una prop de otra rama, y dan <code>MEEK112</code> en un atributo que no admite ninguna rama. Las etiquetas van en minúscula y los componentes en PascalCase; un nombre desconocido, <code>'MeekoOutlet'</code>, <code>'MeekoTeleport'</code> o un valor junto a nombres es el error nuevo <code>MEEK132</code>, y <code>ref:</code> con varias ramas, <code>MEEK052</code>. El editor completa los nombres dentro de <code>is</code> y muestra el componente en el hover del literal. <code>is</code> con un valor de componente o con etiquetas HTML no cambia. Véase <a href="/docs/api#nombres-de-componente-en-is">Nombres de componente en <code>is</code></a>.</p> </li> <li> <p><strong><code>resolveComponent("MeekoLink")</code>.</strong> El registro de componentes incluye <code>MeekoLink</code>, que carga <code><MeekoLink></code> como componente desde <code>@meekojs/meeko/builtins/link</code>, con una variante de props por ruta (<code>to</code>, los <code>params</code> de esa ruta, <code>search</code>, <code>match</code> y los atributos de su <code><a></code> salvo <code>href</code>) y el evento <code>click</code>; un componente del proyecto llamado <code>MeekoLink</code> conserva el nombre. Los componentes de módulos (<code>UI*</code>) ya estaban en el registro. La documentación explica cuándo usar un literal en <code>is</code> (nombre conocido al escribir la plantilla, en el HTML de SSR) y cuándo <code>resolveComponent</code> (nombre en ejecución o carga diferida). Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/components/componentregistry.md">Registro de componentes</a>.</p> </li> <li> <p><strong>Los tipos que generan los módulos tipan <code>meeko.config.ts</code>.</strong> Las declaraciones de <code>meeko.addTypeTemplate</code> (<code>.meeko/types/modules.d.ts</code>) entran en la comprobación de <code>meeko.config.ts</code> de <code>meeko check</code> y <code>meeko build</code>, y en <code>.meeko/tsconfig.config.json</code> del editor. Un módulo puede tipar sus opciones con lo que genera: <code>@meekojs/icon</code> rechaza <code>icon: { include: ['lucide:chek'] }</code> con <code>TS2820</code> y la sugerencia <code>"lucide:check"</code>.</p> </li> <li> <p><strong><code>bind:viewBox</code> en SVG conserva su caso.</strong> El parser HTML sólo ajustaba el caso de los atributos SVG estáticos, así que <code>bind:viewBox</code> o <code>bind:preserveAspectRatio</code> en un <code><svg></code> se escribían en minúsculas (<code>viewbox</code>): el SVG los ignoraba y la hidratación daba <code>Hydration mismatch (attribute viewbox)</code>. Ahora <code>bind:</code> en SVG y MathML usa las mismas tablas que los atributos estáticos (<code>viewBox</code>, <code>preserveAspectRatio</code>, <code>gradientUnits</code>, <code>definitionURL</code>…), en SSR, hidratación y actualizaciones.</p> </li> <li> <p><strong>Los estilos de <code><style scoped></code> ya no cambian al hidratar.</strong> El SSR incrustaba el CSS de los componentes delante de las hojas globales, y el cliente (<code><style></code> de Vite en <code>meeko dev</code>, el CSS de los chunks de la ruta en producción) lo volvía a añadir al final del <code><head></code>: una regla global de igual especificidad (<code>.page .card</code> frente a <code>.card</code> con ámbito) ganaba en el primer pintado y perdía al cargar el JavaScript, y los estilos «saltaban» al recargar. Ahora los <code><style></code> en línea van al final del <code><head></code>, después de <code>app/styles/main.css</code>, de las hojas de los módulos y del <code>head</code> de <code>document</code>, en el documento, el streaming, el 404 y el prerender, con la misma CSP (nonce o hashes) y deduplicación. En <code>meeko dev</code> cada <code><style></code> lleva el <code>data-vite-dev-id</code> de su módulo y el cliente de Vite lo adopta en lugar de duplicarlo; la HMR lo sustituye, así que una regla borrada del <code><style></code> deja de aplicarse (antes la copia del SSR la mantenía hasta recargar). La página de error de un fallo del servidor, que no se hidrata, se servía sin el CSS de sus <code><style></code>; ahora lo incrusta. Una página que dependía de que la hoja global ganara a igual especificidad (sólo antes de hidratar) debe subir la especificidad de la regla global. Véase <a href="/docs/framework">PostCSS y Tailwind</a>.</p> </li> <li> <p><strong>El formato del editor respeta <code>.prettierignore</code> y <code>.gitignore</code>.</strong> El servidor de lenguaje (<code>editor.formatOnSave</code> y «Formatear documento» de VS Code) formateaba también los <code>.meeko</code> que el proyecto excluye de Prettier, por ejemplo las plantillas en una sola línea de <code>Popover</code>, <code>Select</code> y <code>ThemeToggle</code> de <code>@meekojs/ui</code>, donde los espacios entre etiquetas son texto. Ahora un archivo ignorado no recibe ediciones, como con la CLI de Prettier, y tampoco pasa al formateador anterior. Se leen los archivos de exclusión de la carpeta del <code>.meeko</code> y de las superiores hasta la raíz del repositorio (o la del disco), con los patrones de cada uno relativos a su carpeta; en un workspace no confiable también se respetan, porque sólo se leen datos. <code>formatWithPrettier</code> devuelve <code>ignored: true</code> con el texto original. Véase <a href="/docs/editors#formato-con-prettier">Formato con Prettier</a>.</p> </li> <li> <p><strong><code><div /></code>: los elementos sin contenido se pueden cerrar con <code>/></code>, como en Vue.</strong> <code><div /></code>, <code><span class="spinner" if:when="loading.value" /></code>, <code><li each:of="items.value" … /></code>, <code><textarea name="nota" /></code>, <code><td /></code>, <code><option /></code> o <code><my-element /></code> daban <code>MEEK001</code>, porque el parser HTML abre <code><div/></code> y mete dentro todo lo que sigue. Ahora cualquier elemento HTML no vacío o personalizado escrito con <code>/></code> equivale a su forma con etiqueta de cierre: los nodos que siguen son sus hermanos, compila exactamente igual y el SSR escribe HTML válido (<code><div></div></code>), con la misma hidratación, actualizaciones y liberación. Los elementos vacíos (<code><input /></code>), SVG y MathML no cambian. <code><template></code>, <code><script></code>, <code><style></code>, <code><html></code>, <code><head></code>, <code><body></code> y los nombres desconocidos siguen necesitando su etiqueta de cierre (<code>MEEK001</code>, con un mensaje que lo dice), y <code><td /></td></code> es <code>MEEK008</code>. El editor, <code>meeko check</code>, el parser de ESLint y Prettier, que conserva la forma escrita, lo entienden; la regla optativa <code>meeko/html-self-closing</code> de <code>@meekojs/eslint-plugin</code> unifica el estilo. <code>@meekojs/meeko/parse</code> exporta <code>isSelfClosableElement</code>. Véase <a href="/docs/api#elementos-sin-contenido-div-">Elementos sin contenido</a>.</p> </li> <li> <p><strong><code>devtools: true</code> en <code>meeko.config.ts</code>, como en Nuxt.</strong> <code>meeko dev</code> monta el panel de Meeko DevTools en la página sin <code>import()</code> ni <code>mountDevtoolsPanel()</code> en la aplicación; <code>{ position: "bottom-left" }</code> elige la esquina y <code>{ panel: false }</code> lo apaga. Por defecto, <code>false</code>. Nunca llega a <code>meeko build</code>, <code>meeko start</code> ni a las páginas prerenderizadas. Antes, <code>devtools: true</code> daba «clave desconocida "devtools"»; un valor no válido detiene la carga con un mensaje que nombra la opción, y <code>meeko check</code> lo tipa (<code>MeekoDevtoolsConfig</code>). Un módulo con <code>meta.configKey: "devtools"</code> deja de cargarse: dele otra clave.</p> </li> <li> <p><strong>El panel de DevTools con los colores de Meeko, minimizable.</strong> El panel dentro de la página y el de la extensión de Chrome usan los tokens del sitio de Meeko (acento azul, superficies neutras, Inter si está disponible) en claro y oscuro: el panel integrado sigue al sistema o al <code>data-theme</code> de la página, y la extensión, al tema de Chrome DevTools. El panel integrado se minimiza a una pastilla con el logo y el número de eventos nuevos (botón accesible o <code>Alt+Mayús+M</code>), se mueve a otra esquina arrastrando su asa o con las flechas, y recuerda ambas cosas en <code>localStorage</code>. <code>mountDevtoolsPanel</code> acepta <code>position</code>.</p> </li> <li> <p><strong>Módulos por su nombre, como en Nuxt.</strong> <code>modules: ['@meekojs/i18n', '@meekojs/ui']</code> registra los módulos sin importarlos y cada uno lee sus opciones de su clave (<code>i18n: { … }</code>, <code>ui: { … }</code>, la de su <code>meta.configKey</code>). Un paquete se resuelve por su subpath <code>./module</code> si lo exporta (<code>@meekojs/i18n</code>, <code>@meekojs/meeko/i18n</code>) y, si no, por su raíz. La clave queda tipada sin imports: <code>meeko dev</code>, <code>meeko check</code>, <code>meeko build</code>, <code>meeko routes</code> y el editor de un workspace de confianza escriben <code>.meeko/types/config.d.ts</code>, que importa los tipos de cada módulo de <code>modules</code> y carga su ampliación de <code>MeekoConfig</code>, y <code>.meeko/tsconfig.config.json</code>, al que apunta el <code>tsconfig.json</code> de <code>meeko init</code>. El editor completa dentro de <code>modules: ['…']</code> las dependencias con la palabra clave <code>meeko-module</code> (nuevos tipos <code>MeekoModuleNames</code> y <code>MeekoModuleName</code>) y documenta la clave en el hover (<code>defineMeekoConfig</code> recibe <code>T & MeekoConfig</code>). <code>meeko check</code> comprueba siempre <code>meeko.config.ts</code> con esos tipos (antes, sólo cuando la carga fallaba), así que <code>i18n: { defaultLocale: 1 }</code> es <code>TS2322</code>. Una cadena que no resuelve sugiere el módulo instalado más parecido; un paquete sin módulo y dos módulos con la misma <code>configKey</code> dan errores claros; la clave de un módulo instalado que falta en <code>modules</code> es el aviso <code>MEEK127</code>. El módulo integrado <code>@meekojs/meeko/i18n</code> declara <code>configKey: 'i18n'</code>.</p> </li> <li> <p><strong>Obsoletos: el módulo importado y <code>[módulo, opciones]</code> en <code>modules</code>.</strong> Siguen funcionando en <code>1.x</code> con el aviso <code>MEEK126</code> en <code>meeko dev</code>, <code>meeko build</code>, <code>meeko check</code> y el editor, que indica la cadena y la clave que los sustituyen; se retiran en <code>2.0</code>. Véase <a href="/docs/migration-1.8#m%C3%B3dulos-por-su-nombre">Actualizar de 1.7 a 1.8</a>.</p> </li> <li> <p><strong><code>meeko check</code> y el editor avisan de un <code>onCleanup</code> que rompe el SSR.</strong> Una limpieza registrada en el nivel superior del <code><script></code>, en un <code>effect</code> o en un composable que el setup llama también se ejecuta en el servidor, al liberar la raíz tras el render; si usa <code>window</code>, <code>document</code>, <code>cancelAnimationFrame</code>, <code>ResizeObserver</code> u otra API que sólo existe en el navegador, fallaba en Node con <code>ReferenceError</code>. Ahora es el aviso <code>MEEK128</code>, con la corrección rápida «Mover a <code>onMounted</code>» (o dentro del <code>onMounted</code> existente). No avisa si la limpieza está protegida con <code>typeof window</code> o <code>import.meta.env.SSR</code>, ni dentro de <code>onMounted</code> o de un manejador, y el checker de TypeScript distingue una variable local <code>window</code> de la global. Además, <code>MEEK129</code> marca un <code>onCleanup</code> tras un <code>await</code> de su función <code>async</code>, y <code>meeko check</code> de un proyecto da <code>MEEK130</code> para un <code>onCleanup</code> al evaluar un módulo de <code>app/</code>, <code>shared/</code> o <code>server/</code>. Son avisos en <code>1.x</code> y serán errores en <code>2.0</code>; véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/reactivity/oncleanup.md">onCleanup</a>.</p> </li> <li> <p><strong><code>defineProps</code> se puede desestructurar sin perder la reactividad.</strong> <code>const { to, type = 'button', disabled = false, label = '', class: className, ...rest } = defineProps<Props>()</code> daba <code>MEEK015</code>. Ahora, como en Vue 3.5, el compilador escribe cada lectura de un nombre desestructurado como una lectura de la prop, en el script, la plantilla, <code>computed</code>, <code>effect</code>, manejadores y closures; un parámetro, una variable local, un <code>each:as</code> o un parámetro de snippet con el mismo nombre no cambia. Los defaults del patrón equivalen al argumento de defaults (la prop es opcional para el padre y nunca <code>undefined</code> dentro, y un objeto o un array se crea por instancia); con los dos a la vez es <code>MEEK124</code>. <code>class: className</code> renombra y <code>...rest</code> es una vista de sólo lectura que sigue al padre, sin las props desestructuradas ni los manejadores de <code>defineEmits</code>, lista para <code>bind="rest"</code>. Las uniones discriminadas se estrechan en el script y en la plantilla (<code>if:when="to !== undefined"</code> da los <code>params</code> de esa rama), en <code>meeko check</code> y en el editor, donde el hover y el completado de cada nombre muestran su tipo y renombrarlo cambia sólo la variable local (<code>{ label: text }</code>). Asignar un nombre desestructurado o borrarlo con <code>delete</code> es <code>MEEK125</code>, antes de generar código; <code>typeof label</code> en un tipo también lee la prop; copiarlo en el setup, el aviso <code>MEEK101</code>; un nombre que no es una prop, <code>TS2344</code>. La desestructuración anidada, de array, con clave calculada o con <code>let</code> sigue siendo <code>MEEK015</code>, con un mensaje que explica la alternativa. SSR, hidratación y HMR no cambian. Véase <a href="/docs/api#desestructurar-las-props">Desestructurar las props</a>.</p> </li> <li> <p><strong>El editor muestra los valores por defecto de las props.</strong> En el padre, el hover de una etiqueta de componente, el de cada prop (<code>size?: "sm" | "md" = "md"</code>) y el detalle del completado de sus atributos muestran el default, escrito en el argumento de <code>defineProps</code> o en la desestructuración. El módulo compilado exporta el tipo <code>ComponentDefaults</code> con el texto de cada default, que también llevan las declaraciones <code>.d.meeko.ts</code>. Además, el editor ya trata como opcional para el padre una prop con default en la desestructuración, como <code>meeko check</code>, y calcula los defaults por variante de una unión.</p> </li> <li> <p><strong>Constantes en los valores por defecto de <code>defineProps</code>.</strong> Un default (en el argumento o en la desestructuración) puede leer constantes de nivel superior del script cuyo valor sólo usa literales, imports y otras constantes así (<code>const SIZES = ['sm', 'md'] as const</code>, <code>size: SIZES[1]</code>); se evalúan otra vez con los defaults, por instancia. Lo que depende del setup (una prop, una señal, <code>let</code>, una función del script, el valor de una llamada, o <code>arguments</code>, <code>new.target</code> y <code>super</code> de la función del setup) es <code>MEEK123</code>, con la prop, la variable y el motivo; antes era <code>TS2304: Cannot find name</code>. Las variables que declara el propio default (locales, bloques, <code>catch</code>, parámetros, accessors) no cuentan. Los tipos de los defaults se calculan por variante de una unión de props: un default de una prop que una variante declara <code>never</code> (<code>type</code> en la rama de enlace de un botón polimórfico) ya no permite al padre pasarla en esa variante. Véase <a href="/docs/api#constantes-en-los-valores-por-defecto">Constantes en los valores por defecto</a>.</p> </li> <li> <p><strong>Un default en el discriminante de una unión ya no permite omitirlo en todas las variantes.</strong> Con <code>type Props = { kind: "a"; a: string } | { kind: "b"; b: string }</code> y <code>kind = "a"</code> (o <code>defineProps<Props>({ kind: "a" })</code>), el padre podía escribir <code><Child b="hello" /></code>: el componente recibía <code>{ kind: "a", b: "hello" }</code>, que no es ninguna variante, y fallaba en ejecución. Ahora un default literal, o una constante de nivel superior con un literal, hace opcional su prop sólo en las variantes que admiten ese valor, en <code>ComponentProps</code>, las declaraciones <code>.d.meeko.ts</code>, <code>meeko check</code> y el editor; ese padre es un error de tipos y debe pasar <code>kind="b"</code>. Un default que no es literal (un import, <code>KINDS[0]</code>) sigue siendo opcional en todas las variantes, y es el error nuevo <code>MEEK131</code> sobre la prop si alguna variante que la exige no admite su valor. Véase <a href="/docs/api#constantes-en-los-valores-por-defecto">Constantes en los valores por defecto</a>.</p> </li> <li> <p><strong>Valores de los atributos HTML, del estándar.</strong> Meeko conoce los valores que admite cada atributo (<code>type</code> de <code><button></code>, <code>hidden</code>, <code>closedby</code> de <code><dialog></code>, <code>aria-pressed</code>…), de los datos HTML que genera <code>scripts/html-data.ts</code>. Los tipos públicos <code>AttributeValues<Tag, Name></code> y <code>AttributeValueOf<Tag, Name></code>, y los valores de <code>ElementAttributes<Tag></code>, los sugieren al completado sin dejar de aceptar cualquier valor, así que no rompen código de <code>1.x</code>. <code>meeko check</code>, <code>meeko build</code> y el editor dan el aviso <code>MEEK122</code> cuando el valor es un literal fuera de ellos (<code><button type="sumbit"></code>, <code>bind:type="'sumbit'"</code>), también en <code><component is></code> con etiquetas; un <code>string</code> calculado no avisa. En <code>2.0</code> será un error. Véase <a href="/docs/api#valores-de-los-atributos">Valores de los atributos</a>.</p> </li> <li> <p><strong><code>hidden="until-found"</code> con <code>bind:</code>.</strong> <code>bind:hidden</code> trataba <code>hidden</code> como booleano y escribía <code>hidden=""</code> con cualquier texto, así que <code>bind:hidden="'until-found'"</code> perdía su valor. Ahora un texto no vacío se escribe tal cual, en SSR y en el navegador; <code>true</code> sigue escribiendo <code>hidden=""</code> y un valor falso lo quita. La lista de atributos booleanos sale de los datos HTML del estándar: <code>itemscope</code>, <code>headingreset</code>, <code>typemustmatch</code>, <code>alpha</code>, <code>scoped</code>, <code>seamless</code> y los <code>shadowroot*</code> se escriben vacíos con un valor verdadero.</p> </li> <li> <p><strong>Datos HTML generados desde las especificaciones.</strong> La lista de atributos, copiada a mano de los datos de MDN del editor, se había quedado atrás: no tenía <code><dialog closedby></code>, <code>command</code> ni <code>commandfor</code>, <code><template shadowrootmode></code> ni <code>writingsuggestions</code>. Ahora <code>pnpm -F @meekojs/meeko html-data</code> genera <code>src/shared/html-data/</code> desde el HTML Living Standard del WHATWG, WAI-ARIA 1.3 (con DPUB-ARIA y Graphics ARIA), Referrer Policy y <code>@mdn/browser-compat-data</code>: etiquetas y elementos vacíos, atributos globales y de cada elemento con sus valores enumerados (<code>closedby</code>: <code>any</code>, <code>closerequest</code> y <code>none</code>; <code>popover</code>: <code>auto</code>, <code>manual</code> y <code>hint</code>; los 22 de <code><input type></code>), si son booleanos y si son experimentales u obsoletos, los <code>aria-*</code> con sus valores, los roles y los eventos. Los módulos que necesita el runtime (nombres de etiquetas y de atributos) van separados de los detalles para el compilador y el editor, que no llegan al navegador. Lo que Meeko 1.7 aceptaba y ninguna especificación recoge ya (<code><body alink></code>, <code>contextmenu</code>…) se sigue aceptando, marcado como obsoleto; <code>hidden</code> deja de ser booleano porque admite <code>until-found</code>. Las especificaciones se guardan como instantáneas en <code>scripts/html-data/</code>, así que la generación es reproducible sin red, y <code>tests/html-data.test.ts</code> falla si los módulos no están al día. Véase <a href="/docs/editors#datos-html-de-meeko">Datos HTML de Meeko</a>.</p> </li> <li> <p><strong><code>aria-*</code> y <code>data-*</code> pasan a los componentes como props.</strong> <code><AppButton aria-label="Cerrar" data-state="open" bind:aria-busy="saving.value" /></code> daba <code>MEEK032</code> («los nombres con guiones no son props»); ahora cada atributo <code>aria-*</code> o <code>data-*</code> en minúsculas, estático o con <code>bind:</code>, es una prop con ese nombre en las etiquetas de componente y en <code><component is></code> con un componente. El hijo las declara (por ejemplo, <code>defineProps<Props & ElementAttributes<'button'>>()</code>) y una sin declarar es <code>TS2353</code> en el atributo. <code>Aria-Label</code> y <code>data-meeko*</code> dan un <code>MEEK032</code> propio. Véase <a href="/docs/api#props-est%C3%A1ticas">Props estáticas</a>.</p> </li> <li> <p><strong><code>props</code> ya no enumera los manejadores de <code>defineEmits</code>.</strong> El objeto <code>props</code> llevaba en ejecución los callbacks de los eventos (<code>onClick</code>) aunque su tipo no los declarase, así que <code>const { label, ...rest } = props</code> con <code>bind="rest"</code> lanzaba <code>MEEK113: bind="…" no admite la clave "onClick"</code>. Ahora <code>Object.keys</code>, <code>in</code>, la propagación y el resto los omiten cuando el script escribe los eventos (tipo literal, o <code>interface</code> o <code>type</code> locales); <code>props.onClick</code> y <code>emit</code> siguen igual. Véase <a href="/docs/api#eventos-de-componente-defineemits-y-on">Eventos de componente</a>.</p> </li> <li> <p><strong><code><MeekoLink></code> y <code>href()</code> sin rutas generadas: <code>params</code> es opcional.</strong> Cuando el proyecto no tiene <code>.meeko/types/routes.d.ts</code> (<code>RouteId</code> es <code>string</code>: una librería como <code>@meekojs/ui</code> o una app antes de <code>meeko check</code>), <code><MeekoLink to="/anything"></code> daba <code>TS2345</code> (<code>Property 'params' is missing</code>) y <code>bind:params="props.params"</code> con <code>Record<string, string> | undefined</code>, <code>TS2322</code>, y había que escribir <code>params ?? {}</code>; <code>href("/x", { search })</code> fallaba igual. Ahora, sin rutas generadas, <code>params</code> es opcional y admite <code>Record<string, string></code> o <code>undefined</code>, en <code><MeekoLink></code> y en <code>href()</code>. Con rutas generadas no cambia: una ruta dinámica exige sus <code>params</code> y una estática los prohíbe. <code>@meekojs/ui</code> quita ese rodeo de <code>UIButton</code> y <code>UILink</code>. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/components/meekolink.md"><code><MeekoLink></code></a>.</p> </li> <li> <p><strong><code><MeekoLink></code> acepta una unión de rutas con sus <code>params</code>.</strong> En un componente con <code>to: RouteId</code>, <code><MeekoLink bind:to="props.to" bind:params="props.params" bind:search="props.search"></code> daba <code>TS2412</code>, porque la comprobación sólo admitía <code>params</code> cuando <code>to</code> era una sola ruta y no aceptaba <code>search</code> opcional. Con una unión, <code>params</code> puede ser los de alguna de las rutas, o ninguno; con una sola ruta la comprobación no cambia. La documentación muestra cómo tipar las props para que el padre pase cada ruta con sus parámetros y un botón que es ruta, enlace externo o <code><button></code>. Véase <a href="/docs/api#un-bot%C3%B3n-que-es-ruta-enlace-o-bot%C3%B3n">Un botón que es ruta, enlace o botón</a>.</p> </li> <li> <p><strong>Snippets cuyo nombre sale de un genérico: <code>cell-<clave></code> y <code>header-<clave></code>.</strong> El <code>name</code> de <code><snippet></code> admite, además de un identificador, segmentos unidos por guiones (<code>cell-email</code>, <code>header-created-at</code>; regla <code>/^[A-Za-z_$][\w$]*(?:-[\w$]+)*$/</code>, sin guion final ni doble); antes era <code>MEEK061</code>. <code>defineSnippets<T></code> acepta claves de un tipo mapeado con template literal sobre los parámetros de tipo del componente, como <code>{ [K in keyof Row & string as `cell-${K}`]?: [row: Row, value: Row[K]] }</code>, que antes daba <code>TS2344</code>. En el padre, <code>meeko check</code>, <code>checkApp</code> y el editor comprueban cada snippet con el tipo que infieren las props: <code>value</code> tiene el tipo de su columna, un nombre inexistente es <code>TS2353</code> (marcado sobre el nombre) y unos <code>params</code> de más, <code>TS2345</code>. El editor completa los nombres (las claves concretas o, si no se conocen, el prefijo como <code>cell-$1</code>) y muestra su firma en el hover. En el propio componente, una intersección con un tipo mapeado se tipa miembro a miembro, así que <code>snippets.cell</code> conserva su tupla; un nombre calculado (<code>snippets[`cell-${key}`]</code>) funciona en ejecución, pero TypeScript no lo tipa sobre un genérico y se lee de una vista con conversión. SSR, hidratación y actualizaciones no cambian. Véase <a href="/docs/api#snippets-con-definesnippets">Snippets dinámicos tipados por un genérico</a>.</p> </li> <li> <p><strong><code>{{ expr }}</code> dice que Meeko interpola con una sola llave.</strong> Por costumbre de Vue, <code>{{ props.label }}</code> o <code>{ {props.label} }</code> en el texto de la plantilla daban <code>MEEK020: ',' expected</code> (las llaves interiores se leen como un objeto literal) y <code>{{ name }}</code> compilaba y pintaba <code>[object Object]</code>. Ahora una interpolación del texto que empieza y termina con llave y no compila, o es un objeto literal abreviado, da <code>MEEK020</code> con «Meeko interpola con una sola llave: {expr}, no {{expr}}» y el enlace a cómo escribir llaves como texto, en el compilador, <code>meeko check</code> y el editor, que marca la interpolación entera y ofrece «Convertir a {expr}», «Mostrar las llaves como texto» (<code>{"{hola}"}</code>) y «Corregir todas las del archivo». <code>{{</code> no es un alias: un objeto literal con sus claves (<code>{{ a: 1 }}</code>) sigue compilando sin aviso. Véase <a href="/docs/editors#acciones-r%C3%A1pidas">Acciones rápidas</a>.</p> </li> <li> <p><strong>El editor completa <code>bind:<atributo></code> y ordena los valores de las directivas por lo que declara el script.</strong> En un elemento, <code>bind</code> sólo ofrecía <code>bind</code> y <code>bind:</code>; ahora ofrece cada atributo de la etiqueta con <code>bind:</code> (<code>bind:type</code>, <code>bind:href</code>, <code>bind:closedby</code>, los globales, <code>aria-*</code> y <code>bind:data-…</code>), con el tipo que espera la expresión (<code>bind:type: 'submit' | 'reset' | 'button'</code>) y los obsoletos tachados, desde los datos HTML de Meeko; los valores estáticos (<code>type="…"</code>, <code>role="…"</code>, <code>aria-pressed="…"</code>) salen de los mismos datos. <code>ref:</code> ofrece los nombres de <code>useElementRef</code> del script, los que no tienen etiqueta primero. Dentro de un valor van primero las declaraciones que encajan con la directiva y su camino hasta el valor: los manejadores con la firma del evento en <code>on:</code>, las señales escribibles del tipo del control o del modelo en <code>model</code>, los booleanos en <code>if:when</code>, las listas en <code>each:of</code>, los campos del elemento (<code>item.id</code>) en <code>each:key</code>, lo asignable a la prop en una etiqueta de componente, los valores del atributo en <code>bind:type</code>, los snippets de <code>defineSnippets</code> (también <code>snippets['cell-…']</code>) en <code><render snippet></code> y las declaraciones del script antes que los globales en <code>{…}</code>. <code>model=""</code>, <code>{}</code> y <code>snippet=""</code> vacíos también se completan. Al escribir <code>bind</code> → <code>bind:</code> → <code>bind:class</code>, cada diagnóstico dice lo que falta y <code>bind:</code> se marca sobre sí mismo, no sobre la etiqueta. Véase <a href="/docs/editors#completado-de-atributos-directivas-modelos-y-snippets">Completado de atributos</a>.</p> </li> <li> <p><strong>El editor completa las props, eventos y modelos de una etiqueta de componente.</strong> En <code><AppCard |</code> el servidor de lenguaje sólo ofrecía las directivas, así que el editor completaba con lo que encontrara (sugerencias de palabras o de IA, a veces <code>item={}</code> al estilo de JSX, que Meeko no admite). Ahora ofrece lo que declara el hijo, con su tipo y su JSDoc, antes de las directivas, e inserta cada atributo con su valor y el cursor dentro, como la extensión de HTML y Vue: una prop de texto como <code>title="…"</code> (y abre sus valores si es una unión literal), una booleana como <code>disabled</code> o <code>bind:disabled="…"</code>, una que admite texto y otros tipos de las dos formas, y las demás como <code>bind:item="…"</code>; los eventos de <code>defineEmits</code> y las props <code>onX</code> como <code>on:save="…"</code>, y los modelos como <code>model="…"</code> y <code>model:open="…"</code>. Tras <code>bind:</code>, <code>on:</code> o <code>model:</code> sólo se ofrece ese canal y se reemplaza el nombre entero; <code>model:default</code> ya no aparece y <code>ref:</code> no ofrece directivas. Si el nombre ya tiene un <code>=</code> detrás, se inserta sólo el nombre, también en los atributos y eventos de un elemento. Dentro de las comillas vacías de <code>bind:</code>, <code>on:</code>, <code>model</code> o <code>if:when</code> en una etiqueta de componente no se completaba nada; ahora se completan las expresiones, también al escribir la comilla de apertura en cualquier etiqueta. Los elementos de TypeScript reemplazan exactamente el identificador que completan (<code>{ active:na }</code>). Véase <a href="/docs/editors#completado-de-atributos-directivas-modelos-y-snippets">Completado de atributos</a>.</p> </li> <li> <p><strong>Una comparación dentro de <code>{...}</code> en el texto de la plantilla compila.</strong> <code>{row.id < active.value.id}</code>, <code>{a<b}</code>, <code>{n <= 2}</code>, un genérico (<code>{identity<number>(x)}</code>) o una cadena con etiquetas (<code>{"<b>" + x}</code>) daban <code>MEEK001</code>, porque el parser HTML leía ese <code><</code> como el inicio de una etiqueta, y Prettier dejaba la plantilla sin formatear sin avisar. Ahora el contenido de cada interpolación del texto es una expresión, con las mismas reglas que ya usaba el compilador (cadenas, template literals, comentarios y regex): compilador, SSR, hidratación, editor, ESLint y Prettier la leen igual. Un <code><</code> fuera de las llaves sigue siendo HTML, y <code><</code> dentro de ellas sigue funcionando.</p> </li> <li> <p><strong>Una interpolación que combina <code><</code> con <code>&</code> ya no se trunca.</strong> Las referencias de carácter de una expresión del texto se decodificaban pasando la expresión otra vez por el parser HTML, sin enmascarar sus <code><</code>: <code>{a<b&&c}</code> compilaba sin error como <code>{a}</code> (el SSR y la hidratación pintaban <code>1</code> en lugar de <code>true</code>), y <code>{ok && "<b>"}</code> o <code>{ok && `}<b>`}</code> daban <code>MEEK020</code>. Ahora se decodifican sin interpretar marcado, igual en el compilador, <code>meeko check</code> y el editor. El significado no cambia: <code><</code>, <code>&</code> y las referencias numéricas se decodifican como en un atributo y en Vue (<code>{x && y}</code> es <code>x && y</code>; <code>{'<'}</code> pinta <code><</code>), y los diagnósticos tras una referencia (sintaxis, tipos, <code>MEEK057</code>) señalan su posición en la fuente, no la del texto decodificado. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/syntax/interpolation.md#atributos"><code>{expresión}</code></a>.</p> </li> <li> <p><strong>Un contrato de API o RPC admite composiciones simples de schemas de <code>shared/</code>.</strong> <code>output: v.array(snapshotSchema)</code> daba <code>output debe referenciar un schema importado de shared/</code> y obligaba a exportar un <code>snapshotListSchema</code>. El generador de clientes no ejecuta el handler y nombra cada schema por su módulo, así que el schema sigue viniendo de <code>shared/</code>. Ahora, una expresión de llamadas, propiedades y literales cuyos nombres son imports de <code>shared/</code> o de un paquete se copia, con esos imports, a <code>.meeko/types/contract-schemas/</code>, de donde sólo se lee su tipo. Otra expresión (una función, una variable local) se rechaza con el motivo, un ejemplo y la referencia a la documentación; los mensajes conservan el prefijo <code>… debe venir de shared/</code>. Los schemas de Socket siguen siendo exports de <code>shared/</code>, porque el navegador los importa para validar. Véase <a href="/docs/framework#schemas-p%C3%BAblicos">Schemas públicos</a>.</p> </li> <li> <p><strong>El runtime de servidor sabe dónde está el proyecto: <code>ServerRuntimeContext.root</code>.</strong> El build mueve el código de servidor a <code>.meeko/output/…</code>, así que <code>import.meta.url</code> ya no servía para leer archivos del proyecto, y <code>process.cwd()</code> sólo es la raíz cuando la CLI lanza el proceso. Ahora la fábrica de <code>defineServerRuntime</code> recibe <code>root</code>, la ruta absoluta de la raíz: en <code>meeko dev</code>, la del proyecto; en las salidas de Node, Bun y Deno (también con <code>meeko start</code>, con <code>node .meeko/output/node/index.mjs</code> desde cualquier carpeta y en el prerender), la carpeta tres niveles por encima de la salida, o la nueva variable <code>MEEKO_ROOT</code> si la salida se despliega fuera del proyecto. En Cloudflare Workers es <code>undefined</code>. Nueva opción <code>root</code> de <code>createServerApp</code>. Véase <a href="/docs/framework#runtime-de-servidor">Runtime de servidor</a>.</p> </li> <li> <p><strong><code>meeko check</code> y <code>meeko build</code> ya no escriben declaraciones fuera de <code>.meeko/</code>.</strong> Un componente de un módulo enlazado fuera de la app (<code>packages/ui/dist/app/components/Button.meeko</code> en un monorepo) recibía una declaración generada en <code><app>/packages/ui/dist/app/components/</code>, porque su ruta relativa escapaba de <code>.meeko/types</code>; con más niveles podía llegar a escribirse junto al <code>.d.meeko.ts</code> publicado. Ahora sólo los componentes del proyecto reciben declaración generada; los de un módulo externo usan la suya, como ya exigía el registro de componentes. Las carpetas creadas antes pueden borrarse.</p> </li> <li> <p><strong>El SSR y el prerender incrustan el CSS de los componentes ya procesado.</strong> El <code><style></code> en línea de cada componente llevaba el CSS antes de PostCSS (un <code>@apply</code> o un <code>@reference</code> de Tailwind, un <code>@utilities</code>), que sólo se aplicaba al cargar el JavaScript. Ahora el export <code>css</code> de un componente compilado por el plugin de Vite es el CSS procesado (módulo <code>?meeko-style=…&inline&lang.css</code>), en <code>meeko dev</code>, en el build de Node, en el prerender, en <code>static</code> y en Cloudflare, y la HMR del cliente reaplica ese mismo CSS. En el bundle de cliente de producción, donde nada lo lee, <code>css</code> sigue siendo la cadena del compilador: no añade una segunda pasada de PostCSS por componente ni una copia del CSS procesado a los chunks de página. Un host que no procesa CSS, como Vitest sin <code>css: true</code>, resuelve ese módulo como una cadena vacía: entonces <code>css</code> es la cadena del compilador, como antes de 1.8, y no queda vacío. Nueva opción <code>styleModule</code> de <code>compile()</code>. Las media queries de rango (<code>@media (width < 40rem)</code>, el <code>max-sm:</code> de Tailwind) llegan intactas al <code><style></code> en línea: sólo se escapa la secuencia <code></style</code>, que cerraría el elemento, en lugar de todo <code><</code>. CSP, deduplicación y orden no cambian.</p> </li> <li> <p><strong>El editor completa los autoimports del proyecto sin escribir un import.</strong> Al completar un export de las carpetas de autoimports (<code>app/utils</code>, <code>app/composables</code>, <code>shared/…</code>, <code>imports.appDirs</code>…) en el <code><script></code> o la plantilla de un <code>.meeko</code>, también en <code>app/app.meeko</code>, el servidor de lenguaje ofrecía el auto-import de TypeScript, que añadía <code>import { formatPrice } from "../utils/price.js"</code>; si el archivo no estaba en el programa de TypeScript (un proyecto sin <code>tsconfig.json</code>, o con un <code>include</code> que no lo cubre, donde sólo lo importa quien lo usa) no lo ofrecía, y un nombre que coincide con un global del DOM, como <code>navigation</code>, sólo aparecía como el global. Ahora se ofrece siempre que el build lo autoimporta, sin import, con su archivo (<code>app/utils/price.ts</code>) como detalle, y sustituye al global. Un componente bajo <code>server/</code> (una plantilla de email), que sólo se ejecuta en el servidor, completa además los autoimports de ámbito <code>server</code>, como los resuelven su código virtual y el grafo SSR. Los nombres autoimportados de <code>@meekojs/meeko</code> siguen importándose desde su entrada pública. Véase <a href="/docs/framework#autoimports-y-typescript">Autoimports y TypeScript</a>.</p> </li> <li> <p><strong>El editor escribe los imports relativos sin <code>.js</code>.</strong> El completado con auto-import, «Add import» y la corrección de un autoimport ambiguo escribían <code>./settings/context.js</code>; ahora escriben <code>./settings/context</code>, que aceptan Vite y la resolución <code>Bundler</code> del <code>tsconfig.json</code> de Meeko. Un proyecto con <code>moduleResolution</code> (o <code>module</code>) <code>node16</code> o <code>nodenext</code> conserva la extensión.</p> </li> <li> <p><strong><code>export default</code> no se autoimporta.</strong> <code>export default function formatPrice()</code> se registraba como el export nombrado <code>formatPrice</code>, y su uso sin import fallaba con un import que no existe (<code>TS2614</code> en el editor y en <code>meeko check</code>). Ahora sólo se autoimportan los exports nombrados, como dice la documentación: use <code>export function formatPrice()</code>.</p> </li> <li> <p><strong><code>class</code> y <code>bind:class</code> (o <code>style</code> y <code>bind:style</code>) en el mismo elemento escriben un solo atributo.</strong> El SSR escribía <code>class="card" class="ring-4"</code> y la hidratación fallaba; ahora SSR, hidratación y actualizaciones escriben <code>class="card ring-4"</code>, con las declaraciones dinámicas de <code>style</code> tras las estáticas. También en <code><component is></code> con etiqueta.</p> </li> <li> <p><strong>Una clave de <code>createContext</code> que provee un plugin ya no se pierde en <code>meeko dev</code>.</strong> La app de servidor de <code>meeko dev</code> cargaba una sola vez lo que su entrada importa estáticamente (<code>server/runtime.ts</code> y los plugins de servidor y universales), y las páginas en cada petición. Al editar el módulo de la clave (<code>app/utils/modal.ts</code>, importado por <code>app/plugins/modal.ts</code>), Vite lo evaluaba otra vez para las páginas, pero el plugin seguía publicando la clave anterior: <code>inject</code> fallaba con <code>Missing Meeko context: modal</code> hasta reiniciar <code>meeko dev</code>, y una edición del propio plugin no se aplicaba en el servidor. Ahora una edición que alcanza esos módulos sin pasar por un módulo con HMR propio (un componente) crea la app de nuevo, como el navegador recarga la página; lo que la app guarda en memoria (sesiones de <code>MemorySessionStore</code>, cachés) empieza vacío, como al añadir una página. Las ediciones de páginas, componentes y de lo que sólo ellos importan siguen siendo actualizaciones en caliente, sin crear la app.</p> </li> <li> <p><strong>El runtime de un módulo de Meeko instalado en <code>node_modules</code> se evalúa una sola vez.</strong> Un módulo publicado llegaba a Vite por dos caminos: el nombre del paquete de sus autoimports (<code>@meekojs/ui/runtime</code>) y las rutas de los archivos que registra (<code>addPlugin</code>, <code>addComponentsDir</code>…), que importan sus vecinos en relativo. En <code>meeko dev</code> el optimizador de dependencias empaquetaba aparte el primero para el navegador (<code>node_modules/.vite/deps</code>), y el build de servidor lo dejaba externo mientras empaquetaba el plugin: el mismo archivo se ejecutaba dos veces, cada copia con su clave de <code>createContext</code>, y la hidratación (en dev) o el SSR (tras <code>meeko build</code>) fallaban con <code>Missing Meeko context</code>. Ahora los paquetes instalados que contienen archivos de los módulos se compilan como código fuente, igual que un paquete enlazado: se añaden a <code>ssr.noExternal</code> y a <code>optimizeDeps.exclude</code>. Una dependencia CommonJS de uno de esos paquetes debe ir en <code>optimizeDeps.include</code> (<code>"mi-modulo > dependencia-cjs"</code>). <code>Symbol.for(...)</code> ya no hace falta como rodeo. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/reactivity/createcontext.md#notas">createContext</a>.</p> </li> <li> <p><strong>Editar una página ya no rompe en <code>meeko dev</code> la clave de <code>createContext</code> que provee un plugin.</strong> Al editar una página, un layout o un archivo de <code>app/utils</code>, <code>app/composables</code> o <code>app/plugins</code>, al añadir o quitar un componente o al cambiar la hoja global, <code>meeko dev</code> recargaba el navegador e invalidaba todos los módulos del servidor. La app de servidor conservaba sus plugins, pero las páginas volvían a evaluar el módulo de la clave, que ya no era la que el plugin había publicado: cada página respondía 500 con <code>Missing Meeko context</code> hasta reiniciar <code>meeko dev</code>. Con <code>@meekojs/ui</code> bastaba guardar una página para que todas fallaran en <code>useModalHost</code> (<code>@meekojs/ui/modal.manager</code>). Ahora esa invalidación conserva lo que la app importa al crearse (<code>server/runtime.ts</code>, los plugins de servidor y universales y sus importaciones); las páginas y lo demás se evalúan de nuevo. Además, un script de un módulo de Meeko que el navegador cargó (<code>runtime.js</code>, un composable) recarga la página, como <code>app/utils</code> del proyecto: al reconstruir un paquete enlazado, la actualización en caliente de un componente que llegaba antes de la recarga importaba una segunda copia de la clave y la hidratación fallaba con el mismo error. Los componentes de los módulos y sus hojas de estilos siguen con HMR.</p> </li> <li> <p><strong>La CLI trabaja siempre desde la raíz del proyecto.</strong> <code>meeko dev</code>, <code>build</code>, <code>start</code>, <code>preview</code>, <code>check <directorio></code>, <code>routes</code>, <code>prerender</code> y <code>check-app</code> cambian el directorio de trabajo del proceso a la raíz indicada antes de cargar <code>.env</code>, la configuración, PostCSS y Vite. Corrige que <code>@tailwindcss/postcss</code>, que detecta las fuentes desde <code>process.cwd()</code>, recorriera la carpeta de lanzamiento (con el cwd en la raíz de un disco, el disco entero) en lugar del proyecto. La ruta relativa del argumento se resuelve contra el cwd original, y el supervisor de <code>dev</code> relanza su hijo con la ruta absoluta y con las rutas de <code>--env-file</code> y <code>--env-file-if-exists</code> resueltas, escritas con <code>=</code> o separadas por un espacio (<code>node --env-file .env.local</code>). <code>check</code> y <code>routes</code> siguen imprimiendo rutas absolutas, como en 1.7. Las APIs programáticas no cambian el cwd del proceso: llámelas con el cwd en la raíz. Véase <a href="/docs/framework#postcss-y-tailwind">PostCSS y Tailwind</a>.</p> </li> <li> <p><strong>Migración de controles a UI (1.8).</strong> <code><MeekoPopover></code>, <code><MeekoSelect></code> y <code><MeekoThemeToggle></code> quedan obsoletos con aviso <code>MEEK121</code> y etiqueta tachada en el editor; funcionan en 1.x y se retiran en 2.0. Sus reemplazos son <code>UIPopover</code>, <code>UISelect</code> y <code>UIThemeToggle</code> de <code>@meekojs/ui</code> 0.2. Nueva API pública estable <code>useThemeToggle()</code> y tipos <code>ThemeToggleState</code> y <code>ThemeToggleSystem</code> en <code>@meekojs/meeko/framework</code>. El sistema de temas permanece en core. Véase <a href="/docs/migration-1.8">Actualizar de 1.7 a 1.8</a>.</p> </li> <li> <p><strong><code><MeekoPopover></code> emite cada apertura y cada cierre aunque el navegador fusione sus eventos <code>toggle</code>.</strong> Si el menú se cerraba y se reabría (con la flecha, <code>show()</code>, el modelo o <code>popovertarget</code>) antes del evento <code>toggle</code> del cierre, el navegador fusionaba los dos en uno, el menú reabierto no recibía el foco y <code>on:toggle</code> no emitía nada. Ahora <code>on:toggle</code> emite <code>false</code> y <code>true</code> en orden y el foco entra en el menú. Cambio visible: un <code>hint</code> abierto y cerrado muy rápido (un paso rápido del puntero) ahora emite <code>toggle</code> <code>true</code> y <code>false</code>, donde antes no emitía nada. <code>UIPopover</code> de <code>@meekojs/ui</code> 0.2 se comporta igual.</p> </li> <li> <p><strong>CSP de ejemplo con <code>img-src</code> y <code>data:</code>.</strong> Un documento sin icono propio lleva <code><link rel="icon" href="data:,"></code> para que el navegador no pida <code>/favicon.ico</code>; con una política <code>default-src 'self'</code> sin <code>data:</code> en <code>img-src</code>, como los ejemplos de la documentación, el navegador registraba una violación de CSP en cada página. Los ejemplos de <a href="/docs/framework#csp-con-hashes">CSP con hashes</a> incluyen ahora <code>img-src 'self' data:</code> y explican la alternativa de declarar un icono propio. El HTML no cambia.</p> </li> <li> <p><strong>Diagnóstico y observabilidad.</strong> <code>meeko doctor [directorio] [--json]</code> inspecciona versiones, resolución de paquetes, LSP disponible y artefactos generados sin ejecutar la configuración ni leer <code>.env</code>. DevTools incorpora una línea de actividad de navegación y datos, con fases, duración y origen, sin registrar URLs resueltas, claves de caché ni payloads. Véanse <a href="/docs/doctor">Doctor</a> y <a href="/docs/devtools">DevTools</a>.</p> </li> <li> <p><strong>Compilador y cliente separados por responsabilidades.</strong> El análisis de expresiones y el scoping de CSS tienen módulos propios; el navegador separa validación de payloads y transporte deferred/stream del commit transaccional. Se conservan sourcemaps, SSR, hidratación, rollback, CSRF y View Transitions.</p> </li> <li> <p><strong>Calidad del workspace.</strong> La CI prepara los paquetes antes de lint, verifica todos los paquetes públicos y aplicaciones, y prueba consumidores de tarballs fuera del workspace. Las declaraciones de componentes UI se reubican con imports portables. Nuevos benchmarks reproducibles de compilación, SSR, hidratación, bundle y LSP, con presupuestos y comparación por entorno; véanse <a href="/docs/testing">Pruebas</a> y <a href="/docs/performance">Rendimiento</a>.</p> </li> <li> <p><strong>View Transitions nativas en navegación cliente.</strong> <code>viewTransitions: true</code> en <code>meeko.config.ts</code> activa la API del navegador alrededor del commit de DOM y head, después de cargar módulos y datos. Admite historial, nombres compartidos mediante CSS y excepciones con <code>data-meeko-view-transition="false"</code> o <code>app.navigate(to, { viewTransition: false })</code>. La hidratación inicial, movimiento reducido y navegadores sin soporte conservan la navegación habitual. Las transiciones omitidas no bloquean la navegación ni permiten commits de rutas abortadas. Véase <a href="/docs/framework#view-transitions-nativas">View Transitions nativas</a>.</p> </li> <li> <p><strong>IP del cliente tras Cloudflare Tunnel: <code>MEEKO_TRUST_PROXY=cloudflare</code>.</strong> Tras Cloudflare → <code>cloudflared</code> → Traefik sin <code>trustedIPs</code>, <code>X-Forwarded-For</code> sólo traía la IP de <code>cloudflared</code>, así que con <code>MEEKO_TRUST_PROXY=1</code> todos los visitantes compartían el contador de <code>rateLimit</code>. El valor <code>cloudflare</code> hace que <code>context.clientAddress</code>, <code>clientAddress(request)</code> y <code>rateLimit</code> lean <code>CF-Connecting-IP</code> (o <code>True-Client-IP</code> si falta) sólo cuando la conexión y cada salto de <code>X-Forwarded-For</code> vienen de las redes de la nueva <code>MEEKO_TRUSTED_PROXIES</code> (CIDR o IP; por defecto, loopback, RFC 1918 y <code>fc00::/7</code>). Una conexión de fuera, un salto público (alguien que llega directamente a Traefik con la cabecera inventada) o un valor que no es una única IP devuelven la IP de la conexión o la de ese salto. Un <code>MEEKO_TRUSTED_PROXIES</code> no válido detiene el arranque. En Workers no cambia nada. Véase <a href="/docs/framework#cloudflare-tunnel-y-traefik">Cloudflare Tunnel y Traefik</a>.</p> </li> </ul> <h3 id="seguridad">Seguridad<a class="heading-anchor" href="#seguridad" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Toda mutación comprueba <code>Origin</code> por defecto, también sin sesión.</strong> Hasta <code>1.7</code>, una petición <code>POST</code>, <code>PUT</code>, <code>PATCH</code> o <code>DELETE</code> de <code>defineApiRoute</code>, o una llamada de <code>defineRpc</code>, sin cookie de sesión sólo comprobaba <code>Origin</code> si la ruta declaraba <code>origin: "required"</code>, así que otra web podía ejecutar una ruta anónima que aceptara un formulario o JSON enviado como <code>text/plain</code>, sin <em>preflight</em> de CORS. Ahora responde <code>403 INVALID_ORIGIN</code> si su <code>Origin</code> falta, es <code>null</code> o no es el de la aplicación (<code>publicOrigin</code> o <code>MEEKO_PUBLIC_ORIGIN</code>) ni uno de <code>SessionManager.allowedOrigins</code>, la misma regla que con sesión; <code>Sec-Fetch-Site</code> y <code>Referer</code> no sustituyen a <code>Origin</code>. <code>origin: "required"</code> equivale al valor por defecto. <code>origin: "none"</code> es la salida por ruta para webhooks y APIs públicas (<strong>insegura</strong>: úsela con una firma o un token): desactiva la comprobación en las peticiones sin sesión, también en un formulario nativo (un webhook <code>application/x-www-form-urlencoded</code> como los de Twilio, que hasta <code>1.7</code> recibía <code>403</code>), mientras que una con sesión sigue exigiendo <code>Origin</code> y el token CSRF. <code>createLocalCalls</code> envía ahora el origen de la aplicación como <code>Origin</code>, como los clientes <code>api.*</code> y <code>rpc.*</code> del SSR, en lugar de reenviar el de la petición original, así que una mutación local desde una página pedida con <code>GET</code> funciona; con sesión sigue necesitando el token CSRF. Los navegadores ya envían <code>Origin</code> y los clientes <code>api.*</code> y <code>rpc.*</code> del SSR envían el de la petición, así que las aplicaciones web no cambian; un webhook, un script o una app nativa sin <code>Origin</code> recibe <code>403</code>. Es un cambio incompatible aprobado como corrección de seguridad; véase <a href="/docs/migration-1.8#origin-en-todas-las-mutaciones">Actualizar de 1.7 a 1.8</a>.</li> </ul> <h2 id="171---2026-10-29">[1.7.1] - 2026-10-29<a class="heading-anchor" href="#171---2026-10-29" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <h3 id="correcciones">Correcciones<a class="heading-anchor" href="#correcciones" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>meeko dev</code> dice cuándo no publica valores en vivo.</strong> Con <code>MEEKO_EDITOR_BRIDGE=0</code> (también en el <code>.env</code>), <code>meeko dev</code> no escribía el descriptor del puente y no avisaba, y la extensión de VS Code dejaba «Meeko live» desconectado sin explicar por qué. Ahora escribe tras la URL, en la salida de errores, <code>Valores en vivo del editor desactivados (MEEKO_EDITOR_BRIDGE=0)</code>, o <code>(meeko dev escucha en <dirección>, fuera de loopback)</code> cuando escucha en una dirección concreta fuera de loopback, y lo anota en su registro, <code>.meeko/dev/server.json</code>, con <code>editorBridge: false</code> y el motivo en <code>editorBridgeReason</code> (también si el puente falla al arrancar). La extensión 1.7.1 lee ese registro y muestra «Meeko live: desactivado en meeko dev» con el motivo. Nuevo tipo <code>DevelopmentServerRecord</code> en el contrato del puente. Véase <a href="/docs/editors#valores-en-vivo">Valores en vivo</a>.</li> <li><strong>El servidor de lenguaje ya no abre ventanas de consola en Windows.</strong> Al editar un <code>.meeko</code>, el editor abría una ventana de consola cada pocos segundos: la comprobación de los contratos de páginas y la del proyecto (<code>framework/page-contracts-check.ts</code> y las dos llamadas de <code>framework/check-project.ts</code>) lanzaban <code>typescript/bin/tsc</code>, el lanzador en JavaScript, con <code>node</code>, y ese lanzador abre <code>tsc.exe</code> sin <code>windowsHide</code>. Ahora las cuatro llamadas al compilador de TypeScript, también la de <code>meeko check</code>, pasan por un único helper que en Windows ejecuta <code>tsc.exe</code> directamente, oculto, y en los demás sistemas sigue usando el lanzador con Node. Un test falla si otro archivo vuelve a lanzar <code>bin/tsc</code>.</li> <li><strong><code>model</code> en un checkbox acepta <code>boolean | undefined</code>.</strong> El campo de una clave opcional con valor por defecto, como <code>consent: v.optional(v.boolean(), false)</code>, tiene el tipo de la entrada del schema, <code>boolean | undefined</code>, y <code><input type="checkbox" model="form.fields.consent"></code> (o <code>model="props.field.value"</code> con un <code>FormField<boolean | undefined></code>) daba <code>TS2322</code> en <code>meeko check</code>, <code>meeko build</code> y el editor. Ahora la señal de un checkbox puede ser <code>Signal<boolean></code> o <code>Signal<boolean | undefined></code>: <code>undefined</code> se pinta desmarcado, en el SSR y en el navegador, y <code>change</code> escribe siempre un booleano. El campo de <code>useForm</code> sigue teniendo el tipo de la entrada (<code>FormField<boolean | undefined></code>): un componente de campo para checkbox debe declarar ese tipo, porque tiparlo con la salida rompería los schemas cuya entrada admite <code>undefined</code> hasta que el usuario elige. Véase <a href="https://github.com/meekojs/meeko/blob/main/docs/reference/composables/useform.md#un-checkbox-opcional-con-valor-por-defecto">Un checkbox opcional con valor por defecto</a>.</li> </ul> <h3 id="cambios">Cambios<a class="heading-anchor" href="#cambios" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>meeko dev</code> muestra <code>localhost</code> en vez de la IP.</strong> <code>meeko dev</code>, <code>meeko start</code>, <code>meeko preview</code> y las salidas de Node, Bun y Deno escriben <code>http://localhost:4173</code> cuando escuchan en loopback (<code>127.0.0.1</code>, <code>::1</code>) o en todas las interfaces (<code>0.0.0.0</code>, <code>::</code>); hasta ahora escribían <code>http://127.0.0.1:4173</code>. Sólo cambia el texto: la dirección de escucha sigue siendo <code>127.0.0.1</code> por defecto, <code>serveNode(...).url</code> y <code>serveDeno(...).url</code> no cambian y, sin <code>MEEKO_PUBLIC_ORIGIN</code>, Socket sigue tomando la dirección de escucha como origen y acepta los otros nombres de loopback, así que una página abierta en <code>localhost</code> conecta igual. Con <code>MEEKO_HOST=0.0.0.0</code> (o <code>::</code>, o <code>server.host</code>) se añade una línea <code>Red: http://<IP>:4173</code> por cada dirección de las interfaces de red, al estilo de Vite; la salida de Deno sólo las lista con <code>--allow-sys=networkInterfaces</code> y nunca pide el permiso. Un host concreto se muestra tal cual. La primera línea sigue siendo la URL local, sola: un script que buscaba <code>http://127.0.0.1:<puerto></code> en la salida debe buscar <code>http://localhost:<puerto></code> o leer esa primera línea. <code>meeko dev</code> con <code>MEEKO_HOST=::</code> toma ahora <code>[::1]</code> como origen de Socket, en lugar del <code>[::]</code> con el que rechazaba las páginas de loopback. El <code>server.mjs</code> que crea <code>meeko init</code> también escribe <code>http://localhost:4173</code> (y sigue escuchando sólo en <code>127.0.0.1</code>), igual que su README. Véase <a href="/docs/framework#url-que-se-muestra">URL que se muestra</a>.</li> </ul> <h3 id="documentación">Documentación<a class="heading-anchor" href="#documentaci%C3%B3n" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>El campo <code>return</code> de un formulario nativo, con la <code>/</code> sin codificar.</strong> Se comprobó que <code>return=/contacto</code> (como lo envía <code>curl -d</code>), <code>return=%2Fcontacto</code> (como lo envía el navegador), el mismo campo en <code>multipart/form-data</code> y una URL absoluta del mismo origen vuelven todos a <code>/contacto</code>, y que <code>//</code>, <code>\</code>, los esquemas y los segmentos de punto siguen volviendo a <code>/</code>; un test lo fija. El <code>location: /</code> que se veía al probarlo con <code>curl</code> desde Git Bash en Windows no venía de Meeko: MSYS convierte el argumento <code>return=/contacto</code> en <code>return=C:/Program Files/Git/contacto</code>, un esquema <code>c:</code>, que se rechaza como debe. <a href="/docs/framework#formularios-sin-javascript-form">Formularios sin JavaScript</a> lo explica, con <code>return=%2Fcontacto</code> o <code>MSYS_NO_PATHCONV=1</code> como alternativas.</li> </ul> <h2 id="170---2026-10-29">[1.7.0] - 2026-10-29<a class="heading-anchor" href="#170---2026-10-29" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.6</code>, con lo que hay que revisar en cada uno, y cómo adoptar lo nuevo se recogen en <a href="/docs/migration-1.7">Actualizar de 1.6 a 1.7</a>.</p> <h3 id="añadido">Añadido<a class="heading-anchor" href="#a%C3%B1adido" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>CSP y cabeceras en los adaptadores con servidor.</strong> <code>server.contentSecurityPolicy</code> y <code>server.headers</code>, que hasta ahora sólo tenía el adaptador <code>static</code>, existen también con <code>adapter: "node"</code>, <code>"bun"</code>, <code>"deno"</code> y <code>"cloudflare"</code> (tipo <code>ServerResponseConfig</code>). En producción, la aplicación completa la política de cada respuesta: una página prerenderizada lleva los hashes de su índice (<code>scriptHashes</code> y <code>styleHashes</code>, que ahora también llegan en <code>PrerenderedPage</code>) y se sigue sirviendo desde su archivo; una página SSR, <code>"stream"</code>, de error o 404 lleva un nonce nuevo por respuesta en <code>script-src</code>; una página SSR con <code>cache</code>, los hashes del código en línea que escribe Meeko; y el JSON de API, RPC y navegación (todo <code>/api/</code>, también un endpoint con <code>contentType: "response"</code>), <code>default-src 'none'; frame-ancestors 'none'</code>. Los hashes sólo cubren lo que Meeko escribe fuera de la página (el <code><head></code>, el payload, la entrada y <code>document.bodyEnd</code>): un <code><script></code> o un <code><style></code> dentro de <code>#app</code> o de un teleport, que puede llegar con <code>html="…"</code> o con contenido de usuario, queda bloqueado como con el nonce. El nonce y los hashes van a <code>script-src-elem</code> y <code>style-src-elem</code> si la política las tiene. Meeko nunca añade un nonce ni un hash a una directiva con <code>'unsafe-inline'</code> (por ejemplo, el <code>style-src</code> que necesitan los atributos <code>style</code> de Shiki), salvo que tenga <code>'strict-dynamic'</code>, con el que el navegador ya ignora <code>'unsafe-inline'</code>. La página que muestra el resultado de un formulario nativo lleva el nonce de su respuesta. <code>server.headers</code> admite, además de las cabeceras globales, patrones de ruta (<code>"/admin/*": { "X-Robots-Tag": "noindex" }</code>, tipo <code>ServerHeaders</code>), y nunca sustituye una cabecera que la respuesta ya trae. Los Workers lo aplican igual, con Web Crypto; sin <code>contentSecurityPolicy</code>, el build de Cloudflare deja fuera del Worker el analizador HTML de los hashes (<code>parse5</code>), unos 240 KB. El manifiesto de la aplicación lleva los valores en <code>AppManifest.contentSecurityPolicy</code> y <code>AppManifest.headers</code>. Véase <a href="/docs/framework#csp-y-cabeceras-en-los-adaptadores-con-servidor">CSP y cabeceras en los adaptadores con servidor</a>.</li> <li><strong>Caché de páginas SSR.</strong> <code>definePage({ cache: { etag, maxAge, staleWhileRevalidate, memory } })</code> (tipos <code>PageCache</code>, <code>PageCacheContext</code> y <code>PageMemoryCache</code>). <code>etag(ctx)</code> se calcula antes del loader con los <code>params</code> y <code>search</code> validados; Meeko lo combina con el tema, el build (<code>AppManifest.buildId</code>, nuevo en cada <code>meeko build</code>) y el tipo de respuesta en un <code>ETag</code> débil y responde <code>304</code> sin loader ni render, para el documento y para el payload de navegación (<code>application/meeko+json</code> y el <code>ndjson</code> de <code>"stream"</code>), con <code>Vary: Accept, Cookie</code>. <code>memory</code> guarda el HTML y el payload en una LRU por ruta y proceso (1000 entradas y 32 MiB por defecto) que se invalida al cambiar el <code>ETag</code>. El middleware de ruta, isomórfico y de servidor, se ejecuta siempre antes del <code>304</code>. Nunca se cachea una petición con la cookie de sesión o con <code>Authorization</code>, ni una respuesta que pone una cookie (en desarrollo, con un aviso); <code>"stream"</code> sólo usa el <code>ETag</code>; la caché sólo se aplica en producción. En una ruta con schema <code>search</code>, la clave de <code>memory</code> usa el <code>search</code> validado, así que un parámetro no declarado (<code>?utm_source=…</code>) no llena la LRU. Véase <a href="/docs/framework#cach%C3%A9-de-p%C3%A1ginas-ssr">Caché de páginas SSR</a>.</li> <li><strong>Formularios sin JavaScript contra la API: <code>form</code>.</strong> <code>defineApiRoute({ body, response, form: true, handler })</code> acepta, además de JSON, un <code><form method="post"></code> nativo (<code>application/x-www-form-urlencoded</code> y <code>multipart/form-data</code>), validado con el mismo schema de <code>body</code>. Un nombre repetido o terminado en <code>[]</code> es una lista; los campos llegan como texto y, si el schema rechaza el de algunos, se validan una vez más con su lectura tipada (<code>""</code> → <code>undefined</code>, <code>"on"</code>/<code>"true"</code> → <code>true</code>, <code>"false"</code> → <code>false</code>, un número decimal → <code>number</code>), así que <code>v.number()</code> y <code>v.boolean()</code> sirven sin conversiones propias; un schema asíncrono se ejecuta una sola vez, sin ese segundo intento. Un envío correcto responde <code>303 See Other</code> a <code>form.redirect(result, context)</code>, al campo <code>return</code> o a la página de <code>Referer</code>; un error (de validación, un <code>ApiError</code>, <code>401</code>, <code>429</code>…) vuelve con <code>303</code> a esa página. La ruta nunca sale del sitio: <code>//</code>, <code>\</code>, un esquema o segmentos de punto se sustituyen por <code>/</code>, con las comprobaciones de <code>POST /_meeko/theme</code>. El resultado viaja en una cookie de un solo uso (<code>__Host-meeko-form</code>, <code>HttpOnly</code>, 60 s), que la página lee y borra mientras se renderiza (también si está prerenderizada): el código, el estado, los <code>issues</code> y sólo los valores de los campos que lista <code>form.echo</code> (por defecto ninguno; nunca archivos ni nombres como <code>password</code> o <code>token</code>). Todo envío nativo exige un <code>Origin</code> permitido y, con sesión, el token CSRF en el campo <code>_csrf</code>; esos dos fallos responden <code>403</code> sin redirección. <code>rateLimit</code> se cuenta antes de leer el cuerpo. <code>form.maxBytes</code> cambia el límite de 1 MiB, <code>form.files: true</code> admite archivos, que el schema recibe como <code>File</code> (sin él, <code>400 FILES_NOT_ALLOWED</code>), y <code>form.echo</code> lista los campos cuyo valor vuelve a la página tras un error. Un endpoint sin <code>form</code> sigue respondiendo <code>415</code> a un formulario. Nuevo tipo <code>ApiFormOptions</code> en <code>@meekojs/meeko/server</code>. Véase <a href="/docs/framework#formularios-sin-javascript-form">Formularios sin JavaScript</a>.</li> <li><strong><code>useForm({ action })</code> pinta el resultado del envío nativo.</strong> Con <code>action: "/api/feedback"</code>, el SSR de la página a la que vuelve el navegador muestra <code>errors</code>, <code>error</code> y <code>failure</code> de un error (con los valores de <code>form.echo</code> en sus campos), o <code>submitted</code> tras un envío correcto, y la hidratación conserva lo mismo; con JavaScript, <code>form.submit</code> sigue enviando JSON con la misma definición. <code>form.csrfToken</code> da el token de la sesión para el campo oculto <code>_csrf</code>.</li> <li><strong><code>debounceMs</code> y <code>enabled</code> en <code>useApi</code> y <code>useRpcQuery</code>.</strong> <code>{ debounceMs: 200 }</code> espera a que la entrada se quede quieta y hace una sola petición por ráfaga, cancelando la que estaba en curso; durante la espera <code>pending</code> ya vale <code>true</code> y <code>data</code> conserva el resultado anterior (salvo con <code>keepPrevious: false</code>). <code>{ enabled: () => q.value.length >= 2 }</code> (también un booleano o una señal) no pide nada mientras vale <code>false</code>, cancela la petición en curso, deja <code>pending</code> en <code>false</code> y conserva <code>data</code>. En el SSR, un recurso con <code>await</code> se pide enseguida, sin espera; uno desactivado no puede esperarse. Véase <a href="/docs/framework#b%C3%BAsqueda-mientras-se-escribe-debouncems-y-enabled">Búsqueda mientras se escribe</a>.</li> <li><strong><code>rateLimit</code> en SQL, sin Redis.</strong> <code>SqlSessionDriver</code> gana el método opcional <code>rateLimit(key, windowMs, now)</code>, que cuenta una petición con una sola sentencia atómica y devuelve la fila <code>{ count, windowEndsAt }</code> (tipo <code>SqlRateLimitRow</code>). Si el driver lo implementa, <code>SqlSessionStore.rateLimit</code> delega en él y los límites de <code>rateLimit</code> de API y RPC se comparten entre todas las instancias, con la misma semántica que Redis y la memoria: ventana fija, reinicio al terminar y <code>429</code> con <code>Retry-After</code> (los segundos que faltan, como mínimo 1); si la base de datos falla, la petición se rechaza con <code>500</code>. <code>key</code> son los 32 bytes del SHA-256 de la clave del contador, que ya resume la ruta y el sujeto, así que la tabla nunca guarda una IP en claro. <a href="/docs/framework#rate-limit-en-sql">framework.md</a> documenta la tabla <code>UNLOGGED</code> de referencia para PostgreSQL (<code>key bytea</code> como clave primaria, <code>window_ends_at</code> y <code>count</code>) y su <code>INSERT … ON CONFLICT DO UPDATE … RETURNING</code>. Sin <code>rateLimit</code> en el driver todo sigue igual: contadores en la memoria de cada instancia y un aviso en producción, que ahora indica cómo compartirlos.</li> <li><strong><code>D1SessionDriver</code> cuenta <code>rateLimit</code> en D1.</strong> Con la opción <code>rateLimitTable</code>, el driver de Cloudflare D1 implementa <code>rateLimit</code> sobre esa tabla, cuyo esquema devuelve <code>D1SessionDriver.rateLimitSchema(table?)</code> (por defecto, <code>meeko_rate_limits</code>), y <code>deleteExpired()</code> borra también los contadores cuya ventana terminó. Es opcional porque necesita una migración: sin la opción, el driver no cambia.</li> <li><strong><code>clientAddress(request, env?)</code> en <code>@meekojs/meeko/server</code>.</strong> Da la IP del cliente donde no hay <code>RequestContext</code>, como en <code>defineServerMiddleware</code> o en un handler de <code>addServerHandler</code>, con la misma política que <code>context.clientAddress</code> y <code>rateLimit</code>: la IP de la conexión (el socket en Node, Bun y Deno; <code>CF-Connecting-IP</code> en Workers) o, con <code>MEEKO_TRUST_PROXY</code>, la entrada de <code>X-Forwarded-For</code> que añadió el proxy de confianza más externo. Sin <code>env</code>, aplica el entorno de la aplicación que atiende la petición, también en la petición nueva que un middleware pasa a <code>next()</code>; así ya no hace falta leer <code>X-Forwarded-For</code> a mano, que cualquier cliente puede falsificar. Véase <a href="/docs/framework#ip-del-cliente-tras-un-proxy">IP del cliente tras un proxy</a>.</li> <li><strong>Rutas dinámicas con SSR en el sitemap: <code>sitemapEntries</code>.</strong> <code>definePage({ sitemapEntries })</code> declara las URL de la ruta en <code>sitemap.xml</code>: una lista de <code>{ params, lastmod?, changefreq?, priority? }</code> (tipo <code>SitemapEntry</code>) o una función, síncrona o asíncrona, que <code>meeko build</code> evalúa una vez después de prerenderizar, en el servidor de Node intermedio, con <code>SitemapEntriesContext</code> (<code>env</code>, el <code>process.env</code> del build, y <code>prerendering: true</code>). Hasta ahora el sitemap sólo conocía las páginas prerenderizadas y las rutas sin parámetros, así que una ruta <code>/docs/[slug]</code> con SSR no aparecía. Cada <code><url></code> puede llevar <code><lastmod></code> (un <code>Date</code> o un texto W3C Datetime), <code><changefreq></code> y <code><priority></code>, validados en el build. En una ruta <code>render: "prerender"</code>, <code>sitemapEntries</code> sólo completa sus páginas prerenderizadas con esos campos, y una entrada sin página detiene el build; <code>sitemap.exclude</code> y <code>noindex</code> siguen ganando. Una página <code>render: "client"</code> no lo admite (error de tipos y de descubrimiento). Vale para todos los adaptadores, Node y <code>static</code> incluidos. Véase <a href="/docs/framework#rutas-din%C3%A1micas-en-el-sitemap-sitemapentries">Rutas dinámicas en el sitemap</a>.</li> <li><strong><code>context.services</code> tipado sin conversiones.</strong> <code>meeko check</code>, <code>meeko dev</code> y el editor generan <code>.meeko/types/services.d.ts</code>, que infiere el tipo de <code>services</code> del export por defecto de <code>server/runtime.ts</code> (el objeto compartido, o lo que devuelve la función por petición) y amplía la nueva interfaz <code>GeneratedServices</code> de <code>@meekojs/meeko/server</code>. <code>RequestContext.services</code> y <code>services</code> de <code>ServerRouteMiddlewareContext</code> pasan a ser <code>AppServices</code> cuando no se indica otro tipo, así que <code>context.services.db</code> compila sin <code>as unknown as MisServicios</code> en <code>usePage().context</code>, API, RPC, Socket y el middleware de ruta de servidor. Un tipo escrito (<code>RequestContext<MisServicios></code>) o <code>any</code> siguen ganando; sin runtime en TypeScript o sin <code>services</code>, el tipo sigue siendo <code>unknown</code>. <code>RequestContext</code> compara por su tipo de servicios, así que el contexto de un test con servicios falsos (<code>createRequestContext(request, { db: falso }, session)</code>) se sigue aceptando en una ruta sin tipo escrito. Un runtime que usa <code>defineServerRuntime</code> autoimportado también se infiere en el editor: la declaración lee una copia con los autoimports escritos (<code>.meeko/types/server-runtime.ts</code>, con <code>@ts-nocheck</code>). Nuevos tipos: <code>AppServices</code>, <code>GeneratedServices</code> y <code>ServerRuntimeServices</code>. Véase <a href="/docs/framework#tipos-de-los-servicios">Tipos de los servicios</a>.</li> </ul> <h3 id="cambios-1">Cambios<a class="heading-anchor" href="#cambios-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Con <code>server.contentSecurityPolicy</code>, una página prerenderizada se sirve desde su archivo aunque el host pase <code>DocumentOptions.nonce</code>; sin ella, como antes, un nonce del host la renderiza con SSR.</li> <li>Toda respuesta de <code>createServerApp</code> con <code>Set-Cookie</code> y un <code>Cache-Control</code> <code>public</code> o con <code>s-maxage</code> (también si lo añade <code>server.headers</code>) sale como <code>private, no-store</code> y sin <code>ETag</code>, para que ninguna caché compartida guarde la cookie.</li> <li><strong>Una conversión directa de <code>context.services</code> a un tipo incompatible es un error de tipos.</strong> Con <code>server/runtime.ts</code> en TypeScript, <code>context.services as Otro</code> compara ahora con el tipo inferido en lugar de con <code>unknown</code>. <code>as unknown as Otro</code> sigue compilando; lo recomendable es quitar la conversión.</li> <li><strong><code>useSocketClient</code> (y <code>useSocket</code>, <code>useSocketChannel</code>) no lanza en SSR.</strong> Sin <code>await</code>, en el render del servidor devuelve un cliente inerte que se queda en <code>"connecting"</code>, cuyo <code>on</code> no registra nada y cuyo <code>emit</code> rechaza, como prometía su JSDoc; hasta ahora lanzaba <code>useSocketClient() is only available in the browser</code> y el render fallaba. El navegador abre la conexión al montar, como antes. La comprobación de <code>window</code> sigue funcionando y ya no hace falta.</li> <li><strong>Avisos de configuración.</strong> Una clave de <code>meeko.config.ts</code> que ni Meeko ni un módulo (<code>meta.configKey</code>) leen da un aviso una vez por configuración, con la clave más parecida (<code>¿Quisiste decir "sitemap"?</code>); antes se ignoraba en silencio. Es un aviso y no un error porque esa configuración cargaba en <code>1.6</code>, y los tipos de <code>defineMeekoConfig</code> no la rechazan, porque las claves de los módulos que no aumentan <code>MeekoConfig</code> son válidas. Una aplicación de producción con canales de Socket y sin <code>socket.pubsub</code> avisa una vez de que usa <code>LocalSocketPubSub</code>, como ya hacía el contador en memoria de <code>rateLimit</code>; <code>new LocalSocketPubSub()</code> explícito lo quita.</li> <li><strong>Mensajes en español.</strong> La validación de <code>meeko.config.ts</code> y del tema (<code>server.port debe ser un entero entre 0 y 65535</code>, <code>campo desconocido</code>), <code>meeko init</code> y <code>meeko init-framework</code> (<code>El destino no está vacío</code>), la contraseña vacía o demasiado larga de <code>meeko auth hash</code> por tubería y el build que falta en <code>meeko prerender</code>. El servidor de lenguaje reconoce el nuevo <code>No se puede cargar <archivo></code> de la configuración.</li> <li><strong><code>meeko <comando> --help</code></strong> (y <code>meeko help <comando></code>) imprime la ayuda de ese comando; <code>meeko --help</code> lista los cuatro transportes de <code>meeko lsp</code>. <strong><code>meeko routes</code></strong> prepara <code>.meeko/</code> como <code>meeko check</code> (entradas, contratos de páginas, <code>services.d.ts</code> y <code>tsconfig.*.json</code>), así que <code>tsc -p .meeko/tsconfig.server.json</code> funciona después. <strong><code>buildProject</code></strong> genera esos archivos en un proyecto limpio en lugar de fallar con <code>Tsconfig not found</code>. Un segundo <strong><code>meeko dev</code></strong> del mismo proyecto avisa al arrancar de que el primero sigue en marcha (<code>.meeko/dev/server.json</code>), sin sustituir ni borrar su registro.</li> <li><strong>Nuevos autoimports: <code>useNavigation</code>, <code>createRoot</code> y <code>defer</code>.</strong> <code>useNavigation</code> (de <code>@meekojs/meeko/framework</code>) y <code>createRoot</code> (de <code>@meekojs/meeko</code>) se autoimportan como <code>useRoute</code> y <code>effect</code>; <code>defer</code>, en el código de servidor: <code><script server></code> (en el nivel superior y dentro de las opciones de ruta), los sidecars <code>*.route.ts</code>, <code>server/</code> y los <code>*.server.ts</code>. Antes los tres daban <code>TS2304</code>/<code>TS2552</code> sin un import. Un export propio con uno de esos nombres tiene prioridad, como con los demás autoimports añadidos después de <code>1.0</code>. Con <code>defer</code> autoimportado, un <code>export const x = defer(...)</code> llega a la plantilla como <code>Deferred<T></code> con su tipo exacto: <code>x.value.value</code> deja de compilar y los elementos de una lista en <code>x.value</code> ya no son <code>unknown</code>. <code>redirect</code> y <code>notFound</code> siguen sin autoimportarse en <code>app/middleware/*.server.ts</code>, porque sus tipos serían globales en todo el proyecto <code>server</code>, también en las API, donde fallarían con <code>MEEK073</code>.</li> <li><strong>Las props son de sólo lectura en los tipos.</strong> El script ve <code>defineProps<T>()</code> como <code>Readonly<T></code>, así que <code>props.x = …</code> es el error <code>TS2540</code> en <code>meeko check</code>, <code>meeko build</code> y el editor; en ejecución ya lanzaba un <code>TypeError</code>. Leerlas, pasarlas a una función o expandirlas no cambia.</li> <li><strong>Asignar <code>computed(...).value</code> lanza <code>TypeError</code>.</strong> Hasta ahora, en JavaScript sin tipos, la escritura sustituía el valor hasta el siguiente recálculo; ahora lanza siempre, como una escritura en las props. TypeScript ya la rechazaba (<code>ReadonlySignal</code>).</li> <li><strong><code>PageInputError.name</code> es <code>"PageInputError"</code></strong>, como el de <code>ClientError</code> y <code>ApiError</code>; antes era <code>"Error"</code>. <code>instanceof</code> y <code>code</code> no cambian.</li> <li><strong><code>useHead</code> rechaza en los tipos los manejadores de eventos.</strong> Un <code>onclick</code>, <code>onload</code> u otro manejador de los eventos del DOM en <code>htmlAttrs</code> o <code>bodyAttrs</code> es un error de tipos; en ejecución ya lanzaba un <code>TypeError</code>. Un <code>Record<string, string></code> sigue valiendo, y cualquier otro <code>on*</code> sigue fallando en ejecución.</li> <li><strong>Aviso <code>MEEK119</code>.</strong> Un atributo <code>each:*</code> o <code>if:*</code> que no lee ninguna directiva del nodo (<code>each:by</code> junto a <code>each:of</code>, <code>if:else</code> junto a <code>if:when</code>) se escribía en silencio como atributo HTML literal; ahora <code>meeko check</code>, <code>meeko build</code> y el editor lo avisan. El HTML generado no cambia.</li> </ul> <h3 id="seguridad-1">Seguridad<a class="heading-anchor" href="#seguridad-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Hashes de CSP sólo del código que escribe Meeko.</strong> Desde <code>1.3</code>, <code>scriptHashes</code> y <code>styleHashes</code> del índice de prerender y la CSP del adaptador <code>static</code> se calculaban sobre el documento entero, así que un <code><script></code> o un <code><style></code> que llegara dentro de la página (contenido de un CMS leído en el build, <code>html="…"</code> sin sanear) quedaba autorizado. Ahora sólo cuentan los de fuera de <code>#app</code> y de los teleports; un <code>.html</code> propio de <code>public/</code> se sigue leyendo entero. <code>inlineScriptHashes</code> e <code>inlineStyleHashes</code> siguen leyendo todo el documento que reciben.</li> </ul> <h3 id="correcciones-1">Correcciones<a class="heading-anchor" href="#correcciones-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>contentSecurityPolicy()</code> respeta <code>script-src-elem</code>.</strong> Los hashes de scripts iban siempre a <code>script-src</code>, que el navegador no consulta para los elementos <code><script></code> si la política tiene <code>script-src-elem</code>; ahora van a esa directiva, como los de estilos a <code>style-src-elem</code> desde <code>1.4</code>.</li> <li><strong><code>meeko check</code> acepta <code>export default definePage(...)</code>.</strong> En <code><script server></code> sin código de nivel superior y en un sidecar <code>*.route.ts</code>, la forma documentada que el build y el runtime ya leían (<code>route ?? default</code>) hacía fallar la comprobación de contratos con <code>has no exported member 'route'</code>. Ahora <code>meeko check</code> y el editor comparan su loader con las props de la página, como con <code>export const route</code>.</li> <li><strong><code>MEEK073</code> en las funciones que Meeko llama al calcular el head.</strong> <code>usePage()</code>, <code>redirect()</code> o <code>notFound()</code> dentro de <code>export const head = () => ...</code> o de la función de <code>useHead(() => ...)</code> y <code>useSeoMeta(() => ...)</code> en <code><script server></code> fallaban en cada petición con <code>500</code>, porque esas funciones se ejecutan cuando el código de nivel superior ya terminó; ahora son el error <code>MEEK073</code> en <code>meeko check</code>, <code>meeko build</code> y el editor. Un helper al que el código de nivel superior llama mientras se ejecuta (también <code>async</code>) sigue pudiendo usarlas.</li> <li><strong>Una ruta dinámica <code>render: "prerender"</code> sin <code>prerenderEntries</code> detiene el descubrimiento.</strong> Hasta ahora sólo fallaba <code>meeko build</code>; <code>meeko check</code> y <code>meeko dev</code> dan el mismo error (<code>Dynamic prerender route /posts/[id] requires prerenderEntries</code>) con el archivo de las opciones. Unas opciones con un spread que puede llevar <code>prerenderEntries</code> se dejan al build, que las lee al ejecutarlas.</li> <li><strong><code>handleProcessErrors</code> se instala una vez por aplicación.</strong> Junto a <code>serveNode</code>/<code>serveDeno</code> con <code>handleSignals</code>, una segunda llamada añadía otros listeners: cada fallo se informaba dos veces y dos cierres competían. Ahora no añade nada y devuelve su propia función de retirada; los listeners se retiran con la última. Si sus opciones (<code>onError</code>, <code>close</code>, <code>shutdownTimeout</code>) son distintas de las de la primera, se ignoran con un aviso.</li> <li><strong><code>405</code> con <code>Allow: POST</code> en un RPC.</strong> <code>GET</code> (u otro método) a <code>/_meeko/rpc/...</code> en <code>createServerDispatcher</code> y <code>dispatchRpc</code> respondía <code>405</code> sin <code>Allow</code>, aunque su JSDoc lo prometía y la API ya lo ponía.</li> <li><strong>La CLI no da por buena una ruta que no existe.</strong> <code>meeko check-app ./no-existe</code> imprimía <code>OK</code> y salía con <code>0</code>; ahora, como <code>routes</code>, <code>prerender</code>, <code>check</code>, <code>dev</code>, <code>build</code>, <code>start</code> y <code>preview</code>, falla con <code>No existe el directorio …</code>. Un componente que falta da <code>No existe el archivo …</code> en lugar del <code>ENOENT</code> de Node.</li> <li><strong><code>meeko init</code> e <code>init-framework</code> aceptan los mismos destinos.</strong> Una carpeta con sólo <code>.git</code> se rechazaba en los dos, e <code>init-framework</code> no aceptaba <code>bun.lock</code> ni <code>bun.lockb</code>.</li> <li><strong><code>meeko types</code>, <code>compile</code> y <code>check <componente></code> usan las mayúsculas del archivo en disco.</strong> En Windows y macOS, <code>meeko types src/app.meeko</code> con el archivo <code>App.meeko</code> escribía <code>app.d.meeko.ts</code>.</li> <li><strong><code>meeko check componente.meeko</code> comprueba lo mismo que el del proyecto.</strong> Un componente comprobado solo da <code>MEEK044</code> (un <code><script server></code> fuera de una página), <code>MEEK100</code> (<code>generic</code> en una página o un layout) y los errores de tipos de su <code><script server></code>, también de las opciones de ruta (<code>redirect(url, 404)</code>, unas <code>layoutProps</code> que no son las del layout); antes sólo los daba <code>meeko check .</code>. En un proyecto que ya tiene <code>.meeko/types</code>, regenera antes las declaraciones, así que ve un layout o una página creados después del último <code>meeko check .</code>.</li> <li><strong><code>signal(props.x ?? 0)</code> no da <code>MEEK101</code>.</strong> Cualquier expresión de una prop como valor inicial de <code>signal(...)</code> (<code>props.x ?? 0</code>, <code>props.items.length + 1</code>, <code>[...props.items]</code>) cuenta como el valor inicial explícito que ya era <code>signal(props.x)</code>.</li> </ul> <h2 id="160---2026-10-28">[1.6.0] - 2026-10-28<a class="heading-anchor" href="#160---2026-10-28" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.5</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.6">Actualizar de 1.5 a 1.6</a>.</p> <h3 id="añadido-1">Añadido<a class="heading-anchor" href="#a%C3%B1adido-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Middleware de ruta con nombre.</strong> <code>export default defineRouteMiddleware(fn, { global: false })</code> en <code>app/middleware/auth.ts</code> (o <code>10-auth.ts</code>: el prefijo numérico no cuenta) declara el middleware <code>"auth"</code>, que sólo se ejecuta en las rutas que lo piden con <code>defineGroup({ middleware: ["auth"] })</code> en un <code>+group.ts</code> o <code>definePage({ middleware: ["auth", "admin"] })</code>. Se acumula de los grupos exteriores a la página, sin repetir, y <code>middleware: false</code> quita los heredados. Se ejecuta después de los globales, en el orden declarado, con el mismo contrato en SSR, en la navegación del navegador, en <code>render: "client"</code>, en el prerender y en el adaptador <code>static</code>. Meeko lee <code>{ global }</code> y <code>middleware</code> sin ejecutar los archivos: un nombre que no existe (con la lista de los disponibles), uno global o un valor que no es literal detienen <code>meeko dev</code>, <code>meeko build</code> y <code>meeko check</code> con el archivo. <code>middleware</code> se tipa con la unión <code>RouteMiddlewareName</code> (<code>GeneratedRouteMiddleware</code> en <code>.meeko/types/routes.d.ts</code>), con completado, hover y Ctrl+clic en el editor; en una aplicación sin middleware con nombre la unión está vacía, así que cualquier nombre es un error de tipos. En el navegador, cada middleware con nombre es un chunk que se carga la primera vez que se navega a una de sus rutas. La ruta guarda la lista resuelta en <code>RouteRecord.middleware</code>; un host propio la carga con la nueva opción <code>loadNamedMiddleware</code> de <code>mountClientApp</code> y <code>createFrameworkHandler</code>, y <code>discoverRouteMiddleware</code> de <code>@meekojs/meeko/build</code> separa los globales. Un middleware sin opciones sigue siendo global, y <code>middleware</code> en un <code>+group.ts</code> deja de ser un error. Como siempre, el middleware de ruta se empaqueta para el navegador y no sustituye a la autorización del loader, la API o el RPC.</li> <li><strong>Middleware de ruta de servidor.</strong> Un archivo <code>app/middleware/*.server.ts</code> con <code>export default defineServerRouteMiddleware(fn)</code> (de <code>@meekojs/meeko/framework</code>, autoimportado en los <code>*.server.ts</code> y en <code>server/</code>) es middleware de ruta que sólo se ejecuta en el servidor, con el contexto de <code>usePage()</code> (<code>url</code>, <code>params</code>, <code>search</code>, <code>request</code>, <code>signal</code>, <code>context</code>) y <code>session</code>, <code>services</code>, <code>platform</code> y <code>requestId</code> a mano. Expresa «este grupo exige sesión» sin repetirlo en cada página: <code>auth.server.ts</code> con <code>{ global: false }</code> es <code>"auth"</code> y <code>defineGroup({ middleware: ["auth"] })</code> lo pide; sin opciones es global. Corta la ruta con <code>redirect()</code>, <code>notFound()</code>, un error o un <code>Response</code>. Se ejecuta después del middleware isomórfico (globales y luego con nombre) y antes del <code><script server></code> o el <code>load</code>: en SSR y, al navegar, dentro de la petición de datos de la página, cuya redirección sigue el navegador; en <code>render: "stream"</code>, antes del primer byte. Nunca llega al bundle del navegador y puede importar <code>server/</code> y <code>#server/…</code> sin <code>MEEK108</code>. Una página <code>render: "client"</code> o <code>"prerender"</code> que pide uno con nombre detiene el descubrimiento, y los globales no se ejecutan en ellas (el adaptador <code>static</code> lo avisa). <code>RouteMiddlewareName</code> incluye sus nombres (el <code>middleware</code> de una página <code>render: "client"</code> no los admite), el hover del editor los marca como «sólo servidor», y <code>auth.ts</code> y <code>auth.server.ts</code> con nombre son un nombre duplicado. Nuevos: los tipos <code>ServerRouteMiddleware</code> y <code>ServerRouteMiddlewareContext</code>, <code>RouteRecord.serverMiddleware</code> (la cadena completa de la ruta: los globales de servidor y después los con nombre), la opción <code>loadServerMiddleware(file)</code> de <code>createFrameworkHandler</code> (una ruta que lista alguno y no la tiene falla en lugar de saltárselo), <code>PageRoute.middleware</code> y <code>serverGlobal</code> de <code>RouteMiddlewareDiscovery</code>. El middleware de ruta no protege <code>server/api</code> ni el RPC, que siguen necesitando sus propias guardas.</li> </ul> <h3 id="cambios-2">Cambios<a class="heading-anchor" href="#cambios-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>app/middleware/*.server.ts</code> deja de ignorarse.</strong> Hasta <code>1.5</code> el descubrimiento de middleware de ruta los excluía; desde <code>1.6</code> son middleware de ruta de servidor. Un <code>*.server.ts</code> cuyo export por defecto no es una llamada a <code>defineServerRouteMiddleware(...)</code> (un helper sin export por defecto, o con <code>export default function parseCookies…</code>) detiene <code>meeko dev</code>, <code>meeko build</code> y <code>meeko check</code> con el archivo y la indicación de mover los helpers a <code>server/utils</code>, en lugar de convertirse en middleware global de servidor sin aviso (véase la <a href="/docs/stability#excepciones-aprobadas">excepción aprobada</a>).</li> <li><strong>Un spread en las opciones de ruta que puede llevar <code>middleware</code> exige declararlo después.</strong> <code>definePage({ ...protegida, render: "ssr" })</code> con un <code>protegida</code> importado (o una constante del archivo que tiene <code>middleware</code>) detiene el descubrimiento: Meeko no lee el spread y la ruta se serviría sin ese middleware. Declare <code>middleware</code> después del último spread (<code>middleware: []</code> si no añade ninguno). El spread de una constante del mismo archivo sin <code>middleware</code> sigue valiendo. Además, una página cuyo <code>middleware</code> nombra uno que su manifiesto no lista (un build antiguo) responde <code>500</code> en lugar de servirse sin él, como ya pasaba con <code>layout</code>.</li> <li><strong>El navegador ejecuta el middleware de ruta global en el mismo orden que el servidor.</strong> Hasta <code>1.5</code>, la entrada del cliente lo ordenaba con <code>localeCompare</code> y el servidor por código de carácter, lo que sólo difería con nombres que mezclan mayúsculas, <code>-</code> o <code>_</code>; ahora ambos usan el orden del servidor.</li> </ul> <h3 id="correcciones-2">Correcciones<a class="heading-anchor" href="#correcciones-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Una página renderizada para otra URL ya hidrata.</strong> El <code>404.html</code> del adaptador <code>static</code>, que el hosting sirve en cualquier URL inexistente, y una página prerenderizada servida con una query string (<code>/?utm=mail</code>) fallaban al hidratar con <code>Hydration mismatch</code> si algo pintaba <code>useRoute()</code>: el navegador hidrataba con su propia URL y no con la del render. Le pasaba a <code><MeekoThemeToggle></code>, cuyo campo oculto <code>return</code> lleva <code>useRoute().url</code>, y podía pasarle a <code><MeekoAwait reserve></code> (su clave depende de <code>path</code>) y al <code>aria-current</code> de <code><MeekoLink></code>. El payload lleva ahora la URL del render (campo opcional <code>url</code>); el navegador hidrata con ella y, justo después, <code>useRoute()</code> pasa a la del navegador, así que el formulario sin JavaScript vuelve a la página en la que está el visitante.</li> <li><strong><code>POST /_meeko/theme</code> no redirige fuera del origen con segmentos de punto.</strong> Un <code>return</code> como <code>/.//evil.example</code> o <code>/a/..//evil.example</code> se normalizaba a <code>//evil.example</code>, una <code>Location</code> relativa al protocolo. Ahora vuelve a <code>/</code>. La comprobación de <code>Origin</code> ya impedía usarlo desde otro sitio.</li> </ul> <h2 id="150---2026-10-28">[1.5.0] - 2026-10-28<a class="heading-anchor" href="#150---2026-10-28" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.4</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.5">Actualizar de 1.4 a 1.5</a>.</p> <h3 id="añadido-2">Añadido<a class="heading-anchor" href="#a%C3%B1adido-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Layouts con nombre.</strong> Cada <code>app/layouts/<nombre>.meeko</code> es un layout con nombre (<code>app/layouts/admin/panel.meeko</code> es <code>"admin/panel"</code>) que la página elige con <code>definePage({ layout: "dashboard" })</code> en <code><script server></code> o en el sidecar; <code>layout: false</code> deja sólo <code>app/app.meeko</code>, y sin <code>layout</code> se usa <code>default</code>, como hasta ahora. <code>meeko build</code> lo lee sin ejecutar el archivo, como <code>render</code>, y un nombre que no existe detiene <code>meeko dev</code>, <code>meeko build</code> y <code>meeko check</code>. El orden es <code>app/app.meeko</code> → layout con nombre → <code>+layout.meeko</code> de carpetas y grupos → página. Al navegar, el mismo layout se conserva con su estado y otro lo reemplaza, también con <code>render: "client"</code>, <code>"stream"</code>, prerender y el adaptador <code>static</code>. Los layers aportan los suyos y los módulos los añaden con <code>meeko.addLayout(name, file)</code>; el proyecto gana. <code>discoverLayouts</code> en <code>@meekojs/meeko/build</code>, y el campo opcional <code>layout</code> (<code>{ name, file, props? }</code>) en <code>RouteRecord</code> y <code>ErrorPageRecord</code>.</li> <li><strong>Opciones por carpeta: <code>+group.ts</code>.</strong> <code>export default defineGroup({ layout: "dashboard", layoutProps: { showAlert: false } })</code> en cualquier carpeta de <code>app/pages</code> (autoimportado) da su layout y sus props a las páginas de la carpeta y sus subcarpetas: en cascada del exterior al interior, la página gana y <code>layoutProps</code> se combina por clave. Se lee sin ejecutar el archivo, así que sus valores son literales. <code>meeko check</code> avisa con <code>MEEK115</code> de un <code>+group.ts</code> fuera de <code>app/pages</code>. <code>middleware</code> no se admite: las rutas no declaran middleware por nombre.</li> <li><strong>Props del layout desde la página.</strong> <code>definePage({ layoutProps: { title: "Conexiones" } })</code> o <code>layoutProps: ({ data }) => ({ title: data.user.name })</code>, tipadas contra las <code>Props</code> del layout elegido y presentes en el HTML del SSR desde el primer byte (viajan en el payload, campo opcional <code>layoutProps</code>). Una prop con <code>undefined</code> toma el valor por defecto del layout, y una que JSON no representa falla con la página, el layout y la prop. <code>useLayout()</code> (autoimportado) las lee y las cambia de forma reactiva desde el <code><script></code> de la página con <code>layout.set({ showAlert: true })</code>, sin volver a montar el layout; en una página se tipa con su layout. Lo que el setup escribe durante el SSR llega al HTML con un segundo render, sin mismatch de hidratación, y al navegar el layout vuelve a las props de la página nueva. <code>.meeko/types/routes.d.ts</code> declara <code>GeneratedLayouts</code> y <code>GeneratedPageLayouts</code>; <code>@meekojs/meeko/framework</code> exporta <code>useLayout</code>, <code>defineGroup</code> y los tipos <code>LayoutName</code>, <code>LayoutProps</code> (autoimportado), <code>LayoutHandle</code>, <code>LayoutPropsInput</code>, <code>PageLayout</code>, <code>PageLayoutOptions</code>, <code>GroupDefinition</code> y <code>NamedLayoutRecord</code>. <code>meeko check</code> compara las <code>layoutProps</code> de un <code>+group.ts</code> o de una página que hereda su layout con las de ese layout (<code>MEEK_PAGE_LAYOUT_PROPS</code>). El editor completa <code>layout:</code> y las claves de <code>layoutProps</code>, y el hover del nombre del layout muestra su archivo y sus páginas.</li> <li><strong><code><MeekoOutlet /></code> con props propias.</strong> Un layout que usa <code><MeekoOutlet /></code> puede declarar sólo sus props (<code>defineProps<{ title?: string }>()</code>): Meeko añade <code>outlet</code> a su <code>ComponentProps</code>, así que ya no hace falta declararlo.</li> <li><strong><code>meeko dev</code> sigue los cambios de layout.</strong> Editar una página, un sidecar o un <code>+group.ts</code> de forma que cambie el layout (o el <code>render</code>) de una ruta vuelve a crear la aplicación con el manifiesto nuevo, sin reiniciar.</li> <li><strong>Datos que llegan después del primer pintado, sin saltos: <code><MeekoAwait></code>.</strong> Una etiqueta propia de Meeko, como <code><MeekoLink></code>, sin import, que envuelve la zona de un <code>useApi</code> o un <code>useRpcQuery</code> sin <code>await</code>: <code><MeekoAwait for="items" reserve></code>. <code>for</code> es una expresión (como <code>each:of</code>; también <code>bind:for</code>) con un recurso o una lista (<code>for="[items, stats]"</code>). Pinta el snippet <code>pending</code> en la primera carga, <code>error</code> (con <code>error</code> y <code>retry</code>, que vuelve a pedir los recursos que fallaron) si falla, y su contenido cuando todos tienen datos; sin snippet <code>error</code>, un <code><p role="alert"></code> con un botón «Reintentar» (textos en <code>bind:messages</code>). Durante una recarga el contenido sigue montado y recibe <code>refreshing</code> (<code><snippet name="default" params="refreshing"></code>). Dentro del contenido, <code>meeko check</code> y el editor leen <code>items.data.value</code> como cargado, sin <code>!</code>. El contenedor es un <code><div></code> con <code>data-meeko-await="pending|error|ready"</code>, <code>aria-busy="true"</code> mientras carga o recarga y <code>data-meeko-refreshing</code>, sin estilos propios; si el foco estaba en un nodo que desaparece al cambiar de estado (el botón «Reintentar»), pasa a la zona en lugar de perderse. Sin <code>for</code> es el nuevo error <code>MEEK116</code>. Tipos <code>MeekoAwaitProps</code> (autoimportado), <code>MeekoAwaitSnippets</code>, <code>AwaitResource</code> y <code>AwaitMessages</code> en <code>@meekojs/meeko/framework</code>. El editor completa la etiqueta, sus props y sus snippets, la explica en el hover y lleva a <code>MeekoAwaitProps</code>; la gramática de VS Code la colorea como integrada y su <code>for</code> como TypeScript. Véase <a href="/docs/framework#meekoawait"><code><MeekoAwait></code></a>.</li> <li><strong>Reserva de altura con memoria: <code><MeekoAwait reserve></code>.</strong> Al mostrar datos, la zona mide su altura con un <code>ResizeObserver</code> (sin bloquear) y la guarda en <code>sessionStorage</code> y en memoria, por ruta, petición e instancia; mientras vuelve a esperar esos datos, una regla de una hoja de estilos construida (<code>adoptedStyleSheets</code>) le da esa <code>min-block-size</code>, sin atributos <code>style</code>, así que vale con una CSP estricta. En una carga completa, un script en línea de <code><head></code> (con el nonce, o con su hash en un sitio estático; siempre el mismo texto) adopta las reglas antes del primer pintado y la hidratación no cambia nada; en una navegación o un montaje posterior, el componente las adopta antes de insertar la zona. <code>reserve="320px"</code> fija además un mínimo, también en la primera visita, con un <code><style></code> de <code><head></code>; <code>bind:reserve</code> puede cambiar en el navegador, y el script, las reglas y la medición lo siguen. Con <code>sessionStorage</code> bloqueado, la memoria vive mientras la página está abierta. En Chrome, una card con 8 filas que llegan a los 900 ms pasa de CLS 0,246 a 0 en la segunda visita, por navegación o por recarga. Véase <a href="/docs/framework#evitar-saltos-de-altura-cls">Evitar saltos de altura (CLS)</a>.</li> <li><strong><code>refreshing</code> y <code>keepPrevious</code> en <code>useApi</code> y <code>useRpcQuery</code>.</strong> Como desde <code>1.1</code>, <code>refresh()</code> y un cambio de la entrada conservan <code>data</code> hasta que llegan los datos nuevos; ahora <code>refreshing</code> es <code>true</code> durante esa recarga (la primera carga es <code>pending</code> sin <code>refreshing</code>), para un indicador que no oculta los datos. El nuevo último argumento <code>{ keepPrevious }</code> (tipo <code>DataResourceOptions</code>) vale <code>true</code> por defecto, el comportamiento de siempre; con <code>false</code>, un cambio de la entrada vacía <code>data</code> y <code>error</code> y vuelve a ser una primera carga. <code>refresh()</code> y un recurso esperado con <code>await</code> conservan siempre los datos. Véase <a href="/docs/framework#datos-anteriores-durante-una-recarga-keepprevious">Datos anteriores durante una recarga</a>.</li> <li><strong>Aviso <code>MEEK117</code>.</strong> <code>meeko check</code>, <code>meeko build</code> y el editor avisan de una página o un layout que pinta en un <code>each:of</code> los datos de un <code>useApi</code> o un <code>useRpcQuery</code> sin <code>await</code> sin ocuparse de su carga: la lista sale vacía en el HTML del servidor y crece al llegar los datos. Desaparece con <code>await</code>, <code><MeekoAwait></code>, una lectura de <code>pending</code> o <code>refreshing</code>, un <code>if:when</code> sobre los datos o al pasar el recurso entero a otro componente. Es una pista, no un error.</li> <li><strong><code><MeekoTeleport></code>: contenido en otro lugar del documento.</strong> Una etiqueta propia, sin import: <code><MeekoTeleport to="#toolbar">…</MeekoTeleport></code> pinta su contenido dentro del elemento con ese <code>id</code> y <code>to="body"</code>, al final de <code><body></code>. El contenido sigue siendo del componente que lo declara (señales, eventos, snippets, <code>provide</code>/<code>inject</code>, manejadores de errores y <code><style scoped></code>) y se libera con él, también al cambiar de página, sin dejar nodos en el destino. El HTML de SSR, <code>"stream"</code> y <code>"prerender"</code> (también con el adaptador <code>static</code>) ya lo trae en su destino, se renderice éste antes o después, y la hidratación no cambia el DOM. <code>disabled</code> o <code>bind:disabled</code> lo pintan en su sitio; cambiarlo mueve los mismos nodos. Funciona dentro de <code>if:when</code> y <code>each:of</code>. <code>to</code> sólo admite <code>"body"</code> y <code>"#id"</code>, que se busca con <code>getElementById</code>; otro valor estático da <code>MEEK114</code>, y <code>bind:to</code> se tipa como <code>MeekoTeleportTarget</code>. Un <code>#id</code> que la página no renderiza falla en desarrollo y, en producción, se pinta en su sitio con un aviso. <code>@meekojs/meeko/framework</code> exporta los tipos <code>MeekoTeleportProps</code> y <code>MeekoTeleportTarget</code>; un componente del proyecto llamado <code>MeekoTeleport</code> tiene prioridad, con <code>MEEK106</code>. El editor completa sus atributos y, en <code>to="…"</code>, <code>body</code> y los <code>id</code> del componente, de <code>app/app.meeko</code> y de los layouts. Véase <a href="/docs/framework#meekoteleport"><code><MeekoTeleport></code></a>, que explica también cuándo bastan <code><dialog></code> o <code>popover</code>.</li> <li><strong>Popover integrado: <code><MeekoPopover></code>.</strong> Una etiqueta propia, sin import, sobre la API nativa <code>popover</code> y <em>CSS anchor positioning</em>: Meeko pinta un <code><button></code> con <code>popovertarget</code>, <code>aria-expanded</code>, <code>aria-controls</code> y <code>aria-haspopup</code> (el snippet <code>trigger</code> es su contenido) y el contenido en un elemento con <code>popover</code>, oculto desde el HTML del servidor. <code>mode</code> es <code>"auto"</code> (se cierra al pulsar fuera), <code>"manual"</code> o <code>"hint"</code> (un tooltip que se abre con el puntero o el foco, con retardo y sin robar el foco); <code>placement</code> admite <code>top</code>, <code>bottom</code>, <code>left</code> y <code>right</code> con <code>-start</code>/<code>-end</code>, <code>offset</code> separa el contenido y <code>position-try-fallbacks: flip-block, flip-inline</code> lo da la vuelta si no cabe. Sin anchor positioning, un cálculo mínimo en JavaScript lo coloca al abrirse y con <code>resize</code>/<code>scroll</code>, también dado la vuelta y dentro del viewport. <code>Esc</code> cierra y devuelve el foco; con <code>role="menu"</code>, flechas, <code>Inicio</code>/<code>Fin</code> y búsqueda por letras entre los <code>menuitem</code>, y elegir uno cierra el menú; <code>role="dialog"</code> lleva el foco dentro y <code>role="tooltip"</code> describe el disparador. <code>model</code> es la señal de apertura y <code>on:toggle</code> emite <code>{ open }</code>. El snippet <code>anchor</code> acepta un disparador propio, que recibe sus atributos en <code>trigger</code> (listo para <code>bind="trigger"</code>). Los IDs salen de <code>useId</code> y los estilos van por CSSOM, en la capa de cascada <code>meeko</code>: una CSP sin <code>'unsafe-inline'</code> basta. Véase <a href="/docs/api#popover-meekopopover">Popover</a>.</li> <li><strong>Select integrado: <code><MeekoSelect></code>.</strong> Un select accesible sobre <code><MeekoPopover></code>, sin estilos visuales: un <code>role="combobox"</code> con <code>aria-activedescendant</code> (el foco se queda en el disparador) y un <code>role="listbox"</code>, con <code>data-active</code>, <code>data-selected</code> y <code>data-disabled</code> en las opciones y <code>data-open</code> en la raíz. <code>model</code> es la opción o, con <code>multiple</code>, un array; <code>meeko check</code> y el editor infieren su tipo, el de <code>by</code> y el de los parámetros de los snippets (<code>option</code>, <code>value</code>, <code>group</code>, <code>empty</code>, <code>loading</code>) del tipo de <code>options</code>. <code>by</code> compara objetos, <code>groupBy</code> agrupa con encabezados, <code>disabledBy</code> deshabilita y <code>max</code> limita la selección múltiple. <code>searchable</code> convierte el disparador en un <code><input></code> que filtra sin distinguir acentos; <code>filter</code> es una búsqueda propia, también asíncrona, con estado de carga y cancelación. El teclado sigue el patrón de select de ARIA (flechas, <code>Inicio</code>/<code>Fin</code>, <code>RePág</code>/<code>AvPág</code>, <code>Intro</code>, <code>Espacio</code>, <code>Esc</code> y búsqueda por letras), y la opción activa se desplaza hasta verse. Con <code>name</code> envía <code><input type="hidden"></code> con el <code><form></code>; <code>required</code> y <code>disabled</code> funcionan como en un control nativo, y <code>bind:field="form.field('x')"</code> de <code>useForm</code> da el valor, el <code>id</code>, <code>aria-invalid</code> y <code>aria-describedby</code>. La lista mide al menos lo que el disparador y tiene una altura máxima con scroll. Véase <a href="/docs/api#select-meekoselect">Select</a>.</li> <li><strong>Etiquetas integradas sin coste en el bundle.</strong> <code><MeekoThemeToggle></code>, <code><MeekoAwait></code>, <code><MeekoPopover></code> y <code><MeekoSelect></code> son módulos propios (<code>@meekojs/meeko/builtins/theme-toggle</code>, <code>/await</code>, <code>/popover</code> y <code>/select</code>, contrato entre el compilador y el runtime de la misma versión, como <code>/internal</code>) que el compilador importa sólo en los componentes que usan la etiqueta; el resto de la aplicación no carga su código. Sus tipos <code>MeekoPopoverProps</code> y <code>MeekoSelectProps</code> (con <code>PopoverPlacement</code>, <code>PopoverTrigger</code>, <code>SelectModel</code>, <code>SelectFilter</code>…) se exportan desde <code>@meekojs/meeko/framework</code> y se autoimportan en <code>app/</code>. El editor completa ambas etiquetas, sus props y sus snippets y las explica en el hover, y la gramática de VS Code las colorea como etiquetas integradas. Un componente del proyecto con uno de esos nombres tiene prioridad, con <code>MEEK106</code>.</li> <li><strong>Etiquetas HTML en <code><component is></code>, con contenido.</strong> <code>is</code> acepta, además de un componente, una etiqueta HTML: un literal (<code>'a'</code>), una expresión cuyo tipo es una unión de etiquetas (<code>props.href ? 'a' : 'button'</code>, una prop <code>as: "section" | "article"</code>) o una unión de etiquetas y componentes. Con una etiqueta es ese elemento, con sus atributos, eventos, <code>ref:</code>, <code>html</code> y <code>bind="obj"</code>, y con su contenido (hijos, <code>if:when</code>, <code>each:of</code>, <code><render></code> y componentes); con un componente, el contenido son sus snippets. Meeko deduce la unión de etiquetas del tipo de <code>is</code>: <code>event.currentTarget</code> de un <code>on:</code> y el <code>useElementRef</code> de un <code>ref:</code> son la unión de sus elementos (<code>HTMLAnchorElement | HTMLButtonElement</code>). Si todos los resultados de <code>is</code> son literales, el SSR escribe el elemento sin marcadores; si alguno puede ser un componente, el elemento va en el rango del componente. Al cambiar la etiqueta en el navegador, un elemento nuevo sustituye al anterior y los hijos se mueven a él con sus nodos, su estado, el valor de sus controles y el foco; entre una etiqueta y un componente, el rango se monta de nuevo. Las etiquetas admitidas son el nuevo tipo público <code>TagName</code>: no <code>script</code>, <code>style</code>, <code>iframe</code>, <code>object</code>, <code>embed</code>, <code>template</code>, <code>textarea</code> ni las de metadatos; un valor no admitido es un error de compilación (si es un literal) o de tipos (<code>MEEK112</code>), y en ejecución un <code>TypeError</code> antes de escribir HTML, en SSR y en el navegador. Un <code><button></code> que pasa a ser <code><a></code> al recibir <code>href</code> se escribe con una sola plantilla. Véase <a href="/docs/api#etiquetas-html-en-component-is">Etiquetas HTML en <code><component is></code></a>.</li> <li><strong>Atributos según la etiqueta.</strong> En un <code><component is></code> con etiquetas, un atributo que no es global sólo se escribe mientras la etiqueta del momento lo admite según los datos HTML de Meeko (los de MDN que usa el editor), sin ternarios: <code>bind:href</code>, <code>target</code> y <code>rel</code> sólo en <code><a></code>, <code>bind:type</code> y <code>disabled</code> sólo en <code><button></code>. Los globales (<code>class</code>, <code>id</code>, <code>style</code>, <code>title</code>, <code>hidden</code>, <code>tabindex</code>, <code>role</code>, <code>aria-*</code>, <code>data-*</code>…) y los eventos se escriben siempre. Un atributo que no admite ninguna de las etiquetas posibles es el nuevo error <code>MEEK112</code> de <code>meeko check</code> y del editor. En los elementos normales nada cambia. Véase <a href="/docs/api#atributos-seg%C3%BAn-la-etiqueta">Atributos según la etiqueta</a>.</li> <li><strong>Atributos en bloque: <code>bind="obj"</code>.</strong> En un elemento, en <code><component is></code> y en una etiqueta de componente, escribe las claves de un objeto como atributos o como props, de forma reactiva: añade las nuevas y quita las que el objeto deja de tener. Un <code>bind:x</code> explícito o un atributo estático gana sobre la misma clave; <code>class</code> y <code>style</code> se combinan con los explícitos (las declaraciones explícitas de <code>style</code> ganan). Las claves <code>undefined</code>, <code>null</code> o <code>false</code> no se escriben. Las claves <code>on*</code> se rechazan en los tipos y en ejecución, porque los manejadores no se crean desde datos, y también las <code>data-meeko*</code>. Los nombres se comparan sin distinguir mayúsculas, como en HTML: <code>ID</code> junto a <code>bind:id</code> no escribe un segundo <code>id</code>, y <code>Data-Meeko</code> también se rechaza. El objeto se comprueba contra los atributos de la etiqueta o contra las props del componente (<code>MEEK113</code>); el nuevo tipo público <code>ElementAttributes<Tag></code> lo tipa. En un elemento personalizado, <code>bind</code> sigue siendo un atributo HTML. Véase <a href="/docs/api#atributos-en-bloque-con-bind">Atributos en bloque con <code>bind</code></a>.</li> <li><strong>Enlace activo por sección: <code>match</code> en <code><MeekoLink></code> y <code>useRoute().isActive()</code>.</strong> <code>match="exact"</code> (por defecto) mantiene el comportamiento de antes, y <code>match="prefix"</code> marca también las rutas que están por debajo: en su propia ruta el enlace lleva <code>aria-current="page"</code> y en una ruta por debajo, <code>aria-current="true"</code>, la sección actual. Compara por segmentos completos, sobre las rutas codificadas como <code>href()</code> y sin query ni fragmento: <code>/dashboard</code> cubre <code>/dashboard/stats</code>, no <code>/dashboards</code>, y <code>/dash</code> no cubre <code>/dashboard</code>. <code>to="/"</code> sólo coincide exacta, también con <code>prefix</code>, para no quedar activo en todas las páginas; en una ruta dinámica, la sección es la de sus <code>params</code>. <code>match</code> admite <code>bind:match</code> con una expresión <code>"exact" | "prefix"</code>, que <code>meeko check</code> y el editor comprueban; otro valor estático es <code>MEEK105</code>. El valor sale en el HTML del servidor, la hidratación no lo cambia y la navegación lo actualiza, también en un layout conservado. <code>MeekoLinkProps</code> gana <code>match</code>, y el editor lo completa con sus dos valores y lo explica en el hover. Para los enlaces y componentes propios, <code>RouteState</code> (lo que devuelve <code>useRoute()</code>) gana <code>isActive(to, { params, prefix })</code>, con la misma regla: <code>to</code> es un <code>RouteId</code> y <code>params</code> los de esa ruta, con los tipos de <code>href()</code>; devuelve <code>"page"</code>, <code>"true"</code> o <code>false</code>, que sirve tal cual para <code>bind:aria-current</code> y como condición, y es reactivo. Véase <a href="/docs/framework#meekooutlet--y-meekolink"><code><MeekoOutlet /></code> y <code><MeekoLink></code></a> y <a href="/docs/framework#ruta-actual">Ruta actual</a>.</li> <li><strong><code>useId()</code>: IDs estables entre SSR e hidratación.</strong> Desde <code>@meekojs/meeko</code> y autoimportado: devuelve un ID para <code>id</code>, <code>for</code> o <code>aria-describedby</code> que sale de la posición de la instancia en el árbol (componente, clave de la fila de <code>each:</code>, <code>if:</code> y snippet) y del orden de la llamada, así que el servidor y el navegador dan el mismo sin enviarlo, y nunca se repite entre instancias, también en filas o regiones que aparecen después en el navegador. <code>document.idPrefix</code> en <code>meeko.config.ts</code> cambia su prefijo (<code>m</code> por defecto). Véase <a href="/docs/api#ids-estables-useid">IDs estables</a>.</li> <li><strong><code>useForm</code>: <code>trySubmit</code>, <code>commit</code>, <code>onSuccess</code>, <code>focusInvalid</code> y <code>field</code>.</strong> <code>form.trySubmit(event)</code> envía como <code>submit</code> y resuelve con un <code>FormSubmission</code> discriminado (<code>{ ok: true, result }</code> o <code>{ ok: false, reason: "invalid" | "error" | "skipped" }</code>); <code>submit</code> no cambia. <code>form.commit(values?)</code> toma los valores como nuevos iniciales de <code>dirty</code> y de <code>reset()</code> sin borrar <code>submitted</code>, y <code>onSuccess(result, form)</code> lo hace tras un envío correcto. Con <code>focusInvalid: true</code>, un envío con errores en los campos enfoca el primer control inválido una vez pintados los mensajes. <code>form.field(name)</code> devuelve un <code>FormField</code> tipado con la señal, el mensaje, <code>invalid</code>, <code>describedBy</code> e IDs de <code>useId</code>, para un componente de campo propio (<code><AppField bind:field="form.field('email')" /></code>). Véase <a href="/docs/framework#formularios-useform">Formularios</a>.</li> <li><strong><code>ApiError</code> con <code>issues</code>.</strong> <code>new ApiError("EMAIL_TAKEN", 409, { issues: [{ path: "email", message: "…" }] })</code> envía mensajes de campo con la forma de los de un <code>400</code> (como mucho 20, sólo con un <code>4xx</code>); el <code>message</code> sigue siendo interno. Llegan en <code>ClientError.issues</code> y <code>useForm</code> los lleva a su campo. Sólo viajan los de un <code>ApiError</code> de Meeko: otro error con su forma (un <code>ApiError</code> de un SDK, un <code>ClientError</code> de otro servicio que se deja escapar) no envía sus <code>issues</code>. Tipos nuevos <code>ApiErrorOptions</code> y <code>ApiErrorIssue</code>. Véase <a href="/docs/framework#errores-de-un-campo-apierror-con-issues">Errores de un campo</a>.</li> <li><strong><code>ClientError</code> e <code>isClientError</code> autoimportados</strong> en los componentes y en los módulos de <code>app/</code>, como <code>useForm</code>; no en <code>server/</code>, <code>*.server.ts</code> ni los archivos de ruta. Un export propio con el mismo nombre tiene prioridad.</li> <li><strong>Aliases de ruta: <code>~/</code>, <code>@/</code>, <code>#shared/</code> y <code>#server/</code>.</strong> Sin configuración, <code>~/</code> es la raíz del proyecto, <code>@/</code> es <code>app/</code> (al revés que en Nuxt, a propósito), <code>#shared/</code> es <code>shared/</code> y <code>#server/</code> es <code>server/</code>. Funcionan en <code>meeko dev</code> y <code>meeko build</code> (navegador y SSR, con todos los adaptadores), en los <code>paths</code> de <code>.meeko/tsconfig.app.json</code>, <code>server</code> y <code>shared</code> (así que <code>meeko check</code> y el editor resuelven y tipan), en el servidor de lenguaje (completado de carpetas y archivos tras el alias e «Ir a la definición») y en los módulos de <code>@utilities</code> y lo que importan. Cada alias tiene el ámbito de su carpeta, como los autoimports: <code>#server/</code> sólo existe en el código de servidor y en un componente, un <code>.ts</code> de <code>app/</code> o <code>shared/</code> da <code>MEEK108</code> (también con <code>import type</code>) en <code>meeko check</code>, el editor y el build, y <code>@/</code> en <code>shared/</code> da el nuevo error <code>MEEK118</code> en <code>meeko check</code>, <code>meeko dev</code> y el build. Los aliases se buscan en el proyecto y después en cada layer: gana el primer archivo que existe, también desde un archivo de un layer. Un componente se puede importar con un alias (<code>import * as Card from "@/components/Card.meeko"</code>). <code>alias</code> en <code>meeko.config.ts</code> (<code>{ "ui/": "app/components/ui/", "#server/": false }</code>) añade aliases, cambia los de Meeko o los quita; cada uno toma el ámbito de la carpeta a la que apunta, y una clave o una carpeta no válidas son un error de la configuración (<code>MEEK_CONFIG</code> en el editor). Un patrón de los <code>paths</code> del <code>tsconfig.json</code> del proyecto con el prefijo de un alias de Meeko y otra carpeta, un <code>resolve.alias</code> de Vite que cubre ese prefijo (del proyecto o de un módulo) y una entrada de <code>"imports"</code> de <code>package.json</code> que empieza por <code>#shared/</code> o <code>#server/</code> ganan y desactivan ese alias de Meeko en todas partes, también en las comprobaciones de ámbito (<code>MEEK108</code>, <code>MEEK118</code>), con un aviso una vez por proceso. Los schemas de los contratos de API, RPC y Socket también se importan con un alias (<code>#shared/schemas/auth</code> o uno propio que apunte a <code>shared/</code>): el generador de contratos lo resuelve y los clientes generados nombran el archivo de <code>shared/</code> por su ruta. Véase <a href="/docs/framework#aliases-de-ruta">Aliases de ruta</a>.</li> </ul> <h3 id="cambios-3">Cambios<a class="heading-anchor" href="#cambios-3" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code><component is></code> admite contenido.</strong> Hasta <code>1.4</code> daba <code>MEEK031</code>; ahora su contenido son los snippets del componente, como en su etiqueta, o los hijos de la etiqueta HTML. <code>MEEK031</code> queda para una etiqueta vacía (<code>img</code>, <code>input</code>…) con contenido. En un <code><component is></code> cuya expresión puede dar una etiqueta, los atributos con guiones, que antes daban <code>MEEK032</code>, son del elemento. Un <code><component is></code> cuyos resultados son nombres en PascalCase o imports de un <code>.meeko</code> (<code>is="Card"</code>, <code>is="open ? Dialog : Sheet"</code>) compila igual que antes; una expresión como <code>props.content</code> admite además etiquetas y lleva algo más de código.</li> <li><strong><code>bind="..."</code> es una directiva.</strong> Sin nombre, <code>bind</code> en un elemento estándar o en una etiqueta de componente ya no es un atributo literal ni la prop estática <code>bind</code>: es <code>bind="obj"</code>. Para la prop o el atributo literal, use <code>bind:bind="'texto'"</code> (véase la <a href="/docs/stability#excepciones-aprobadas">excepción aprobada</a>).</li> <li><strong><code>alias</code> es una clave de <code>MeekoConfig</code>.</strong> Un módulo con <code>meta.configKey: "alias"</code> hace fallar la carga de la configuración y pide otra clave, como <code>theme</code> desde <code>1.4</code> (véase la <a href="/docs/stability#excepciones-aprobadas">excepción aprobada</a>).</li> <li><strong>Los <code>tsconfig</code> generados copian los <code>paths</code> del proyecto.</strong> <code>.meeko/tsconfig.app.json</code>, <code>server</code> y <code>shared</code> incluyen ahora los <code>paths</code> del <code>tsconfig.json</code> del proyecto, que hasta <code>1.4</code> sólo usaban el editor y la comprobación de los componentes, así que <code>meeko check</code> resuelve con ellos también los <code>.ts</code>.</li> <li><strong><code>MEEK108</code> ve el <code>server/</code> de los layers en <code>meeko check</code>.</strong> Un import de valores de un componente que llega al <code>server/</code> de un layer, que ya fallaba en el build, es ahora <code>MEEK108</code> también en <code>meeko check</code> y en el editor.</li> </ul> <h3 id="correcciones-3">Correcciones<a class="heading-anchor" href="#correcciones-3" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Una señal con <code>undefined</code> ya no rompe el SSR.</strong> <code>const id = signal<string | undefined>(undefined)</code> hacía responder <code>500</code> a toda la página con «TypeError: Non-serializable value at $.id», sin decir de qué componente. Ahora el estado lleva esas señales aparte y el navegador las hidrata como <code>undefined</code>, sin diferencias. Un valor que JSON sigue sin representar (una fecha, un <code>Map</code>, una instancia) falla con el componente, la señal y una pista: <code>app/pages/agenda.meeko: the signal "when" cannot be sent to the browser with the SSR state (…)</code>.</li> <li><strong><code>useForm</code> revalida los campos que dependen del que cambia.</strong> Una confirmación (<code>v.forward(v.partialCheck(…), ["confirm"])</code>) seguía mostrando «Las contraseñas no coinciden» después de corregir la contraseña, porque sólo se validaba el campo editado. Ahora cada cambio vuelve a validar también los demás campos con un error del schema (y el mensaje del formulario que vino del schema); los mensajes del servidor de otros campos se conservan.</li> </ul> <h2 id="141---2026-10-28">[1.4.1] - 2026-10-28<a class="heading-anchor" href="#141---2026-10-28" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <h3 id="correcciones-4">Correcciones<a class="heading-anchor" href="#correcciones-4" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>La hoja global ya no se queda sin reglas tras editar un archivo que importa.</strong> En <code>meeko dev</code>, el snapshot <code>.meeko/styles/main.css</code> transformaba <code>app/styles/main.css</code> en cuanto el watcher avisaba de un cambio. Cuando el aviso llega al truncarse el archivo, antes de escribirse su contenido (el watcher descarta después el cambio de la escritura), transformaba un archivo vacío, y la petición del navegador reutilizaba ese resultado de la caché de Vite. La página se quedaba sin las reglas del archivo hasta la siguiente edición. Ahora el snapshot espera al contenido del archivo cambiado con el <code>read()</code> de Vite antes de transformar la hoja.</li> </ul> <h2 id="140---2026-10-28">[1.4.0] - 2026-10-28<a class="heading-anchor" href="#140---2026-10-28" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.3</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.4">Actualizar de 1.3 a 1.4</a>.</p> <h3 id="añadido-3">Añadido<a class="heading-anchor" href="#a%C3%B1adido-3" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Snippets condicionales: <code>if:when</code> en <code><snippet></code>.</strong> <code><snippet name="footer" if:when="snippets.actions">…</snippet></code> pasa el snippet al hijo sólo mientras la condición es verdadera; con la condición falsa, para el hijo no existe: <code>snippets.footer</code> es <code>undefined</code>, su <code>if:when="snippets.footer"</code> es falso y un <code><render></code> no pinta nada. Permite reenviar un snippet opcional sin que el hijo pinte un contenedor vacío. La condición se evalúa en el ámbito del padre, igual en SSR y al hidratar, y es reactiva: el hijo sigue montado (con su DOM, su estado y su foco) y sólo se actualizan los bindings que leen ese snippet, porque el objeto <code>snippets</code> de un hijo con props reactivas sigue al padre; un hijo sin props reactivas (con un <code>await</code> de datos en el nivel superior, o compilado antes de <code>1.2</code>) se vuelve a montar, conservando sus señales editables por nombre. Sólo vale para un snippet que el hijo declara opcional (<code>x?:</code>): en uno obligatorio es el nuevo error de tipos <code>MEEK110</code> de <code>meeko check</code> y del editor, marcado en <code>if:when</code>. La condición estrecha los tipos dentro del contenido del snippet, como <code>if:when</code> en un elemento. <code>MEEK061</code> sigue rechazando los demás atributos y señala además un <code>if:when</code> vacío o sin valor. El editor completa <code>name</code>, <code>params</code> e <code>if:when</code> en <code><snippet></code>, y el plugin de Prettier formatea la condición como una expresión. Véase <a href="/docs/api#snippets-con-definesnippets">docs/api.md</a>.</li> <li><strong>Tema claro/oscuro sin parpadeo: <code>theme</code> y <code>useTheme()</code>.</strong> Con <code>theme: true</code> (o <code>{ themes, default, system, darkThemes, attribute, colorScheme, cookie, storageKey, clientHints }</code>) en <code>meeko.config.ts</code>, Meeko guarda la elección en una cookie (<code>meeko-theme</code>) y en <code>localStorage</code>, y el servidor escribe el tema en <code><html></code> (<code>data-theme="dark"</code> o una clase) desde el primer byte. En modo <code>"system"</code>, el servidor lo resuelve con el client hint <code>Sec-CH-Prefers-Color-Scheme</code> (responde con <code>Accept-CH</code> y <code>Critical-CH</code>, así que Chromium lo envía ya en la primera visita) y, si no lo recibe, un script en línea y bloqueante de <code><head></code> aplica el tema antes del primer pintado; el mismo script resuelve las páginas prerenderizadas y el adaptador <code>static</code>. El script lleva el nonce en SSR y su hash entra en la CSP de las páginas prerenderizadas y de <code>static</code>; <code>color-scheme</code> se aplica por CSSOM, que una CSP sin <code>'unsafe-inline'</code> permite. <code>useTheme()</code>, autoimportado, devuelve <code>theme</code> (la elección, editable y válida para <code>model</code>), <code>resolved</code> (el tema efectivo), <code>themes</code> y <code>set(theme)</code>: en SSR lee la cookie, así que los iconos salen bien en el HTML del servidor; la hidratación pinta lo mismo que el servidor y recibe los valores del navegador al terminar; un cambio actualiza <code><html></code>, la cookie y <code>localStorage</code>, sigue a <code>prefers-color-scheme</code> en <code>"system"</code> y llega a las otras pestañas. La cookie se valida contra la lista de temas, los documentos llevan <code>Vary: Cookie, Sec-CH-Prefers-Color-Scheme</code> y <code>meeko check</code> tipa los temas como la unión literal de <code>themes</code> (<code>GeneratedTheme</code>), que el editor declara a partir de <code>theme</code> leído sin ejecutar la configuración. Con <code>attribute: "class"</code>, el runtime sólo cambia la clase del tema en <code><html></code> (con <code>classList</code>) y conserva las demás, también las que añaden otros scripts. El script va en <code><head></code> justo después de las <code>meta</code> y antes de las hojas de estilo enlazadas, así que no espera a ninguna. Sin <code>theme</code>, nada cambia. Véase <a href="/docs/framework#tema-clarooscuro-sin-parpadeo">Tema claro/oscuro sin parpadeo</a>.</li> <li><strong>Selector de tema integrado: <code><MeekoThemeToggle></code>.</strong> Con <code>theme</code> activo, una etiqueta propia de Meeko, como <code><MeekoLink></code>, sin import: <code>mode="cycle"</code> (por defecto), un botón que pasa a la elección siguiente, o <code>mode="select"</code>, un grupo de radios accesible con el teclado; <code>bind:themes</code> restringe y ordena la lista, <code>bind:labels</code> nombra cada elección («Claro», «Oscuro», «Sistema» por defecto) y <code>bind:messages</code> traduce los textos accesibles (tipo <code>ThemeToggleMessages</code>); <code>class</code> e <code>id</code> van al <code><form></code> raíz. Un snippet por elección (<code><snippet name="dark"><IconMoon /></snippet></code>) es su icono; <code>meeko check</code> y el editor tipan los snippets, <code>themes</code> y <code>labels</code> con los temas de la configuración (tipo <code>ThemeToggleSnippets</code>; el editor lee <code>theme</code> de <code>meeko.config.*</code> sin ejecutarlo, también antes del primer <code>meeko check</code> y aunque el tsconfig no incluya <code>.meeko/types/routes.d.ts</code>), y el editor completa la etiqueta, sus props y sus snippets y la explica en el hover. El componente pinta todos los iconos, cada uno en <code><span data-meeko-theme-icon></code>, y una regla mínima que Meeko añade a <code><head></code> (sólo <code>display: none</code>) muestra el de la elección, así que el icono sale bien desde el primer frame, también en <code>"system"</code> sin cookie ni client hint, y hidratar no cambia ningún nodo. El <code>aria-label</code> del botón dice la elección y la siguiente («Tema: oscuro. Cambiar a sistema») o, mientras la página no la conoce, «Cambiar tema». En <code>mode="select"</code>, mientras no se conoce la elección (sin la cookie o en una página prerenderizada) ningún radio lleva <code>aria-checked</code>, ni siquiera el de <code>default</code>; el estado visual lo da el CSS con <code>data-theme-choice</code>, y al hidratar cada radio recibe su <code>aria-checked</code> una sola vez. Sin JavaScript es un formulario que envía <code>POST /_meeko/theme</code>: el servidor comprueba que el tema sea uno de <code>themes</code> o <code>"system"</code> y que <code>Origin</code> sea el del propio sitio, escribe la cookie y responde <code>303</code> sólo a una ruta del mismo origen (nunca una redirección abierta); con JavaScript, el envío se intercepta y el cambio es inmediato. En el adaptador <code>static</code> el formulario necesita JavaScript. Usarla sin <code>theme</code> es el nuevo error <code>MEEK111</code> (en <code>meeko check</code> y el editor, cuando <code>meeko.config.*</code> lo dice sin ejecutarse; si no, al renderizarse); un componente del proyecto con ese nombre tiene prioridad, con <code>MEEK106</code>. La gramática de VS Code la colorea como etiqueta integrada. Véase <a href="/docs/framework#meekothemetoggle"><code><MeekoThemeToggle></code></a>.</li> <li><strong><code>data-theme-choice</code> en <code><html></code>.</strong> Con <code>theme</code>, <code><html></code> lleva además la elección, <code>"system"</code> incluido: la escribe el script de <code><head></code> antes del primer pintado, el servidor cuando la conoce por la cookie y el runtime con cada cambio, para el CSS propio (un icono de «sistema» que no salta). Una cookie que escribió el servidor pasa a <code>localStorage</code> y a las otras pestañas en la siguiente carga. <code>theme.attribute</code> no puede ser <code>"data-theme-choice"</code>.</li> <li><strong>CSP con hashes de estilos.</strong> <code>inlineStyleHashes(html)</code> de <code>@meekojs/meeko/build</code> calcula el SHA-256 de cada <code><style></code> en línea, <code>prerender/manifest.json</code> los guarda en <code>pages[ruta].styleHashes</code> y <code>contentSecurityPolicy(policy, scriptHashes, styleHashes)</code> los añade a <code>style-src-elem</code>, <code>style-src</code> o una copia de <code>default-src</code>, salvo que la directiva ya admita <code>'unsafe-inline'</code> (el hash la anularía para los atributos <code>style</code>). El adaptador <code>static</code> los aplica con <code>server.contentSecurityPolicy</code>, así que el estilo del tema (y el de los componentes) funciona con una política sin <code>'unsafe-inline'</code>; en SSR lleva el nonce. Véase <a href="/docs/framework#csp-con-hashes">CSP con hashes</a>.</li> <li><strong>Autoimports en los módulos de <code>@utilities</code>.</strong> En un proyecto Meeko (una carpeta con <code>meeko.config.*</code> o un <code>package.json</code> que depende de <code>@meekojs/meeko</code>), <code>meekoUtilities()</code> aplica al módulo de <code>@utilities</code>, y a los módulos locales en TypeScript que importa, los mismos autoimports de valores que el plugin de Vite aplica al resto del proyecto, con el mismo registro y la misma transformación: los de <code>app/composables</code>, <code>app/utils</code>, <code>app/stores</code>, <code>app/types</code> e <code>imports.appDirs</code>, los de <code>shared/*</code> e <code>imports.sharedDirs</code> y los de los layers y los módulos. Así, un <code>app/styles/utilities/color.ts</code> que usa sin import una constante de <code>app/theme</code> declarada en <code>imports.appDirs</code> genera la hoja en lugar de fallar con <code>THEME_COLORS is not defined</code>, como ya aceptaban el editor y <code>meeko check</code>. No llegan los exports de <code>server/</code> y <code>serverDirs</code>, los <code>.client.ts</code> y <code>.server.ts</code>, los componentes <code>.meeko</code>, los clientes generados ni las API del framework (<code>signal</code>, <code>useState</code>…); usar uno da un error que nombra el autoimport, su origen y el motivo, no un <code>ReferenceError</code>. <code>defineUtilities</code> sigue importándose de <code>@meekojs/meeko/postcss</code>. Los archivos de autoimports que se usan son dependencias de la hoja, y añadir o quitar un export en una carpeta de autoimports regenera el módulo. Nueva opción <code>meekoUtilities({ autoImports })</code>, <code>true</code> por defecto; <code>false</code> empaqueta los módulos como en <code>1.3</code>. Para leer el registro, el plugin ejecuta <code>meeko.config.*</code> y los <code>setup</code> de sus módulos, como <code>meeko dev</code>, una vez por hoja; si eso falla, la hoja se genera sin autoimports y con un aviso, en lugar de fallar. Fuera de un proyecto Meeko, con <code>autoImports: false</code> o sin rolldown (Vite 8), la configuración no se ejecuta y los módulos se cargan como en <code>1.3</code>. Véase <a href="/docs/framework#utilidades-generadas-con-typescript">docs/framework.md</a>.</li> <li><strong><code>defineSnippets</code> acepta un mapa de snippets.</strong> El valor de cada clave de <code>T</code> puede ser, además de una tupla de parámetros, un <code>Snippet<Args></code>, que cuenta como <code>Args</code>. Así un componente reutiliza los snippets de otro: <code>defineSnippets<Omit<AppCardSnippets, "footer"> & { actions?: [close: () => void] }>()</code>, o con <code>import type { ComponentSnippets as CardSnippets } from "./Card.meeko"</code>, que antes era el error <code>TS2344</code> porque <code>ComponentSnippets</code> es el mapa de <code>Snippet<Args></code> y no la declaración de tuplas. Cada snippet conserva sus parámetros y su opcionalidad con <code>Omit</code>, <code>Pick</code> y <code>&</code>, también en un componente genérico, y <code>meeko check</code>, el editor y la comprobación de las etiquetas del padre ven las tuplas resultantes (<code>MEEK110</code> incluido). Las declaraciones con tuplas tienen el mismo tipo que antes. Véase <a href="/docs/api#snippets-con-definesnippets">docs/api.md</a>.</li> <li><strong>Tipos con el nombre de cada componente.</strong> Cada componente autoimportado (de <code>app/components</code>, de los layers y de las carpetas de componentes de los módulos, con su prefijo) aporta sin import <code><Nombre>Props</code>, <code><Nombre>Snippets</code>, <code><Nombre>Models</code> y <code><Nombre>Exposed</code>, con el nombre de su etiqueta: <code>app/components/App/Card.meeko</code> da <code>AppCardProps</code>, <code>AppCardSnippets</code>, <code>AppCardModels</code> y <code>AppCardExposed</code>. Son el <code>ComponentProps</code>, <code>ComponentSnippets</code>, <code>ComponentModels</code> y <code>ComponentExposed</code> de su módulo, con sus parámetros de tipo y <code>null</code> cuando el componente no declara el canal, y tienen el ámbito del componente: los <code>.meeko</code> y los <code>.ts</code> de <code>app/</code>, no <code>shared/</code>. Llegan con <code>import type</code> desde el <code>.meeko</code> y se declaran en <code>.meeko/types/autoimports/</code>; un autoimport del proyecto con el mismo nombre (por ejemplo, de <code>app/types</code>) tiene prioridad. El editor los completa donde se escribe un tipo, y el hover y la navegación a definición llevan al componente y a la macro que declara cada uno; lo mismo hacen ahora con un <code>ComponentSnippets</code> importado de un <code>.meeko</code>. Los nombres genéricos no cambian. Véase <a href="/docs/framework#tipos-de-cada-componente">Tipos de cada componente</a>.</li> <li><strong><code>MeekoLinkProps</code>, <code>MeekoOutletProps</code>, <code>MeekoThemeToggleProps</code> y <code>RouteId</code></strong> en <code>@meekojs/meeko/framework</code>: los tipos de las props de <code><MeekoLink></code> (<code>to</code>, <code>params</code> y <code>search</code>, con las rutas de la aplicación y los parámetros de cada una), de <code><MeekoOutlet /></code> (ninguna) y de <code><MeekoThemeToggle></code> (<code>mode</code>, <code>themes</code>, <code>labels</code>, <code>messages</code>, <code>class</code> e <code>id</code>, con los temas de la configuración), y el ID de cualquier ruta de la aplicación (el tipo de <code>to</code> y de <code>href</code>). Sólo son tipos, documentados con JSDoc. Se autoimportan: los de las etiquetas donde se usan los componentes (<code>app/</code> y los <code>.meeko</code>), con el ámbito de <code>AppCardProps</code>, y <code>RouteId</code> en todo el proyecto, como <code>href</code>; un tipo del proyecto con el mismo nombre tiene prioridad, y un componente del proyecto que sustituye la etiqueta (<code>app/components/MeekoLink.meeko</code>, con <code>MEEK106</code>) aporta su propio <code>MeekoLinkProps</code>. Así un componente recibe una ruta sin import, con <code>defineProps<{ href: MeekoLinkProps["to"] }>()</code> o <code>RouteId</code>, y <code>meeko check</code> comprueba que el padre le pasa una ruta que existe. El editor los usa en el hover de esas etiquetas y en «Ir a definición», y los completa sin añadir un import.</li> <li><strong>Hover de <code><MeekoLink></code>, <code><MeekoOutlet /></code> y <code><MeekoThemeToggle></code> en el editor.</strong> Muestran la misma ficha que un componente del proyecto en lugar de <code>any</code>: sus props con los tipos reales (<code>to</code> con la ruta, <code>bind:params</code> con los parámetros de esa ruta, <code>bind:search</code>), su contenido (<code>default</code>), lo que renderizan, su documentación y un enlace a la guía. La de <code><MeekoThemeToggle></code> lista sus props y un snippet por elección de la configuración. «Ir a definición» abre <code>MeekoLinkProps</code>, <code>MeekoOutletProps</code> o <code>MeekoThemeToggleProps</code>; el hover y el completado de <code>to</code>, <code>bind:params</code> y <code>bind:search</code> usan esos tipos, <code>on:click</code> y el resto de atributos tienen los de un <code><a></code> y el completado ofrece los atributos de <code><a></code> sin <code>href</code>. El servidor de lenguaje las describe con una tabla de etiquetas propias (props, snippets, elemento que renderizan, documentación y dónde valen), a la que se suma cada etiqueta nueva. Con un <code>@meekojs/meeko</code> anterior sin esos tipos, la ficha usa los de la tabla.</li> <li><strong>Ficha de componente con color.</strong> El hover de una etiqueta de componente, del identificador que lo importa y de sus tipos (<code>AppCardProps</code>…) muestra la firma de la etiqueta en un bloque TypeScript (<code><AppCard</code>, una línea por prop con su tipo declarado, como <code>variant?: CardVariant</code>, <code>on:save(id: number)</code>, <code>model:open?: boolean</code> y los snippets <code>header?()</code> y <code>default()</code> como contenido), un enlace que abre el <code>.meeko</code> y el JSDoc de cada prop, evento, modelo y snippet que lo tenga. Se omiten las secciones vacías en lugar de escribir «ninguno». El hover de <code><snippet name></code> también muestra el JSDoc del snippet.</li> </ul> <h3 id="cambios-4">Cambios<a class="heading-anchor" href="#cambios-4" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>meta.configKey</code> no puede ser una clave propia de <code>MeekoConfig</code>.</strong> Desde esta versión <code>theme</code> es una opción de Meeko, y un módulo con <code>configKey: "theme"</code>, como el del ejemplo de módulos de la guía de <code>1.3</code>, leería como sus opciones las del tema de Meeko y su aumentación de <code>MeekoConfig.theme</code> chocaría con el tipo de Meeko. Ahora un módulo cuyo <code>meta.configKey</code> es <code>layers</code>, <code>extends</code>, <code>modules</code>, <code>imports</code>, <code>server</code>, <code>css</code>, <code>document</code>, <code>dev</code>, <code>site</code>, <code>sitemap</code>, <code>robots</code> o <code>theme</code> hace fallar la carga de la configuración con un mensaje que pide otra clave, y unas opciones de <code>theme</code> con campos que no son del tema (<code>initial</code>) fallan con <code>unknown field</code> y un mensaje que apunta a ese conflicto. Es una excepción aprobada en <a href="/docs/stability#excepciones-aprobadas">stability.md</a>; la migración (otra clave, como <code>acmeTheme</code>) está en la <a href="/docs/migration-1.4#un-m%C3%B3dulo-con-configkey-theme">guía de actualización</a>.</li> </ul> <h3 id="correcciones-5">Correcciones<a class="heading-anchor" href="#correcciones-5" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Completado del <code><script></code> sin ruido.</strong> El completado, el hover y «Ir a definición» ya no ofrecen los tipos auxiliares del código virtual del editor (<code>__MeekoDeclaredProps</code>, <code>__MeekoEmit</code>, <code>__MeekoChannelsOf</code>, <code>__MeekoAnyProp</code>…), y el hover de un evento muestra <code>HTMLAnchorElement</code> en lugar de <code>__MeekoElementOf<"a", false></code>. De <code>@meekojs/meeko</code> sólo se sugieren las entradas públicas de <code>exports</code>: con el paquete enlazado (<code>link:</code> de pnpm o una junction), TypeScript lo resuelve fuera de <code>node_modules</code> y sugería sus archivos internos con rutas relativas (<code>MeekoAdapterName</code> desde <code>../../../../Clients/meeko/packages/meeko/dist/…</code>); ahora un nombre que exporta una entrada se importa desde ella (<code>@meekojs/meeko/framework</code>) y uno que ninguna exporta no se sugiere. Los exports de los paquetes van después de los nombres locales y de los autoimports del proyecto.</li> <li><strong>Autoimport de un nombre de un módulo ya autoimportado.</strong> Completar <code>Signal</code> (o <code>MeekoModule</code>) en un componente que usa <code>signal()</code> (o <code>useRoute()</code>) escribía <code>, type Signal</code> al principio del <code><script></code>, porque TypeScript lo añadía al import que el editor genera para el autoimport y que no existe en el <code>.meeko</code>. Ahora añade <code>import { type Signal } from "@meekojs/meeko";</code>.</li> <li><strong>Comprobación del proyecto en el editor desactualizada (<code>MEEK_PROJECT_CHECK</code>).</strong> Un <code>.meeko</code> vacío recién creado (por ejemplo, en una carpeta nueva <code>app/components/Layout</code>) rompía la comprobación de contratos y su <code>MEEK007</code> aparecía en cada archivo abierto que la lanzaba; al guardar el componente con su contenido el error seguía, porque guardar un componente fuera de <code>app/pages</code> y <code>app/layouts</code> no volvía a comprobar el proyecto y un fallo anterior no se borraba con la siguiente comprobación correcta. Ahora la comprobación se repite, con una espera de 450 ms, al guardar, crear, borrar o renombrar cualquier <code>.meeko</code>, módulo, configuración o carpeta de la aplicación (el servidor observa también la creación y el borrado de carpetas bajo <code>app/</code>, <code>server/</code> y <code>shared/</code>); usa el texto sin guardar de los componentes abiertos; un componente que no compila conserva su última declaración y su error sale en ese archivo, un <code>.meeko</code> vacío se trata como «en edición», y cada comprobación sustituye todos los diagnósticos de la anterior, también los de un fallo.</li> <li><strong><code>meeko dev</code> con un Meeko enlazado ya no se reinicia al leer el build.</strong> En Windows, con la actualización de la fecha de último acceso activa (lo habitual), la primera lectura de cada archivo en una hora llega al observador como un cambio, así que cargar un <code>dist/</code> de hace más de una hora o servir uno de sus módulos al navegador reiniciaba el servidor supervisado. Ahora sólo cuentan las escrituras, creaciones y borrados de <code>dist/</code> y <code>package.json</code>.</li> <li><strong><code>MEEKO_LINK_WATCH=0</code> avisa al reconstruir el Meeko enlazado.</strong> Sin supervisor, <code>meeko dev</code> conserva el código de servidor de Meeko que cargó mientras Vite sirve al navegador el <code>dist/</code> nuevo, así que el HTML salía del build anterior y la hidratación usaba el nuevo, sin ningún aviso. Ahora escribe en la terminal, una vez por reconstrucción, que hay que reiniciar <code>meeko dev</code>.</li> <li><strong>Dependencias de <code>@utilities</code> con constantes en línea.</strong> Un módulo local cuyo export rolldown escribía en línea (una constante de texto o número) dejaba de figurar en los mensajes <code>dependency</code> de la hoja, así que editarlo no regeneraba el CSS en <code>meeko dev</code>. Ahora la hoja depende de todos los módulos locales que lee el bundle.</li> <li><strong><code><snippet></code> en el completado de una etiqueta de componente.</strong> Escribir <code><sn</code> justo dentro de <code><AppCard></code> o <code><MeekoThemeToggle></code> ofrece <code><snippet name="…"></code> y, al insertarlo, los nombres de los snippets del hijo. No se ofrece dentro de <code><MeekoLink></code> ni de un elemento, donde <code><snippet></code> es <code>MEEK061</code>.</li> <li><strong>Completado del <code><script></code> de un componente sin nombres de Node ni del módulo compilado.</strong> Con <code>@types/node</code> en el tsconfig del proyecto, el completado del <code><script></code> y de la plantilla, que también se ejecutan en el navegador, ofrecía <code>__dirname</code>, <code>__filename</code>, <code>require</code>, <code>process</code> o <code>Buffer</code> y autoimports de los módulos de Node (<code>userInfo</code> de <code>os</code> y de <code>node:os</code>). Además ofrecía <code>renderToString</code>, <code>renderWithState</code>, <code>hydrate</code>, <code>hydrateScope</code> y <code>css</code>, que no son APIs de Meeko sino los exports del propio componente compilado para su padre y el runtime. Ahora quedan fuera; los globales que el DOM también declara (<code>setTimeout</code>, <code>fetch</code>, <code>URL</code>…) siguen, y <code><script server></code> conserva los de Node.</li> <li><strong>Servidor de lenguaje al apagarse.</strong> <code>shutdown</code> cancela lo pendiente y espera a que termine la comprobación de contratos en curso; lo que llega después se descarta, y escribir en el log, publicar diagnósticos o reenviar <code>console.*</code> con la conexión ya cerrada ya no lanza un error sin capturar (<code>Connection is disposed</code>).</li> </ul> <h2 id="130---2026-10-27">[1.3.0] - 2026-10-27<a class="heading-anchor" href="#130---2026-10-27" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.2</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.3">Actualizar de 1.2 a 1.3</a>.</p> <h3 id="añadido-4">Añadido<a class="heading-anchor" href="#a%C3%B1adido-4" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Arrays expandidos como los objetos en el plugin de Prettier.</strong> Nueva opción <code>meekoPreserveArrayBreaks</code> de <code>@meekojs/meeko/prettier</code>, activa por defecto: un array, un patrón de desestructuración o una tupla de TypeScript con un salto de línea entre <code>[</code> y su primer elemento se imprime con un elemento por línea aunque quepa en <code>printWidth</code>, la regla de <code>objectWrap: "preserve"</code> para los objetos; sin ese salto decide Prettier, así que para colapsarlo basta con unir <code>[</code> y el primer elemento. El plugin sustituye para ello el printer <code>estree</code> de Prettier (exportado en <code>printers</code>), así que se aplica a todo el JavaScript y TypeScript que formatee Prettier con el plugin en la configuración, no sólo al script y a las expresiones de la plantilla de los <code>.meeko</code>. Ese printer delega en tiempo de ejecución en el printer <code>estree</code> del Prettier que lo ejecuta, aunque sea otra versión 3.x que la que instala Meeko, así que con <code>false</code> la salida es la de ese Prettier. Es un cambio de la salida del formato, que <a href="/docs/stability">docs/stability.md</a> permite en un minor (véase <a href="/docs/editors#formato-con-prettier">docs/editors.md</a>).</li> <li><strong>HTML de confianza para <code>html="..."</code>: <code>TrustedHtml</code> y <code>trustHtml</code>.</strong> La raíz <code>@meekojs/meeko</code> exporta el tipo <code>TrustedHtml</code>, un <code>string</code> con una marca que sólo existe en los tipos, y <code>trustHtml(html)</code>, que la pone y en ejecución devuelve el mismo <code>string</code>, sin coste. <code>trustHtml</code> no sanea: sólo declara que el HTML es propio o ya está saneado (por ejemplo, <code>trustHtml(DOMPurify.sanitize(input))</code>). La marca llega intacta a la plantilla desde <code><script server></code>, <code>load</code> y <code>ServerData<T></code>, porque el payload es JSON. No es un autoimport. Véase <a href="/docs/api#html-de-confianza-trustedhtml-y-trusthtml">docs/api.md</a>.</li> <li><strong>Orden de las clases en el plugin de Prettier.</strong> Nueva opción <code>meekoSortClasses</code> de <code>@meekojs/meeko/prettier</code> (<code>"off"</code> por defecto, <code>"stylesheet"</code> o <code>"alphabetical"</code>; en la CLI, <code>--meeko-sort-classes</code> con <code>--plugin @meekojs/meeko/prettier</code>) para el atributo estático <code>class</code> de la plantilla. Con <code>"stylesheet"</code>, como <code>prettier-plugin-tailwindcss</code>, cada clase toma la posición de su primera aparición en <code>app/styles/main.css</code>, procesada con la API de Vite como en <code>meeko dev</code> (el <code>postcss.config</code> del proyecto, <code>@import</code> y <code>@utilities</code>), y después en el <code><style></code> del componente; las clases desconocidas van primero en su orden. No depende de que <code>meeko dev</code> esté en marcha: la hoja procesada se cachea por proceso mientras no cambie ningún archivo de su grafo. Si la hoja no existe o falla, no se ordena y se avisa una vez en la salida de errores. En un workspace no confiable de VS Code no se aplica, porque procesar la hoja ejecuta código del proyecto. Véase <a href="/docs/editors#orden-por-la-hoja-global">docs/editors.md</a>.</li> <li><strong>Aviso <code>MEEK107</code>.</strong> <code>meeko check</code>, <code>meeko build</code> y el editor avisan cuando el valor de <code>html="..."</code> no es asignable a <code>TrustedHtml | null | undefined</code>: un <code>string</code>, <code>string | undefined</code> o <code>any</code>. No avisan los tipos literales de texto y sus uniones (<code>html="'<br>'"</code>), ni <code>TrustedHtml</code>. Es un aviso: no hace fallar la comprobación ni cambia el SSR, la hidratación ni el código generado.</li> <li><strong>Hoja global procesada para el editor: <code>.meeko/styles/main.css</code>.</strong> <code>meeko dev</code> escribe <code>app/styles/main.css</code> tal como la sirve en desarrollo (con los <code>@import</code> resueltos, las <code>@utilities</code> expandidas y el resto de PostCSS aplicado, sin minificar) en <code>.meeko/styles/main.css</code>, en cuanto el servidor escucha y cada vez que cambian la hoja, un archivo que importa o un módulo de <code>@utilities</code> y su grafo. La sustituye de forma atómica y sólo si cambia el contenido, Vite no la vigila (no recarga la página) y, si la hoja no compila, conserva la última versión buena. Sin <code>app/styles/main.css</code> no hay archivo. Sirve para que extensiones como HTML CSS Support completen las clases generadas con <code>"css.styleSheets": [".meeko/styles/main.css"]</code>; <code>meeko build</code> no la escribe (véase <a href="/docs/framework#hoja-global-procesada-para-el-editor">docs/framework.md</a>).</li> <li><strong>Completado de clases CSS en el editor.</strong> El servidor de lenguaje completa en <code>class="…"</code> y en los literales de cadena de <code>bind:class</code> las clases del <code><style></code> del componente (también sin guardar), de los <code><style></code> sin <code>scoped</code> de los demás componentes (de uno con <code>scoped</code>, sólo las de <code>:global(…)</code>) y de la hoja global: la que <code>meeko dev</code> escribe ya procesada en <code>.meeko/styles/main.css</code> y, siempre, <code>app/styles/main.css</code> con sus <code>@import</code> locales, leída sin ejecutar PostCSS. Cada clase lleva su origen y su regla; el hover las muestra e ir a definición lleva al selector en el componente, en otro componente o en la hoja, o a la regla de la hoja procesada si sólo existe allí. Lee las reglas anidadas, <code>@media</code>, <code>@layer</code>, <code>:is()</code>, <code>:where()</code>, <code>:not()</code>, <code>:global()</code> y <code>@utility</code> de Tailwind 4, guarda lo leído por archivo y funciona en workspaces sin confianza. El servidor observa además <code>**/*.css</code> (véase <a href="/docs/editors#completado-de-clases-css">docs/editors.md</a>).</li> <li><strong>Cada API en su sitio: error <code>MEEK108</code> y aviso <code>MEEK109</code>.</strong> <code>meeko check</code>, <code>meeko build</code> (también el plugin de Vite en <code>meeko dev</code>) y el editor señalan, con un mensaje que dice dónde se usa, lo que no existe donde está escrito. En el <code><script></code> y la plantilla de un componente, que también se ejecutan en el navegador, es <code>MEEK108</code> un autoimport de servidor (<code>defineApiRoute</code>, <code>defineRpc</code>, <code>defineServerMiddleware</code>, <code>defineSocketChannel</code>, <code>defineServerRuntime</code>, <code>ApiError</code> o uno de <code>server/utils</code>), un import de valores de <code>@meekojs/meeko/server</code> o <code>/cloudflare</code> y un import de <code>server/</code> o de un módulo <code>*.server.*</code>; <code>usePage</code>, <code>redirect</code> y <code>notFound</code> sin import dan <code>MEEK073</code>, como ya ocurría al importarlos. En <code><script server></code> es <code>MEEK108</code> una macro del componente (<code>defineProps</code>, <code>defineEmits</code>, <code>defineExpose</code>, <code>defineModel</code>, <code>defineSnippets</code>, <code>useElementRef</code>) y <code>onMounted</code>. Todo eso ya fallaba: el autoimport no se resolvía en el bundle del navegador, <code>/server</code> y <code>/cloudflare</code> lanzan un <code>TypeError</code> al cargarse allí, un import de <code>server/</code> detenía <code>meeko build</code> y las macros no existen fuera del <code><script></code>; ahora el error llega antes y en su línea. Es <code>MEEK109</code>, un aviso, lo que hoy compila y se carga: <code>definePage</code> en el componente, que no configura la ruta, y un import de valores de <code>@meekojs/meeko/node</code>, <code>/bun</code>, <code>/deno</code>, <code>/password</code> o <code>/build</code>, cuyas funciones sólo funcionan en el servidor. Los <code>import type</code> siguen admitidos y un componente dentro de <code>server/</code> puede usarlo todo. El build y <code>meeko dev</code> sólo lo aplican al bundle del navegador, así que un componente fuera de <code>server/</code> que sólo importa código de servidor (una plantilla de correo de <code>app/emails/</code> que renderiza una ruta de API) sigue compilando. Véase <a href="/docs/framework#d%C3%B3nde-se-usa-cada-api">docs/framework.md</a>.</li> <li><strong>Fallos globales del navegador.</strong> <code>mountClientApp</code> escucha <code>error</code> y <code>unhandledrejection</code> en <code>window</code> mientras la aplicación está montada: las excepciones no capturadas y las promesas rechazadas sin manejar del código que no pasa por Meeko (un <code>setTimeout</code>, un <code>fetch().then()</code> sin <code>catch</code>, una librería) llegan a <code>onError</code> y a <code>app.onError</code> de los plugins con las fuentes nuevas <code>"uncaught"</code> y <code>"rejection"</code>; sin ellos, al primer <code>provideErrorHandler</code> activo. Un fallo entregado llama a <code>preventDefault()</code>, así que el navegador no lo repite en la consola; sin observador, el navegador lo muestra como siempre. Un error que ya recibió un observador de Meeko no se informa otra vez, el <code>"Script error."</code> opaco de un script de otro origen se deja a la consola y los listeners se retiran con <code>dispose()</code> o si la hidratación falla. <code>ErrorSource</code> gana los dos miembros, como permite la <a href="/docs/stability#api-p%C3%BAblica">política de estabilidad</a> para las uniones que Meeko entrega: un <code>switch</code> exhaustivo necesita rama por defecto (véase <a href="/docs/framework#fallos-globales-del-navegador">docs/framework.md</a>).</li> <li><strong>Fallos fuera de una petición en el servidor: <code>processErrors</code>.</strong> <code>meeko dev</code>, las salidas de <code>meeko build</code> (Node, Bun, Deno y Workers) y <code>serveNode</code> y <code>serveDeno</code> con <code>handleSignals</code> atienden las promesas rechazadas sin manejar y las excepciones no capturadas del proceso. Por defecto, un rechazo llega al <code>onError</code> de <code>server/runtime.ts</code> y el servidor sigue atendiendo (hasta ahora, Node, Bun y Deno terminaban el proceso, también <code>meeko dev</code>); una excepción llega a <code>onError</code> y el servidor se cierra de forma ordenada (deja de aceptar conexiones, espera las respuestas abiertas, las tareas de <code>waitUntil</code> y el cierre de la aplicación) y sale con código 1. <code>processErrors</code> en <code>server/runtime.ts</code> cambia la política (<code>unhandledRejection: "report" | "shutdown" | "off"</code>, <code>uncaughtException: "shutdown" | "off"</code>) o la desactiva con <code>false</code>. <code>onError</code> recibe esos fallos con un tercer argumento opcional, <code>{ kind, inRequest }</code> (tipo <code>ServerErrorInfo</code>), y el <code>requestId</code> de la petición cuando el runtime conserva su contexto asíncrono (Node; Deno y Workers para los rechazos; Bun para las excepciones); sin <code>onError</code>, Meeko escribe el error completo en la consola. Si la aplicación registró sus propios listeners de <code>process</code>, Meeko sólo informa. En Workers sólo se informan los rechazos. <code>handleProcessErrors(app, { close })</code> aplica la misma política a un host propio. Nuevos tipos <code>ProcessErrorPolicy</code>, <code>ProcessErrorOptions</code> y <code>ServerErrorInfo</code> (véase <a href="/docs/framework#fallos-fuera-de-una-petici%C3%B3n">docs/framework.md</a>).</li> <li><strong><code>isClientError(error, code?)</code></strong> en <code>@meekojs/meeko/framework</code>: comprueba y estrecha un <code>ClientError</code>, opcionalmente por código (<code>isClientError(error, "UNAUTHENTICATED")</code>), en los observadores que reciben <code>unknown</code>. Reconoce también el <code>ClientError</code> de otra copia de Meeko en la página, donde <code>instanceof</code> falla.</li> <li><strong>Logs del servidor en la consola del navegador.</strong> En <code>meeko dev</code>, lo que el código de servidor escribe con <code>console.log</code>, <code>info</code>, <code>warn</code>, <code>error</code> o <code>debug</code> mientras atiende una petición aparece también en la consola del navegador, agrupado por petición (método, ruta y <code>requestId</code>) y marcado con la insignia <code>server</code>, como <code>features.devLogs</code> de Nuxt; la terminal lo sigue mostrando igual. Cada log pertenece a su petición, también con peticiones simultáneas, y llega una sola vez: en el documento HTML, en los chunks de <code>render: "stream"</code>, en el payload de una navegación cliente o, para API, RPC y el trabajo posterior a la respuesta, por el WebSocket de HMR. Los objetos se despliegan como en el servidor (<code>Map</code>, <code>Set</code>, <code>bigint</code>, ciclos) y los <code>Error</code> muestran la traza del servidor y su <code>cause</code>, con límites de profundidad y tamaño que nunca rompen la respuesta ni el log. Sólo llega en la respuesta al navegador del desarrollador (peticiones desde loopback, a un host de loopback y sin cabeceras de proxy, así que tampoco a los visitantes de un túnel como ngrok o cloudflared), los scripts que inyecta llevan el nonce del documento y no existe en <code>meeko build</code> ni en <code>meeko start</code>. Se desactiva con la nueva opción <code>dev: { serverLogs: false }</code> de <code>meeko.config.ts</code> (véase <a href="/docs/framework#logs-del-servidor-en-la-consola-del-navegador">docs/framework.md</a>).</li> <li><strong>Adaptador <code>static</code>.</strong> <code>meeko build --adapter static</code> (o <code>server: { adapter: "static" }</code>) escribe en <code>.meeko/output/static/</code> un sitio sin servidor para cualquier hosting estático: los assets y <code>public/</code>, cada página prerenderizada como <code><ruta>/index.html</code> con su payload <code><ruta>/index.meeko.json</code>, y <code>404.html</code> desde <code>app/error.meeko</code>. El cliente de este build navega leyendo esos archivos, sin la negociación de <code>Accept</code> que un hosting estático no hace (<code>ClientAppOptions.serverData</code> acepta <code>"static"</code>). El build falla, antes de compilar, con la lista de lo que necesita un servidor: páginas que no son <code>render: "prerender"</code>, API, RPC, Socket, middleware de servidor y handlers de servidor de los módulos. <code>meeko preview</code> sirve la salida como un hosting. Nuevo tipo <code>StaticHeaderFile</code> (véase <a href="/docs/framework#sitio-est%C3%A1tico">docs/framework.md</a>).</li> <li><strong><code>sitemap.xml</code> y <code>robots.txt</code>.</strong> <code>sitemap: true | { exclude }</code> y <code>robots: true | { allow, disallow }</code> en <code>meeko.config.ts</code> los generan en el build, con las páginas prerenderizadas (salvo las <code>noindex</code>) y las rutas sin parámetros, para todos los adaptadores; en Node, Bun, Deno y Workers se sirven desde el manifiesto de assets. Nuevos tipos <code>SitemapConfig</code> y <code>RobotsConfig</code> (véase <a href="/docs/framework#sitemapxml-y-robotstxt">docs/framework.md</a>).</li> <li><strong><code>site</code> en <code>meeko.config.ts</code></strong>: el origen público de las URL absolutas que escribe el build (<code>MEEKO_PUBLIC_ORIGIN</code> sin él). No cambia las comprobaciones de <code>Origin</code>.</li> <li><strong>Canónica y Open Graph por página: <code>document.seo</code>.</strong> Añade <code><link rel="canonical"></code>, <code>og:url</code>, <code>og:title</code> y <code>og:description</code> a cada documento a partir del origen, la ruta, el título final y la descripción; una página que declara la etiqueta la sustituye, las páginas de error no tienen URL canónica y la navegación cliente las actualiza. Nuevo tipo <code>DocumentSeo</code> (véase <a href="/docs/framework#can%C3%B3nica-y-open-graph-por-p%C3%A1gina">docs/framework.md</a>).</li> <li><strong>CSP con hashes.</strong> <code>prerender/manifest.json</code> guarda en <code>scriptHashes</code> el SHA-256 de los scripts en línea de cada página prerenderizada; <code>inlineScriptHashes(html)</code> de <code>@meekojs/meeko/build</code> los calcula para cualquier documento y señala el JavaScript que un hash no puede permitir (<code>on*</code>, <code>javascript:</code>), y <code>contentSecurityPolicy(policy, hashes)</code> de <code>@meekojs/meeko/server</code> construye la cabecera. El adaptador <code>static</code> lo aplica con <code>server.contentSecurityPolicy</code> y escribe la cabecera, con <code>server.headers</code>, en <code>_headers</code> (Netlify, Cloudflare Pages) o <code>_meeko/headers.conf</code> (nginx) según <code>server.headerFiles</code>. Nuevos tipos <code>ContentSecurityPolicy</code> e <code>InlineScriptReport</code> (véase <a href="/docs/framework#csp-con-hashes">docs/framework.md</a>).</li> <li><strong>Carpetas de autoimports de <code>app/</code> y <code>shared/</code>: <code>imports.appDirs</code> e <code>imports.sharedDirs</code>.</strong> Junto a <code>imports.serverDirs</code>, <code>meeko.config.ts</code> admite carpetas de autoimports dentro de <code>app/</code> (<code>appDirs: ["app/services"]</code>, con el ámbito de <code>app/</code>: navegador y SSR, no <code>shared/</code>) y dentro de <code>shared/</code> (<code>sharedDirs: ["shared/validators"]</code>, con el ámbito de <code>shared/</code>). Se leen como las carpetas por defecto: de forma recursiva, en el proyecto y en cada layer, sin <code>*.test.ts</code>, <code>*.spec.ts</code> ni <code>*.d.ts</code>, con los sufijos <code>.client.ts</code>, <code>.server.ts</code> y <code>.shared.ts</code>, <code>import type</code> para los tipos, prioridad sobre los autoimports del framework y el mismo error de colisión; sólo aportan exports, no componentes. <code>meeko check</code>, <code>meeko build</code>, <code>meeko dev</code> (que recarga al crear, editar o borrar sus archivos), las declaraciones de <code>.meeko/types/autoimports/</code> y el editor (también el lector estático de un workspace no confiable) las ven, y <code>MEEK108</code> trata un <code>*.server.ts</code> de <code>appDirs</code> como código de servidor. Una ruta fuera de su carpeta (<code>appDirs: ["shared/x"]</code>, <code>..</code>, una ruta absoluta) es un error de <code>meeko.config.ts</code> que nombra la entrada, <code>imports.appDirs[0] must be a relative path inside app/: shared/x</code>, que el editor marca en ella (<code>MEEK_CONFIG</code>); una entrada no válida de <code>serverDirs</code>, que ya se rechazaba al leer los autoimports, da ahora el mismo error, y un <code>imports</code> que no es un objeto también es un error. Véase <a href="/docs/framework#carpetas-de-autoimports">Carpetas de autoimports</a>.</li> </ul> <h3 id="cambios-5">Cambios<a class="heading-anchor" href="#cambios-5" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>El plugin de Prettier normaliza el atributo estático <code>class</code>.</strong> En la plantilla de los <code>.meeko</code>, el valor de cada <code>class="…"</code> estático de un elemento pierde los espacios del principio y del final, sus espacios, tabuladores y saltos de línea quedan en uno y sus clases repetidas desaparecen (se conserva la primera), como ya hacía Prettier con el HTML suelto. Siempre activo y sin opción: no cambia las clases del elemento, porque los atributos estáticos de Meeko no interpolan. No toca <code>bind:class</code>, el <code>class</code> de una etiqueta de componente (una prop estática) ni un valor con referencias de carácter. Es un cambio de la salida del formato, que <a href="/docs/stability">docs/stability.md</a> permite en un minor: <code>prettier --check</code> puede marcar archivos que antes pasaban.</li> <li><strong>Declaraciones de <code>@meekojs/meeko/postcss</code> tipadas con csstype.</strong> El objeto de declaraciones de <code>rule()</code> y <code>atRule()</code> (<code>UtilityDeclarations</code>) usa los tipos de <a href="https://github.com/frenic/csstype">csstype</a>: el editor autocompleta las propiedades estándar y con prefijo de proveedor, en camelCase y en kebab-case, y las palabras clave de cada valor, y una propiedad mal escrita (<code>backgroundColr</code>) es un error de tipos. Las longitudes y los tiempos son cadenas con unidad salvo el <code>0</code> (<code>padding: 4</code>, que el plugin escribía sin unidad y el navegador descartaba, es ahora un error); los números siguen valiendo en <code>opacity</code>, <code>zIndex</code>, <code>flexGrow</code>, <code>lineHeight</code>… Siguen compilando las propiedades <code>--*</code>, los arrays de respaldo (también <code>as const</code>), <code>undefined</code>, <code>!important</code> y las claves dinámicas de <code>Object.fromEntries</code>. Sin la firma de índice <code>[property: string]</code>, leer las declaraciones con una clave <code>string</code> (<code>decls[key]</code>) es el error <code>TS7053</code> con <code>noImplicitAny</code>: use <code>Object.entries(decls)</code> o una clave <code>keyof UtilityDeclarations</code>. <code>atRule()</code> acepta además los descriptores de <code>@font-face</code>, <code>@property</code>, <code>@page</code>, <code>@counter-style</code>, <code>@font-palette-values</code> y <code>@view-transition</code> con el nuevo tipo <code>UtilityAtRuleDeclarations</code>. <code>csstype</code> pasa a ser una dependencia del paquete, sólo de tipos; el CSS generado no cambia. Lo que csstype no conozca se escribe con <code>css`…`</code>. Es una excepción aprobada de SemVer, sólo de tipos, registrada en <a href="/docs/stability#excepciones-aprobadas">docs/stability.md</a>.</li> <li><strong><code>definePage</code> resuelve las llamadas inferidas con una sola firma.</strong> Una firma nueva, la primera, cuya opción es la unión de <code>PageDefinition</code> y <code>ClientPageDefinition</code>, atiende las llamadas sin argumentos de tipo. Con un <code>render</code> todavía incompleto, el editor completaba la opción contra la primera de las cuatro sobrecargas (<code>render: "client"</code> con y sin <code>load</code> y las de servidor) y sólo ofrecía <code>"client"</code>; ahora ofrece <code>"ssr"</code>, <code>"stream"</code>, <code>"prerender"</code> y <code>"client"</code>, en <code><script server></code> y en los sidecars. La inferencia no cambia: el contexto de <code>load</code> según el modo, los datos de <code>head</code>, el <code>load</code> obligatorio en el resultado (que lee <code>meeko check</code>) y el error de tipos de <code>render: "client"</code> con <code>prerenderEntries</code>, cuyo mensaje sí cambia: tras «No overload matches this call», señala <code>render</code>, <code>prerenderEntries</code> y <code>load</code> como incompatibles. Las cuatro sobrecargas de 1.2 siguen detrás para las llamadas que escriben los argumentos de tipo hasta <code>D</code> (<code>definePage<P, S, D, C>(…)</code>, la forma de tipar el contexto <code>C</code>), en las que TypeScript no infiere nada: el resultado sigue siendo el tipo del modo de <code>render</code>, con <code>load</code> obligatorio si se declara. El hover muestra la firma nueva, con un parámetro de tipo más, <code>T</code>.</li> <li><strong>El autocompletado del <code><script></code> y de la plantilla no ofrece APIs de servidor.</strong> Quedan fuera los exports de <code>@meekojs/meeko/server</code>, <code>/node</code>, <code>/bun</code>, <code>/deno</code>, <code>/password</code>, <code>/build</code> y <code>/cloudflare</code>, los módulos de <code>server/</code> y <code>*.server.*</code>, y <code>definePage</code>, <code>usePage</code>, <code>redirect</code> y <code>notFound</code>. <code><script server></code> las sigue ofreciendo.</li> <li><strong>JSDoc de las opciones de ruta.</strong> <code>render</code> documenta su valor por defecto (<code>"ssr"</code>) y cada modo; <code>params</code>, <code>search</code>, <code>prerenderEntries</code>, <code>load</code> y <code>head</code> de <code>PageDefinition</code> y <code>ClientPageDefinition</code> dicen cuándo se ejecutan y qué valida el servidor; <code>PageBodyHead</code> incluye las etiquetas de <code>useHead</code> desde <code>1.2</code>, y <code>PageRequest.context</code> avisa de que lanza sin contexto de petición.</li> </ul> <h3 id="correcciones-6">Correcciones<a class="heading-anchor" href="#correcciones-6" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>El <code>404.html</code> de un sitio estático hidrata y navega en el cliente.</strong> Un documento con el payload de error de <code>app/error.meeko</code> ya no lanza <code>Meeko route hydration mismatch</code> cuando su URL coincide con una ruta, como <code>/docs/x</code> con <code>/docs/[slug]</code> sin esa entrada prerenderizada: hidrata la página de error y sus enlaces navegan en el cliente en lugar de recargar.</li> </ul> <h3 id="deprecado">Deprecado<a class="heading-anchor" href="#deprecado" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>html="..."</code> con un <code>string</code> sin marcar.</strong> Sigue funcionando igual durante 1.x, con el aviso <code>MEEK107</code>; en <code>2.0</code> será un error de <code>meeko check</code>. Reemplazo: marcar el HTML con <code>trustHtml(…)</code> donde se produce, después de sanearlo si viene de usuarios, o usar <code>{expr}</code>, que escapa. Véase <a href="/docs/stability#apis-deprecadas">docs/stability.md</a>.</li> <li><strong><code>definePage</code> y los imports de valores de <code>@meekojs/meeko/node</code>, <code>/bun</code>, <code>/deno</code>, <code>/password</code> y <code>/build</code> en el <code><script></code> o la plantilla de un componente.</strong> Siguen compilando durante 1.x, con el aviso <code>MEEK109</code>; en <code>2.0</code> serán un error. Reemplazo: las opciones de ruta en <code><script server></code> o en un sidecar <code>*.route.ts</code>, y el código de servidor en <code><script server></code> o en <code>server/</code>, con <code>import type</code> para los tipos. Véase <a href="/docs/stability#apis-deprecadas">docs/stability.md</a>.</li> </ul> <h3 id="documentación-1">Documentación<a class="heading-anchor" href="#documentaci%C3%B3n-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Nueva sección <a href="/docs/framework#errores">Errores</a> en la guía del framework: qué captura cada nivel (componente, aplicación, página, API y RPC, runtime del servidor y proceso), con su observador y su política. Las pruebas confirman que un fallo del render SSR o de una página <code>render: "stream"</code> y un diferido rechazado de un stream (en el documento y en la navegación) llegan a <code>+error.meeko</code> o al cliente como <code>{ code, status }</code>, y al <code>onError</code> del runtime y de los plugins con el <code>requestId</code> de la respuesta.</li> </ul> <h2 id="120---2026-10-27">[1.2.0] - 2026-10-27<a class="heading-anchor" href="#120---2026-10-27" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.1</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.2">Actualizar de 1.1 a 1.2</a>.</p> <h3 id="añadido-5">Añadido<a class="heading-anchor" href="#a%C3%B1adido-5" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Head del documento: <code>document</code>, <code>useHead</code> y <code>useSeoMeta</code>.</strong> <code>document</code> en <code>meeko.config.ts</code> fija <code>lang</code> y el <code><head></code> común de todos los documentos (SSR, <code>"stream"</code>, <code>"prerender"</code>, errores y el shell de <code>"client"</code>). <code>useHead(input)</code> añade título, <code>titleTemplate</code>, <code>meta</code>, <code>link</code>, <code>script</code>, <code>style</code> y atributos de <code><html></code> y <code><body></code> desde páginas, layouts, <code>app.meeko</code>, componentes, composables y el nivel superior de <code><script server></code>; con un getter o una señal, el navegador actualiza el documento. <code>useSeoMeta</code> es el atajo tipado para descripción, Open Graph, Twitter y <code>canonical</code>. Las fuentes se combinan con una prioridad y una deduplicación documentadas, el servidor las escribe entre <code></code> y <code></code> con el nonce CSP, la hidratación las adopta sin duplicar y la navegación restaura lo que sustituía una página. Nuevos tipos <code>HeadInput</code>, <code>HeadMeta</code>, <code>HeadLink</code>, <code>HeadScript</code>, <code>HeadStyle</code>, <code>SeoMetaInput</code>, <code>DocumentConfig</code> y <code>DocumentHead</code>.</li> <li><strong>Módulos.</strong> <code>defineMeekoModule</code> crea módulos que configuran el proyecto desde código, como los de Nuxt: componentes, autoimports, plugins, middleware y handlers de servidor, layers, entradas de <code><head></code> (<code>meeko.addHead</code>, antes del <code>document</code> de la configuración), archivos públicos, plugins y configuración de Vite, y hooks del build. <code>modules</code> acepta un módulo, un paquete, una ruta o <code>[módulo, opciones]</code>; las opciones se combinan con <code>defaults</code> y la clave <code>meta.configKey</code> de <code>meeko.config.ts</code>, y <code>meta.compatibility</code> comprueba la versión de Meeko. El <code>setup</code> se ejecuta sólo en Node y nunca llega al navegador.</li> <li><strong>Plugins de aplicación.</strong> <code>definePlugin</code> en <code>app/plugins</code> (o añadido por un módulo) se ejecuta en orden antes de renderizar en el servidor y antes de hidratar en el navegador, con <code>provide</code> para todos los componentes y <code>onError</code> como observador de la aplicación. Los sufijos <code>.server</code> y <code>.client</code> limitan un plugin a un lado.</li> <li><strong><code>layers</code>.</strong> Nuevo nombre de <code>extends</code> (que sigue funcionando como alias) para las carpetas con la estructura de la aplicación; sus páginas se muestran dentro del shell del proyecto y los layouts propios se anidan dentro.</li> <li><strong>Props reactivas.</strong> Cuando el padre cambia una prop, el hijo sigue montado y sólo se actualizan los bindings que la leen: se conservan el DOM, el foco, el cursor y la composición de un <code><input></code>, el estado, los snippets y los hijos anidados. <code>props</code> es una vista de sólo lectura (escribir en ella lanza <code>TypeError</code>) y los defaults se aplican en cada lectura. Se siguen montando de nuevo los cambios de <code><component is></code>, de modelos o de presencia de snippets, y los componentes con un <code>await</code> de datos en el nivel superior. El SSR y la hidratación no cambian (véase <a href="/docs/api#props-reactivas">docs/api.md</a>).</li> <li><strong>Aviso <code>MEEK101</code>: props leídas una sola vez.</strong> <code>meeko check</code>, <code>meeko build</code> y el editor avisan cuando el setup desestructura o expande <code>props</code>, o lee <code>props.x</code> en su nivel superior o directamente en <code>onMounted</code>: con las props reactivas, ese valor no sigue a la prop. Es el primer diagnóstico de tipo aviso: <code>CompileDiagnostic</code> gana <code>severity: "warning"</code> y <code>CompileResult</code> gana <code>warnings</code>, y un aviso no hace fallar la comprobación. No avisan las lecturas en funciones, <code>computed</code> o <code>effect</code>, las llamadas a una prop función, <code>signal(props.x)</code> ni los componentes con un <code>await</code> de datos en el nivel superior. <code>untrack</code> se autoimporta, como el resto de la reactividad, para declarar una lectura única intencionada: <code>untrack(() => props.x)</code>.</li> <li><strong><code>.env</code> del proyecto.</strong> <code>meeko dev</code>, <code>build</code>, <code>start</code>, <code>preview</code> y <code>check</code> cargan el <code>.env</code> de la raíz en <code>process.env</code>, como Vite y Nuxt en desarrollo: <code>MEEKO_PORT</code>, <code>MEEKO_PUBLIC_ORIGIN</code>, <code>MEEKO_LINK_WATCH</code> o las variables de la propia aplicación ya no hay que exportarlas en la terminal. El entorno real tiene prioridad, y la salida de <code>meeko build</code> ejecutada directamente no lee <code>.env</code>.</li> <li><strong><code><MeekoOutlet /></code> y <code><MeekoLink></code>.</strong> Dos etiquetas propias que el compilador reconoce sin import. <code><MeekoOutlet /></code> pinta, en <code>app.meeko</code> y en los layouts, el layout o la página de dentro sin declarar <code>defineProps<{ outlet }>()</code> (sustituye a <code><component is="props.outlet"></code>). <code><MeekoLink to="/users/[id]" bind:params="{ id }"></code> renderiza un <code><a></code> con el <code>href</code> de <code>href()</code>: sólo rutas existentes, <code>params</code> obligatorios en las dinámicas, <code>aria-current="page"</code> en la ruta activa y el resto de atributos (<code>class</code>, <code>aria-*</code>, <code>data-*</code>, <code>on:click</code>) en el <code><a></code>. Los errores se marcan en <code>to</code>; nuevos códigos <code>MEEK104</code> y <code>MEEK105</code>. El starter de <code>meeko init-framework</code> las usa.</li> <li><strong><code>definePage</code> y las definiciones de servidor sin import.</strong> <code>definePage</code>, <code>defineRouteMiddleware</code> y <code>definePlugin</code> se autoimportan, y en <code>server/</code> y <code><script server></code> también <code>defineApiRoute</code>, <code>defineRpc</code>, <code>defineServerMiddleware</code>, <code>defineSocketChannel</code>, <code>defineServerRuntime</code> y <code>ApiError</code>. El descubrimiento de contratos ya leía la llamada por su nombre, así que los contratos no cambian; las de servidor nunca llegan al código del navegador. La página de <code>meeko init-framework</code> deja de importar <code>definePage</code>.</li> <li><strong><code>app/types</code> se autoimporta.</strong> Los tipos que sólo usa la aplicación (por ejemplo, las variantes de un botón) se usan sin import en componentes, páginas y módulos de <code>app/</code>, en cliente y SSR, con <code>import type</code>. Como el resto de <code>app/</code>, no llegan a <code>shared/</code>; los tipos comunes con el servidor siguen en <code>shared/types</code>.</li> <li><strong>Navegación en el editor.</strong> Las cadenas de <code>href</code>, <code>useApi</code>, <code>useApiMutation</code>, <code>useRpcQuery</code> y <code>useRpcMutation</code> enlazan a su página o handler; la búsqueda de símbolos del workspace encuentra componentes, páginas, endpoints y procedimientos; y unas pistas en línea muestran el tipo del elemento de <code>each:as</code> y de los parámetros de <code><snippet params></code>.</li> <li><strong>Acciones rápidas nuevas en el editor.</strong> Para <code>MEEK101</code>, convertir la copia de una prop en <code>computed</code> (con <code>.value</code> en cada uso, también en la plantilla) o declarar la lectura única con <code>untrack</code>; para <code>MEEK022</code>, añadir <code>each:as</code> con el singular de la lista, aunque el componente no compile; y, en una etiqueta de componente que no existe, crearlo en <code>app/components</code> con una prop tipada por cada <code>bind:</code>.</li> <li><strong>HTML y CSS en el editor.</strong> El servidor de lenguaje completa las etiquetas, los atributos HTML y sus valores en la plantilla, con la documentación de MDN en el hover, y los eventos del DOM tras <code>on:</code> en un elemento; renombra juntas la etiqueta de apertura y la de cierre y responde <code>meeko/tagComplete</code> para cerrarlas. En <code><style></code>, completado, hover, diagnósticos de CSS y colores. En <code>class="…"</code> completa las clases de <code><style></code> e ir a definición lleva a sus selectores; en <code><style scoped></code> marca como sin uso las clases que no nombran ni la plantilla ni el script (<code>MEEK_UNUSED_CLASS</code>); un prefijo antes de una interpolación (<code>`badge--${tone}`</code>) cubre las clases que empiezan por él. TypeScript sólo responde a <code>/</code>, <code><</code> y las comillas donde significan algo, como en una ruta de <code>href("…")</code>.</li> <li><strong>Completado de directivas en el editor.</strong> En el nombre de un atributo de la plantilla, el servidor de lenguaje ofrece <code>if:when</code>, <code>each:of</code>, <code>each:as</code>, <code>each:key</code>, <code>each:index</code>, <code>bind:</code>, <code>on:</code> y <code>ref:</code> en cualquier etiqueta, también en las de componente, <code>html</code> en los elementos, <code>model</code> en los controles de formulario y <code>model:</code> en los componentes, sin repetir las que la etiqueta ya tiene.</li> <li><strong><code>idempotencyKey</code> en <code>api.*</code> y <code>rpc.*</code>.</strong> Una llamada puede enviar su propia cabecera <code>Idempotency-Key</code>; un valor que no es UUID rechaza con <code>TypeError</code> sin enviar nada.</li> <li><strong><code>onSuccess</code> y <code>onError</code> en <code>useRpcMutation</code> y <code>useApiMutation</code>.</strong> Avisan de cada intento, también de los reintentos de <code>retrySafe</code>, con <code>input</code>, <code>idempotencyKey</code> y <code>trigger</code>. Nuevos tipos <code>MutationAttempt</code> y <code>MutationFailure</code>; <code>MutationOptions</code> gana parámetros de tipo opcionales.</li> <li><strong>Duración propia de cada sesión.</strong> <code>context.session.create(data, { ttlMs })</code> fija la duración de esa sesión (un entero positivo de milisegundos; uno no válido rechaza con <code>RangeError</code>), por ejemplo 30 días para los propietarios y 12 horas para el personal. Determina el <code>Max-Age</code> de la cookie y la caducidad en el store, se guarda en el campo opcional <code>SessionRecord.ttlMs</code> y <code>rotate()</code> la conserva. Sin la opción, y en los registros anteriores, se usa <code>SessionManager.ttlMs</code>, como hasta ahora. <code>SqlSessionStore</code> (y con él <code>D1SessionDriver</code>) deduce la duración de <code>expiresAt - createdAt</code>, sin migrar el esquema. Nuevo tipo <code>SessionCreateOptions</code> (véase <a href="/docs/framework#duraci%C3%B3n-de-cada-sesi%C3%B3n">docs/framework.md</a>).</li> <li><strong><code>origin: "required"</code> en <code>defineApiRoute</code> y <code>defineRpc</code>.</strong> Exige un <code>Origin</code> permitido (el de la petición o <code>publicOrigin</code>, o uno de <code>SessionManager.allowedOrigins</code>) aunque no haya sesión: en los métodos <code>POST</code>, <code>PUT</code>, <code>PATCH</code> y <code>DELETE</code> de una ruta de API y en toda llamada RPC. Si falta o no está permitido, responde <code>403 INVALID_ORIGIN</code> antes de validar la entrada. Protege los inicios de sesión frente al <em>login CSRF</em> sin comprobaciones a mano. Los clientes de servidor del SSR siguen funcionando (véase <a href="/docs/framework#origin-en-mutaciones-an%C3%B3nimas">docs/framework.md</a>).</li> <li><strong>Mensajes de validación en las respuestas <code>400</code>.</strong> <code>INVALID_PARAMS</code>, <code>INVALID_QUERY</code>, <code>INVALID_BODY</code> e <code>INVALID_INPUT</code> añaden <code>issues: [{ path, message }]</code> con los mensajes del schema (como mucho 20; <code>path</code> son las claves unidas con <code>.</code>, o <code>""</code>). No viajan valores, expectativas ni trazas, y los fallos de <code>response</code>/<code>output</code> siguen siendo <code>500</code> sin detalle. En el cliente, <code>ClientError.issues</code> (tipo <code>ValidationIssue</code>, de sólo lectura, <code>undefined</code> si no hay) llega desde <code>api.*</code>, <code>rpc.*</code>, <code>useApi</code>, <code>useRpcQuery</code> y <code>useRpcMutation</code> (véase <a href="/docs/framework#errores-de-validaci%C3%B3n-en-formularios">docs/framework.md</a>).</li> <li><strong><code>locals</code> en <code>defineApiRoute</code> y <code>defineRpc</code>.</strong> <code>locals(context)</code> se ejecuta tras Origin, CSRF, <code>auth</code>, <code>authorize</code> y la validación de la entrada, y su valor llega al handler como <code>locals</code>, con el tipo inferido; un <code>ApiError</code> que lance es la respuesta. Sin <code>locals</code>, el handler recibe <code>undefined</code>. <code>ApiRouteDefinition</code> y <code>RpcDefinition</code> ganan el parámetro de tipo opcional <code>L</code> (véase <a href="/docs/framework#valores-por-petici%C3%B3n-locals">docs/framework.md</a>).</li> <li><strong>Eventos de plantilla tipados por elemento.</strong> En un elemento HTML o SVG, el manejador de <code>on:evento</code> recibe el tipo de <code>HTMLElementEventMap</code> (o <code>SVGElementEventMap</code>) para ese nombre, no sólo para los ocho eventos que se tipaban hasta ahora, y <code>event.currentTarget</code> tiene el tipo del elemento de la etiqueta, el mismo que da <code>ref:</code> (<code>HTMLInputElement</code>, <code>HTMLSelectElement</code>, <code>HTMLElement</code> en un elemento personalizado…). <code>on:input="(event) => query.value = event.currentTarget.value"</code>, el patrón de la documentación, ya pasa <code>meeko check</code> y el editor sin conversiones. El tipo nuevo es más preciso que el anterior, así que un manejador que era válido lo sigue siendo; sólo una conversión explícita a otro elemento (<code>event.currentTarget as HTMLSelectElement</code> en un <code><input></code>) puede dar ahora un error de tipos. Las etiquetas de componente no cambian. Es una excepción aprobada de SemVer, sólo de tipos y sin cambio en ejecución, registrada en <a href="/docs/stability#excepciones-aprobadas">docs/stability.md</a>.</li> <li><strong><code>model</code> con <code>bind:type</code> en <code><input></code>.</strong> El control se trata siempre como uno de texto (<code>value</code>, en <code>input</code>, con una señal <code>string</code>) aunque cambie el tipo, por ejemplo en un campo de contraseña que muestra su texto. Un tipo sin valor de texto (<code>checkbox</code>, <code>radio</code>, <code>file</code>, <code>submit</code>, <code>reset</code>, <code>button</code>, <code>image</code>) no se admite: el modelo no toca ni la señal ni el control, la hidratación lanza un <code>TypeError</code> si el control ya lo tiene y, si lo toma después, el error llega al observador de errores más cercano. <code>MEEK065</code> ya no rechaza <code>bind:type</code>, pero sí <code>bind:type</code> junto a <code>type="..."</code> en el mismo <code><input></code>; <code>bind:multiple</code> sigue rechazado (véase <a href="/docs/api#controles-de-formulario-con-model">docs/api.md</a>).</li> <li><strong><code>useRoute()</code></strong> en <code>@meekojs/meeko/framework</code>, también autoimportado: devuelve la ruta confirmada que renderiza el componente, con una señal de sólo lectura por valor (tipo <code>RouteState</code>): <code>url</code> (URL relativa al origen, con el fragmento en el navegador), <code>path</code>, <code>id</code> (<code>null</code> en la página <code>404</code> de <code>app/error.meeko</code>), <code>params</code> y <code>search</code>, con la misma forma que reciben las páginas. En SSR son los de la petición, también en layouts, <code>app/app.meeko</code>, rutas <code>"prerender"</code> y layouts de rutas <code>"client"</code>; el navegador hidrata con los mismos valores y los actualiza sólo al confirmar una navegación, también por el historial y al cambiar sólo el fragmento, y el render previo de la navegación ya ve la ruta de destino. Fuera de una aplicación lanza un error. Un export propio llamado <code>useRoute</code> en las carpetas de autoimports tiene prioridad sobre el del framework, así que no se vuelve ambiguo. Véase <a href="/docs/framework#ruta-actual">Ruta actual</a>.</li> <li><strong><code>status</code> en <code>defineApiRoute</code></strong> (<code>200</code>, <code>201</code>, <code>202</code> o <code>204</code>): responde, por ejemplo, <code>201 Created</code> sin perder la validación con <code>response</code> ni el tipo del cliente generado. Con <code>204</code> no hay cuerpo y <code>api.*</code> resuelve <code>undefined</code>. El generador exige un literal y <code>generateOpenApi</code> documenta el estado. Nuevo tipo <code>ApiSuccessStatus</code> y nuevo código <code>INVALID_RESPONSE_STATUS</code> para un <code>status</code> mal declarado.</li> <li><strong>Broadcast tipado desde el servidor.</strong> En el código de servidor (API, RPC, <code><script server></code>, middleware y handlers de Socket), el autoimport <code>socket</code> ofrece <code>socket.<canal>.broadcast(sala, evento, payload)</code>, tipado por el contrato del canal y con las mismas comprobaciones que <code>hub.broadcast</code>. Fuera de una petición, <code>createServerSocketRegistry(socketContracts, { hub: () => app.socket?.hub })</code>. Nuevos <code>createServerSocketRegistry</code>, <code>ServerSocketRegistry</code>, <code>ServerSocketRegistryOptions</code> y <code>SocketBroadcaster</code>.</li> <li><strong>Desestructuración en el <code><script></code>.</strong> <code>const { a, b: c = 1, ...rest } = useX()</code> y <code>const [x, , ...ys] = pair()</code> en el nivel superior. Cada nombre es un enlace del setup para la plantilla y los tipos; las señales desestructuradas no entran en la captura de estado de SSR y HMR, porque pertenecen al composable que las devolvió. <code>defineProps</code> y <code>useElementRef</code> siguen necesitando un nombre simple (<code>MEEK015</code>, con un mensaje específico).</li> <li><strong><code>if:when</code> estrecha tipos</strong> en <code>meeko check</code> y en el editor, como <code>v-if</code>: <code><p if:when="user.value">{user.value.name}</p></code> ya no necesita <code>!</code>. Alcanza a atributos, props, eventos, contenido, listas y snippets anidados, sin cambiar el código de ejecución.</li> <li><strong>Utilidades CSS generadas con TypeScript: <code>@meekojs/meeko/postcss</code>.</strong> Nuevo subpath con el plugin de PostCSS <code>meekoUtilities()</code>. La at-rule <code>@utilities "./utilities/color.ts" layer(utilities);</code> (en la hoja global, en un archivo importado o en un <code><style></code> de un <code>.meeko</code>) se sustituye por las reglas que devuelve la función exportada por un módulo <code>.ts</code>, <code>.mts</code>, <code>.js</code> o <code>.mjs</code>, relativo a esa hoja. <code>defineUtilities</code> tipa la función, que puede ser <code>async</code> y recibe los helpers <code>rule</code>, <code>atRule</code> (para <code>@media</code>, <code>@supports</code>…) y <code>css</code>, con anidamiento, declaraciones como objeto (camelCase a kebab-case, <code>--*</code> sin cambios, <code>undefined</code> omite) y <code>layer(x)</code> para envolver el resultado en <code>@layer x</code>. Con Vite 8 el módulo se empaqueta con rolldown, el bundler que Vite ya incluye, así que editarlo, o editar un módulo local que importa, actualiza el CSS en <code>meeko dev</code> sin reiniciar. Los errores (módulo inexistente, export que no es una función, una excepción, un selector o un valor no válidos) se muestran en la línea del <code>@utilities</code>. Va antes de <code>@tailwindcss/postcss</code>, y avisa si Tailwind se ejecuta primero; nunca forma parte del runtime (véase <a href="/docs/framework#utilidades-generadas-con-typescript">docs/framework.md</a>).</li> <li><strong>Segmentos dinámicos invocables en <code>api.*</code>.</strong> <code>server/api/menu/categories/[id]/archive.post.ts</code> se llama <code>api.menu.categories({ id }).archive.post()</code>, y los segmentos se encadenan: <code>api.orgs({ org }).users({ id }).get()</code>. La llamada exige el parámetro de su segmento y los métodos que siguen ya no reciben <code>params</code>; <code>query</code>, <code>body</code> y <code>signal</code> no cambian y la URL se construye igual. Un catch-all recibe la ruta unida por <code>/</code>. El editor completa la llamada y lleva al handler. <code>useApi</code> no cambia.</li> <li><strong><code>useForm()</code></strong>, también autoimportado: una señal por campo para <code>model</code>/<code>model:value</code>, validación al enviar con cualquier Standard Schema, los <code>issues</code> de un <code>400</code> en cada campo (<code>errors</code>, con rutas como <code>"items.0.name"</code>) y el resto en <code>error</code>, más <code>failure</code>, <code>pending</code>, <code>submitted</code>, <code>dirty</code> y <code>reset()</code>. <code>form.submit(event)</code> hace <code>preventDefault</code>, ignora un segundo envío en curso y no envía en SSR. Nuevo tipo <code>Form</code>.</li> <li><strong><code>useStorage(clave, inicial, opciones?)</code></strong>, también autoimportado: una señal guardada en JSON en <code>localStorage</code> (o <code>sessionStorage</code>), con un schema opcional para validar lo leído. El SSR y la hidratación usan <code>inicial</code> y el valor guardado llega justo después de hidratar, antes de <code>onMounted</code>; otras pestañas se sincronizan por el evento <code>storage</code>; un almacenamiento bloqueado nunca lanza. Nuevos tipos <code>StorageOptions</code> y <code>StorageArea</code>.</li> <li><strong>Mutaciones seguras ante reintentos.</strong> <code>useRpcMutation(proc, { retrySafe: { key } })</code> y el nuevo <code>useApiMutation(ruta, método, opciones?)</code> guardan la intención y la envían con la cabecera <code>Idempotency-Key</code>; sin respuesta (red, <code>5xx</code>, <code>408</code>, <code>429</code>) la conservan en <code>uncertain</code> y la reintentan con la misma clave al volver <code>online</code>, al montarse o con <code>retry()</code>; <code>discard()</code> la olvida. En el servidor, <code>context.idempotencyKey</code> expone la clave validada (Meeko no deduplica). Nuevos <code>createUseApiMutation</code>, <code>ApiMutation</code>, <code>ApiMutationInput</code>, <code>ApiMutationContract</code>, <code>UseApiMutation</code>, <code>MutationOptions</code>, <code>RetrySafeOptions</code>, <code>RetrySafeMutation</code> y <code>UncertainMutation</code>.</li> <li><strong><code>meeko dev</code> se reinicia al reconstruir un Meeko enlazado</strong> (<code>link:</code> de pnpm, <code>npm link</code> o un workspace): vigila <code>dist/</code> y <code>package.json</code> del paquete y, cuando el build termina, cierra el servidor anterior y arranca otro en el mismo puerto. <code>MEEKO_LINK_WATCH=0</code> lo desactiva.</li> <li><strong>Puerto libre en <code>meeko dev</code>.</strong> Sin <code>PORT</code> ni <code>server.port</code>, usa el primer puerto libre desde <code>4173</code> (hasta <code>4192</code>), avisa del cambio y deriva de él el HMR y el puente con el editor. Un puerto fijado que está ocupado termina con un mensaje que lo nombra.</li> <li><strong>Sentencias en el setup.</strong> El nivel superior del <code><script></code> admite cualquier sentencia de expresión (<code>count.value = props.initial</code>, <code>void Child</code>) y <code>if</code>, bucles, <code>try</code>, <code>switch</code>, bloques y sentencias etiquetadas, como la continuación de navegador. <code>useElementRef</code>, <code>useApi</code>, <code>useRpcQuery</code> y <code>useRpcMutation</code> dentro de ellas dan <code>MEEK054</code>.</li> <li><strong><code>css.scopeAttribute</code></strong> en <code>meeko.config.ts</code> (y <code>scopeAttribute</code> en <code>compile()</code>): con <code>"matched"</code>, <code><style scoped></code> pone <code>data-meeko-s-<hash></code> sólo en los elementos que algún selector con ámbito puede seleccionar, con los mismos estilos y menos HTML (en el sitio, 2.650 → 2.216 atributos). En 1.x el valor por defecto sigue siendo <code>"all"</code>; será <code>"matched"</code> en 2.0.</li> <li><strong>Sesiones sin configuración.</strong> Sin <code>server/runtime.ts</code>, o si no devuelve <code>sessions</code>, Meeko crea las sesiones: en memoria en desarrollo y, en producción (Node, Bun y Deno), en Redis con <code>MEEKO_REDIS_URL</code>. Importa el paquete <code>redis</code> del proyecto, conecta un cliente y un suscriptor de revocaciones antes de servir, usa el prefijo <code>MEEKO_REDIS_PREFIX</code> o <code>meeko:<name>:prod:</code> y cierra ambas conexiones al detenerse; sin conexión, las peticiones fallan en el acto. <code>MEEKO_SESSION_TTL</code> (<code>12h</code>, <code>7d</code>…) y <code>MEEKO_SESSION_SAMESITE</code> (<code>Lax</code> o <code>Strict</code>) ajustan esas sesiones. Sin store persistente, la producción sigue sin arrancar, y unas <code>sessions</code> explícitas siempre ganan. <code>ServerRuntime.sessions</code> pasa a ser opcional y <code>ServerAppOptions</code> gana <code>appName</code> y <code>loadRedis</code>, que pasa la entrada generada. El starter de <code>meeko init-framework</code> ya no crea <code>server/runtime.ts</code> y añade <code>.env.example</code> (véase <a href="/docs/framework#sesiones-sin-configuraci%C3%B3n">docs/framework.md</a>).</li> <li><strong>Contraseñas: <code>@meekojs/meeko/password</code> y <code>meeko auth hash</code>.</strong> <code>hashPassword</code>, <code>verifyPassword</code> y <code>needsRehash</code> usan scrypt (N = 2^17, r = 8, p = 1) en el formato autodescriptivo <code>scrypt$<N>$<r>$<p>$<sal>$<hash></code>, comparan en tiempo constante, limitan a dos los cálculos simultáneos y aceptan los hashes con ese formato escritos antes a mano. La subruta importa <code>node:crypto</code> (Node, Bun y Deno), así que <code>/server</code> sigue siendo portable. <code>meeko auth hash</code> pide la contraseña sin eco (o la lee de stdin) e imprime sólo el hash (véase <a href="/docs/framework#contrase%C3%B1as">docs/framework.md</a>).</li> <li><strong><code>rateLimit</code> en <code>defineApiRoute</code> y <code>defineRpc</code>.</strong> <code>{ limit, window, key? }</code> limita las peticiones por ventana fija y responde <code>429 RATE_LIMITED</code> con <code>Retry-After</code>, tras Origin y CSRF y antes de <code>auth</code>, la entrada y el handler. Sin <code>key</code>, cuenta por IP de cliente (IPv6 por /64) o, si no se conoce, en un contador común de la ruta. Los contadores viven en el store de sesiones: memoria o Redis, con un script atómico bajo el mismo prefijo y la clave resumida con SHA-256; si el store falla, la petición se rechaza. Nuevo método opcional <code>SessionStore.rateLimit</code> (y <code>SessionManager.rateLimit</code>), implementado por <code>MemorySessionStore</code> y <code>RedisSessionStore</code>; nuevos tipos <code>RateLimitOptions</code> y <code>RateLimitHit</code>. <code>RequestContext.clientAddress</code> expone la IP: la de la conexión (los adaptadores de Node, Bun y Deno la entregan; en Workers, <code>CF-Connecting-IP</code>) o, con <code>MEEKO_TRUST_PROXY</code> (número de proxies o <code>true</code>), la de <code>X-Forwarded-For</code>, que sin esa variable nunca se lee. <code>BunServerLike</code> gana <code>requestIP</code> opcional (véase <a href="/docs/framework#l%C3%ADmite-de-peticiones-ratelimit">docs/framework.md</a>).</li> <li><strong>Datos de sesión tipados: <code>MeekoSession</code>.</strong> Una aumentación de módulo (<code>declare module "@meekojs/meeko/server" { interface MeekoSession { user: string } }</code>) tipa <code>context.session.current.data</code> y <code>context.session.create(data)</code> en el <code><script server></code> de las páginas (<code>usePage().context</code>), API, RPC, Socket, <code>authorize</code> y <code>locals</code>, sin <code>as</code>. Sin declaración, los datos siguen siendo <code>unknown</code>. <code>RequestContext.session</code> pasa a ser <code>SessionHandle<SessionData></code> y <code>SessionHandle</code> toma <code>SessionData</code> como tipo por defecto; nuevos tipos <code>MeekoSession</code> y <code>SessionData</code>.</li> </ul> <h3 id="cambios-6">Cambios<a class="heading-anchor" href="#cambios-6" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Un marcador de hidratación por elemento.</strong> Cada elemento con bindings lleva un único <code>data-meeko="N"</code> en lugar de un atributo por binding (<code>data-meeko-a-N</code>, <code>data-meeko-e-N</code>, <code>data-meeko-m-N</code> y <code>data-meeko-r-N</code>): el HTML pesa menos y el runtime busca el elemento una sola vez para todos sus atributos, eventos, modelos y referencias. Los atributos son internos; sólo cambia algo para quien los leía desde CSS o pruebas.</li> <li><strong><code><MeekoLink></code> estático conserva su <code>href</code> en el HTML.</strong> Con un <code>to</code> sin segmentos dinámicos ni <code>bind:params</code>/<code>bind:search</code>, el SSR escribe el <code>href</code> directamente y sólo <code>aria-current</code> queda enlazado, así que el enlace funciona sin JavaScript y lo siguen los rastreadores.</li> <li><strong>Resolución de módulos <code>Bundler</code>.</strong> <code>meeko check</code>, el editor y los <code>tsconfig</code> que genera Meeko usan <code>"module": "ESNext"</code> y <code>"moduleResolution": "Bundler"</code> en lugar de <code>NodeNext</code>: un import relativo ya no necesita <code>.js</code> (<code>import { format } from "../utils/format"</code>), como en Vite y Nuxt. Los imports con <code>.js</code> siguen funcionando y <code>meeko init-framework</code> genera el <code>tsconfig.json</code> nuevo; un proyecto existente puede cambiar esas dos líneas de su <code>tsconfig.json</code>.</li> <li><strong>Lo que el setup copia de una prop conserva el valor inicial.</strong> Con las props reactivas, <code>const { label } = props</code> o <code>props.x.toUpperCase()</code> en el setup ya no se recalculan: hasta <code>1.1</code> el hijo se reconstruía con cada cambio. Use <code>{props.x}</code>, <code>computed</code> o una función en <code>useApi</code>/<code>useRpcQuery</code>. Es una excepción aprobada de SemVer, registrada en <a href="/docs/stability">docs/stability.md</a>.</li> <li><strong>Estado de las mutaciones.</strong> Cada envío vacía <code>error</code> al empezar; el resultado escribe <code>data</code> o <code>error</code>, <code>pending</code> y <code>uncertain</code> en una sola actualización, y <code>discard()</code> vacía <code>error</code>.</li> <li><strong>Props opcionales y <code>undefined</code>.</strong> Una prop opcional acepta <code>undefined</code> desde <code>bind:</code> también con <code>exactOptionalPropertyTypes</code> (<code>bind:error="cond ? 'x' : undefined"</code>), y el hijo recibe su default de <code>defineProps</code>. Las props obligatorias y las desconocidas siguen siendo errores.</li> <li><strong><code>defineSocketChannel</code> acepta la forma abreviada</strong> de propiedades (<code>serverToClient: { kitchenChanged }</code>) con schemas importados de <code>shared/</code>.</li> <li><strong>Diagnósticos de contratos en español.</strong> Los del descubrimiento y la generación de contratos de API, RPC y Socket (<code>meeko routes</code>, <code>meeko check</code>, <code>meeko dev</code>).</li> <li><strong><code>socket.<canal></code> en el servidor.</strong> Leerlo ya no lanza un error; lo lanzan <code>on</code>, <code>emit</code>, <code>state</code> y <code>close</code>, porque en el servidor no hay conexión.</li> <li><strong>El manifiesto rechaza segmentos ambiguos del cliente de API:</strong> un segmento estático con el mismo nombre que el segmento dinámico de su nivel (<code>users/byId/</code> junto a <code>users/[id]</code>) o dos parámetros que sólo cambian en la inicial.</li> <li><strong>Servidor de lenguaje y extensión de VS Code:</strong> los cambios en paquetes enlazados dentro de <code>node_modules</code> o en proyectos bajo un <code>.meeko/</code> ya no disparan comprobaciones de contratos en ellos, y los valores en vivo ya no se conectan a <code>meeko dev</code> de esos proyectos.</li> <li><strong>Repositorio como workspace de pnpm.</strong> El paquete vive ahora en <code>packages/meeko</code>, junto a la extensión de VS Code (<code>packages/vscode</code>), la de Chrome DevTools (<code>packages/devtools</code>) y el sitio (<code>apps/site</code>). Nada cambia para quien instala <code>@meekojs/meeko</code> desde npm; un proyecto que enlaza un checkout local con <code>link:</code> debe apuntar a <code><checkout>/packages/meeko</code>.</li> <li><strong>Prefijo <code>MEEKO_</code> en las variables de entorno.</strong> Todas las variables que lee Meeko empiezan por <code>MEEKO_</code>: <code>MEEKO_HOST</code>, <code>MEEKO_PORT</code> y <code>MEEKO_PUBLIC_ORIGIN</code> sustituyen a <code>HOST</code>, <code>PORT</code> y <code>PUBLIC_ORIGIN</code> en <code>meeko dev</code>, <code>start</code> y <code>preview</code>, en las salidas de Node, Bun y Deno y en el Worker (<code>vars</code> de <code>wrangler.jsonc</code>). <code>PORT</code> sigue valiendo sin aviso, porque la inyectan plataformas como Coolify, Railway o Cloud Run. El mensaje de puerto ocupado propone <code>MEEKO_PORT=<otro puerto></code>. El prefijo queda reservado: las variables propias de la aplicación deben usar otro nombre.</li> </ul> <h3 id="seguridad-2">Seguridad<a class="heading-anchor" href="#seguridad-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Login CSRF bloqueado por defecto en <code>session.create()</code>.</strong> En una petición <code>POST</code>, <code>PUT</code>, <code>PATCH</code> o <code>DELETE</code>, <code>context.session.create()</code> sólo crea la sesión si su <code>Origin</code> ya se comprobó (<code>origin: "required"</code> o una mutación autenticada que superó Origin y CSRF) o está permitido en ese momento; si no, rechaza con <code>403 INVALID_ORIGIN</code> sin tocar el store. Así, otra web no puede iniciar sesión en el navegador de la víctima aunque la ruta no declare <code>origin: "required"</code>. Los navegadores envían <code>Origin</code> en esas peticiones, así que las aplicaciones web no cambian. <strong>Migración:</strong> un script, una prueba o una app nativa que inicia sesión debe enviar el <code>Origin</code> de la aplicación, o la ruta declarar <code>origin: "none"</code> (nuevo, documentado como inseguro). <code>GET</code> sigue sin comprobarse, para los callbacks de OAuth y los enlaces mágicos. Una aplicación detrás de un proxy que termina TLS y sin <code>MEEKO_PUBLIC_ORIGIN</code> ve su inicio de sesión rechazado con <code>403</code>; esa aplicación ya fallaba en <code>1.1</code> en las mutaciones autenticadas, y se corrige igual, fijando <code>MEEKO_PUBLIC_ORIGIN</code>. Es una excepción aprobada de SemVer por seguridad, registrada en <a href="/docs/stability#excepciones-aprobadas">docs/stability.md</a> (véase <a href="/docs/framework#origin-en-mutaciones-an%C3%B3nimas">docs/framework.md</a>).</li> <li><strong><code>rateLimit</code> conserva la IP del cliente tras un middleware que sustituye la petición.</strong> Con un middleware de servidor habitual como <code>return next(new Request(request, { headers }))</code>, la petición nueva perdía la IP de la conexión: todos los clientes compartían el contador común de la ruta y uno solo podía bloquear el inicio de sesión de los demás. <code>next()</code> copia ahora la IP a la petición que recibe, igual que las peticiones que crean <code>createLocalCalls</code> y el handshake de Socket (también el de <code>createNodeSocketUpgradeHandler</code>).</li> </ul> <h3 id="correcciones-7">Correcciones<a class="heading-anchor" href="#correcciones-7" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong><code>meeko.config.ts</code> reescrito dos veces seguidas.</strong> La configuración se importaba con la fecha de modificación del archivo en la URL, así que dos escrituras dentro del mismo instante (un guardado rápido del editor) volvían a cargar la versión anterior desde la caché de módulos. Ahora la clave es un hash del contenido.</li> <li><strong>Errores del prerender legibles.</strong> Si una página lanzaba durante el prerender de <code>meeko build</code> o <code>meeko prerender</code>, la salida sólo decía <code>[meeko] request error <id> (Error)</code> y que la ruta respondió <code>500</code>, sin mensaje ni pila. Ahora el build falla con <code>Prerender <url> (<archivo de la ruta>) failed:</code> seguido del error con su pila y la cadena de <code>cause</code> («Caused by: …»), y el error original queda en <code>cause</code>. <code>prerenderRoutes</code> hace lo mismo cuando su <code>handler</code> rechaza. La política de las peticiones en producción no cambia: el observador por defecto sigue registrando sólo el nombre del error y el ID de la petición, salvo en desarrollo.</li> <li><strong><code>titleTemplate</code> de <code>document.head</code> tipado como cadena.</strong> <code>document.head</code> de <code>meeko.config.ts</code> y <code>meeko.addHead</code> de los módulos son ahora del nuevo tipo <code>DocumentHead</code>, en el que <code>titleTemplate</code> sólo es una cadena: una función, que el build no puede fijar como JSON y la ejecución ya rechazaba, es un error de TypeScript en la línea de <code>titleTemplate</code>, en el editor y en <code>meeko check</code>. Si la configuración no carga, <code>meeko check</code> y <code>meeko build</code> muestran primero los errores de tipos de <code>meeko.config.ts</code> con su línea y columna, y <code>meeko.addHead</code> valida su entrada al llamarse, con el nombre del módulo en el error. <code>useHead</code> sigue admitiendo la función.</li> <li><strong>El título del sitio no pasa por la plantilla.</strong> Con <code>title: "Mi Sitio"</code> y <code>titleTemplate: "%s - Mi Sitio"</code> en <code>document.head</code>, una página sin título mostraba «Mi Sitio - Mi Sitio». El <code>title</code> de <code>document.head</code> (y el de <code>meeko.addHead</code>) es ahora el título del sitio: se muestra tal cual en las páginas sin título propio, y la plantilla sólo se aplica a los títulos de <code>app.meeko</code>, los layouts, las páginas, <code>useHead</code> y el <code>head</code> de la ruta. Un título ganador vacío también muestra el del sitio, en lugar de « - Mi Sitio». Igual en SSR, al hidratar y al navegar (véase <a href="/docs/framework#head-del-documento-document-usehead-y-useseometa">Head del documento</a>).</li> <li><strong>Errores de <code>meeko.config.ts</code> en su archivo.</strong> En el editor, un error de validación de la configuración aparecía en la línea 1 de cada componente abierto. Ahora se marca en <code>meeko.config.*</code>, en la propiedad que nombra (por ejemplo, <code>titleTemplate</code> dentro de <code>document.head</code>), con el código <code>MEEK_CONFIG</code>, y desaparece cuando la configuración vuelve a cargar.</li> <li><strong>Declaraciones del proyecto en <code>meeko check</code> y en el editor.</strong> La comprobación de cada <code>.meeko</code> y el servidor de lenguaje no incluían los <code>.d.ts</code> de <code>app/</code>, <code>server/</code> y <code>shared/</code>, así que una aumentación de módulo (como <code>MeekoSession</code>) no llegaba al <code><script server></code> de una página ni a los <code>.ts</code> que importa, y daban errores falsos que los proyectos del servidor no daban. Ahora los incluyen.</li> <li><strong>PostCSS en los <code><style></code> de componentes.</strong> El CSS de un componente era un módulo virtual cuyo id empezaba por un byte nulo, y los plugins de PostCSS que resuelven archivos fallaban con él: Tailwind con <code>@reference</code> o <code>@apply</code>, o un <code>@import</code> relativo, dejaban la página en error 500 («The argument 'path' must be … without null bytes»). Ahora el módulo es <code>Componente.meeko?meeko-style=…&lang.css</code>, junto al archivo del componente, como en Vue.</li> <li><strong>Servidor de lenguaje más rápido.</strong> Los primeros diagnósticos de un <code>.meeko</code> tardaban más de 20 s en un proyecto con dependencias enlazadas, y cada completado en el script, unos 6 s. La resolución de módulos recorría <code>node_modules</code> en cada import sin caché, y los autoimports volvían a leer el <code>package.json</code> de cada paquete y a calcular cada ruta de import. Ahora el proyecto comparte una caché de resoluciones (con la de <code>package.json</code>) y la de rutas de import de tsserver, y devuelve el completado incompleto cuando TypeScript no resolvió todos los autoimports, como VS Code con TypeScript. En diegootayza y ordemi-meeko, los primeros diagnósticos bajan a unos 3 s y el completado, a menos de 1 s (0,1 s al repetirlo).</li> <li><strong>Imports que aparecen después.</strong> Crear el archivo de un import que no resolvía (o instalar su paquete) no quitaba el error «Cannot find module» hasta editar el archivo que lo importa: el servicio de lenguaje conservaba el programa con las resoluciones anteriores. Los cambios de archivos del proyecto, y ahora también de <code>package.json</code> y de los lockfiles, invalidan esas resoluciones.</li> <li><strong>Ventanas de consola en Windows.</strong> El servidor de lenguaje comprobaba los contratos de página con <code>tsc</code> en un proceso sin <code>windowsHide</code>; como VS Code no tiene consola, Windows abría una ventana cada vez. Ese proceso y el <code>tsc</code> de <code>meeko check</code> y <code>meeko build</code> se lanzan ahora ocultos, y una prueba exige <code>windowsHide</code> en todo proceso hijo.</li> <li><strong>Estilos globales duplicados en desarrollo.</strong> <code>meeko dev</code> cargaba <code>app/styles/main.css</code> dos veces: como <code><link></code> en el documento del servidor y como <code><style></code> que inyectaba el cliente de Vite. El <code><link></code> lleva ahora el id del módulo CSS (<code>data-vite-dev-id</code>), de modo que Vite lo adopta: no añade la copia y aplica el HMR sobre el propio enlace, sin que una regla borrada siga aplicándose desde la otra hoja.</li> <li><strong>Uniones en los clientes de API generados.</strong> <code>api.x.post({ body })</code> acepta un <code>body</code> tipado como la unión completa del schema (por ejemplo, un <code>v.variant</code> con varias formas), y lo mismo <code>params</code> y <code>query</code>; antes sólo compilaba un literal de una de las variantes. Una forma que no pertenece a la unión sigue siendo un error, y las reglas de argumentos opcionales no cambian. <code>rpc.x(input)</code>, <code>useApi</code>, <code>useRpcQuery</code> y <code>useRpcMutation().mutate</code> ya aceptaban uniones y se comprueban ahora en las pruebas.</li> <li><strong><code><form></code> con un componente autocerrado.</strong> Un <code><Componente /></code> dentro de un <code><form></code> hacía que <code></form></code> se compilara como texto y que el resto de la plantilla quedara dentro del formulario. El compilador enmascara ahora <code><form></code> mientras lee la plantilla, para que su cierre funcione como el de cualquier otro elemento.</li> <li><strong>Listas anidadas.</strong> Con tres o más <code>each:</code> anidados, la hidratación (y <code>meeko check</code>) leía en una lista interior el elemento de la lista que la contiene: cada lista nombraba su señal de elemento igual. Ahora cada lista usa nombres propios.</li> <li><strong>Orden de actualización de las regiones.</strong> Un <code>if:when="v.value"</code> que protege <code>{v.value!.n}</code> (o un atributo, una prop o las filas de un <code>each:</code>) lanzaba un <code>TypeError</code> al volverse <code>null</code>, porque el contenido se actualizaba antes que la condición que debía ocultarlo. Los observadores se ejecutan ahora en orden de creación, y cada región reserva su lugar antes de hidratar su contenido, de modo que se actualiza (y libera ese contenido) antes que él.</li> <li><strong><code>export</code> de valores en el <code><script></code></strong> (<code>export const</code>, <code>export function</code>, <code>export default</code>) generaban código inválido; ahora dan <code>MEEK018</code>. <code>defineProps</code> fuera de su propia declaración da <code>MEEK016</code> en vez de fallar en ejecución. Los autoimports ya no toman las etiquetas de <code>break</code>/<code>continue</code> como referencias.</li> <li><strong><code>aria-current</code> en un <code><MeekoLink></code> estático con caracteres no ASCII.</strong> Con <code>to="/categorías"</code>, el <code>href</code> del HTML era el literal sin codificar y nunca coincidía con <code>useRoute().path</code>, que es el <code>pathname</code> codificado (<code>/categor%C3%ADas</code>), así que el enlace no recibía <code>aria-current="page"</code>. El <code>href</code> estático se codifica ahora por segmentos como en <code>href()</code>, y la comparación usa la misma codificación en ambos lados.</li> <li><strong>Componentes propios llamados <code>MeekoLink</code> o <code>MeekoOutlet</code>.</strong> El compilador interceptaba siempre esas etiquetas, así que un proyecto de <code>1.1</code> con un componente con ese nombre (autoimportado de <code>app/components</code> o de un módulo, o importado o declarado en el <code><script></code>) cambiaba de comportamiento o fallaba con <code>MEEK104</code> o <code>MEEK105</code>. Ahora gana el componente del proyecto, y <code>meeko check</code>, <code>meeko build</code> y el editor avisan con el nuevo aviso <code>MEEK106</code> para renombrarlo y adoptar la etiqueta propia. El completado del editor trata esa etiqueta como un componente.</li> <li><strong>Hoja de estilos de un componente que ya no existe en <code>meeko dev</code>.</strong> Una pestaña abierta antes de reiniciar <code>meeko dev</code> pedía la hoja de estilos de un componente con un hash que el servidor no conocía; Vite leía entonces el <code>.meeko</code> como CSS y PostCSS fallaba. Ahora se sirve una hoja vacía con un aviso que pide recargar la página, sin romperla. Además, el servidor de desarrollo sólo conserva las dos últimas hojas de cada componente, en lugar de todas las que generaba cada edición.</li> <li><strong>Teclas especiales en <code>meeko auth hash</code>.</strong> El aviso de la contraseña sólo descartaba el carácter <code>ESC</code>, así que una flecha (<code>ESC [ A</code>) añadía <code>[A</code> a la contraseña y el hash no correspondía a lo que se creía escribir. Ahora descarta las secuencias de escape completas (flechas, Inicio, Supr, teclas de función, Alt+tecla, los marcadores del pegado entre corchetes y las secuencias OSC), también partidas entre lecturas, y cualquier otro carácter de control salvo Retroceso e Intro.</li> <li><strong><code>X-Forwarded-For</code> con puerto en <code>rateLimit</code>.</strong> Con <code>MEEKO_TRUST_PROXY</code>, una entrada con puerto, como la que escribe Azure Application Gateway (<code>203.0.113.7:5678</code> o <code>[2001:db8::1]:5678</code>), no se reconocía como IP y la petición caía en el contador común de la ruta. Ahora cuenta por su IP; una entrada que sigue sin ser una IP cuenta con la IP de la conexión, nunca con el contador común.</li> <li><strong><code>MEEKO_TRUST_PROXY</code> no válida en el entorno del adaptador.</strong> <code>createServerApp</code> ya la validaba al arrancar, pero <code>serveNode</code>, <code>createBunServer</code> y <code>serveDeno</code> sirven las peticiones con su propia plataforma (por defecto, <code>process.env</code>, <code>Bun.env</code> o <code>Deno.env</code>), y un valor no válido sólo ahí aparecía como <code>500</code> en cada ruta con <code>rateLimit</code> y en cada página que llamaba a la API en local. Esos adaptadores la validan ahora al arrancar.</li> <li><strong><code>createLocalCalls</code> y <code>rateLimit</code>.</strong> Las llamadas locales contaban en un contador propio (método y ruta concreta), distinto del que usa el despachador HTTP, así que no compartían el límite. Ahora usan el mismo contador de la ruta y la IP del <code>context</code> que reciben. Un host propio que crea sus peticiones sin un adaptador de Meeko no tiene IP de conexión: está documentado en <a href="/docs/framework#l%C3%ADmite-de-peticiones-ratelimit">Límite de peticiones</a>.</li> </ul> <h3 id="deprecado-1">Deprecado<a class="heading-anchor" href="#deprecado-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Carpetas de layer en <code>modules</code>.</strong> Una carpeta con <code>app/pages</code> listada en <code>modules</code> sigue funcionando como layer en toda la serie <code>1.x</code>, con un aviso; muévala a <code>layers</code>. Dejará de funcionar en <code>2.0</code>.</li> <li><strong><code>byId</code> en <code>api.*</code>.</strong> <code>api.users.byId.get({ params: { id } })</code> sigue funcionando durante 1.x y se retira en 2.0. Reemplazo: <code>api.users({ id }).get()</code>.</li> <li><strong>Variables <code>HOST</code> y <code>PUBLIC_ORIGIN</code>.</strong> Siguen funcionando durante 1.x cuando falta la variable nueva, con un aviso por proceso, y dejarán de leerse en 2.0. Reemplazos: <code>MEEKO_HOST</code> y <code>MEEKO_PUBLIC_ORIGIN</code>. <code>PORT</code> no está obsoleta: es el respaldo permanente de <code>MEEKO_PORT</code>.</li> </ul> <h3 id="documentación-2">Documentación<a class="heading-anchor" href="#documentaci%C3%B3n-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Guía de autenticación.</strong> <a href="/docs/framework#autenticaci%C3%B3n">docs/framework.md</a> muestra la aplicación mínima: <code>.env</code> con <code>MEEKO_REDIS_URL</code> y <code>MEEKO_PUBLIC_ORIGIN</code>, el tipo de la sesión, un inicio de sesión de diez líneas, el cierre y una página protegida.</li> <li><strong>Valibot, validador por defecto de la documentación.</strong> Meeko sigue aceptando cualquier Standard Schema (Valibot, Zod, ArkType…) sin cambios de API; la documentación lo explica en <a href="/docs/framework#api-y-rpc">API y RPC</a> y recomienda Valibot por ser pequeño y modular, y sus ejemplos y los de la referencia usan <code>import * as v from "valibot"</code>.</li> <li><strong>Todas las propiedades de los tipos públicos tienen descripción</strong> en el hover del editor, también las de <code>DevtoolsSnapshot</code>, <code>DevtoolsAssignmentSite</code>, <code>SocketUpgrade</code>, <code>PluginErrorInfo</code> o <code>MeekoServerConfig</code>; una prueba lo exige ahora para las interfaces y los tipos objeto exportados, como ya hacía con las clases.</li> </ul> <h2 id="110---2026-10-26">[1.1.0] - 2026-10-26<a class="heading-anchor" href="#110---2026-10-26" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Los cambios de comportamiento que se notan al actualizar desde <code>1.0</code>, con lo que hay que revisar en cada uno, se recogen en <a href="/docs/migration-1.1">Actualizar de 1.0 a 1.1</a>.</p> <h3 id="añadido-6">Añadido<a class="heading-anchor" href="#a%C3%B1adido-6" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li> <p><strong><code><script server></code> en las páginas.</strong> El bloque <code><script server lang="ts"></code> declara las opciones de ruta (<code>load</code>, <code>head</code>, <code>render</code>, <code>params</code>, <code>search</code>, <code>prerenderEntries</code>) dentro del propio <code>.meeko</code>, sin un sidecar <code>*.route.ts</code>. El componente compilado nunca lo incluye: se ejecuta en el servidor con sus autoimports y sólo llega al navegador en las rutas <code>render: "client"</code>. <code>meeko check</code> lo comprueba con TypeScript en el ámbito del servidor y compara su loader con las props de la página, con los errores en la línea del <code>.meeko</code>; el servidor de lenguaje le da diagnósticos, hover, completado, navegación, renombrado, símbolos y formato, y la gramática de VS Code resalta el atributo <code>server</code>. Los sidecars siguen funcionando, pero una página no puede declarar ambos. <code>meeko init-framework</code> genera la portada con este bloque. Nuevos diagnósticos <code>MEEK043</code> (<code>server</code> con valor) y <code>MEEK044</code> (bloque fuera de una página). En esas páginas, <code>RouteRecord.sidecar</code> (de <code>discoverRoutes</code> y del manifiesto) es el id de módulo <code><página>.meeko?meeko-route&lang.ts</code>, que sólo carga el plugin de Vite de Meeko, y no una ruta de archivo: una herramienta que lea <code>sidecar</code> del disco debe tratar ese caso.</p> </li> <li> <p><strong>Código de nivel superior en <code><script server></code>.</strong> Las sentencias del bloque se ejecutan en cada petición (SSR y datos de navegación), después del middleware y de validar <code>params</code> y <code>search</code>, con <code>await</code> de nivel superior. Cada <code>export const</code> o <code>export let</code> es un dato de la página que el <code><script></code> y la plantilla ven por su nombre, tipado y de sólo lectura, sin <code>definePage({ load })</code> ni <code>props.data</code>; sólo los exports llegan al navegador y se comprueban como JSON en <code>meeko check</code> y en ejecución. <code>export const head</code> fija el <code><head></code>. <code>usePage()</code> devuelve <code>{ url, params, search, request, context, signal }</code>, tipado por los schemas de <code>route</code>, y <code>redirect(url, status?)</code> y <code>notFound()</code> responden con una redirección o con la página de error <code>404</code>; las tres se exportan desde <code>@meekojs/meeko/framework</code> y se usan sin import en el bloque. Un bloque tiene código de nivel superior si exporta un nombre distinto de <code>route</code> o usa esas funciones fuera de cualquier función; si no, se comporta como en <code>1.0</code>. Con <code>render: "stream"</code>, un export con <code>defer</code> llega después de la página; con <code>"prerender"</code>, el bloque se ejecuta en el build. El editor tipa los exports en la página y lleva de su uso al <code>export</code>. Nuevos tipos <code>PageRequest</code>, <code>PageRequestOf</code>, <code>PageBodyHead</code>, <code>ServerData</code>, <code>JsonShape</code> y <code>SerializableExport</code>, y nuevos diagnósticos <code>MEEK070</code> a <code>MEEK076</code>.</p> </li> <li> <p><strong>Página de error de la aplicación <code>app/error.meeko</code></strong>, junto a <code>app/app.meeko</code>, con props <code>{ status, message }</code>:</p> <ul> <li>Una petición de documento (<code>accept: text/html</code>) a una URL sin ruta responde <code>404</code> con esa página dentro de <code>app.meeko</code> y el layout raíz, hidratable, en lugar del texto plano <code>Not Found</code>. Un enlace a una URL sin ruta sigue cargándose como documento, porque esa URL puede pertenecer a middleware de servidor, a un archivo o a una redirección.</li> <li>Es el respaldo cuando falla una página sin <code>+error.meeko</code> más cercano.</li> <li>No puede coexistir con <code>app/pages/+error.meeko</code>. Sin <code>app/error.meeko</code>, el comportamiento de <code>1.0</code> no cambia. <code>/api</code>, <code>/_meeko</code> y las peticiones que no son de página conservan sus <code>404</code>.</li> <li>El payload de navegación de ese <code>404</code> lleva <code>error: true</code> y no lleva <code>route</code> (véase <a href="/docs/stability">docs/stability.md</a>). Nuevos tipos y campos opcionales: <code>ErrorPageRecord</code>, <code>errorPage</code> en <code>ClientAppOptions</code>, <code>FrameworkHandlerOptions</code> y <code>AppManifest</code>, y <code>discoverErrorPage</code> en <code>@meekojs/meeko/build</code>.</li> </ul> </li> <li> <p><strong><code>href(id, options)</code> sin el manifiesto.</strong> Usa el de la aplicación en ejecución: en el servidor, el de la petición en curso (SSR, loaders, <code>head</code>, prerender, API, RPC y middleware); en el navegador, el de <code>mountClientApp</code>. Fuera de una aplicación lanza un error que indica pasar el manifiesto. <code>href(routes, id, options)</code> no cambia, y la acción rápida «quitar <code>params</code>» del editor reconoce ambas formas.</p> </li> <li> <p><strong><code>PageHead.description</code>.</strong> <code>head</code> y <code>export const head</code> pueden devolver la descripción de la página, que va en <code><meta name="description"></code> en SSR y en el prerender y se actualiza al navegar. El payload lleva <code>head.description</code>.</p> </li> <li> <p><strong>Etiquetas de componente con nombre en mayúscula.</strong> <code><AppButton bind:label="x" /></code> equivale a <code><component is="AppButton"></code>, con un import o un autoimport de <code>app/components</code>. Se cierran solas o con <code></AppButton></code>, como <code><component is="..." /></code>, y su contenido son snippets del hijo (véase <code>defineSnippets</code>); <code>MEEK049</code>, que rechazaba ese contenido, ya no se emite. Un <code></AppButton></code> sin apertura da <code>MEEK008</code> y una etiqueta de componente fuera de las secciones, <code>MEEK002</code>. El editor completa los nombres, lleva al <code>.meeko</code> y la gramática de VS Code los resalta.</p> </li> <li> <p><strong>Props estáticas en componentes.</strong> <code><AppButton variant="primary" disabled /></code> pasa <code>"primary"</code> como literal de texto y <code>true</code> para un atributo sin valor, comprobados con tipos contra las props del hijo. La misma prop como texto estático y con <code>bind:</code>/<code>on:</code> es <code>MEEK090</code>. <code>is</code>, <code>ref</code>, <code>html</code> y los nombres con guiones o con <code>:</code> que no son directivas siguen dando <code>MEEK032</code>.</p> </li> <li> <p><strong><code><script lang="ts"></code> opcional.</strong> Un componente o una página con sólo <code><template></code>, o con <code><script server></code> y <code><template></code>, compila con setup vacío y props <code>Record<string, never></code>. <code>MEEK005</code> deja de emitirse. Las acciones rápidas de imports crean el <code><script></code> si falta, y Prettier no lo añade.</p> </li> <li> <p><strong>Componentes genéricos.</strong> <code><script lang="ts" generic="T extends { id: string }"></code> declara parámetros de tipo que se usan en <code>defineProps</code>, <code>defineEmits</code>, <code>defineModel</code>, <code>defineSnippets</code>, <code>defineExpose</code> y el resto del script. Cada etiqueta del padre infiere los parámetros de sus props (también de los manejadores <code>on:</code> con parámetros anotados) y comprueba con ellos los manejadores, los modelos, los snippets y el valor de su <code>ref:</code>. El módulo compilado exporta <code>ComponentProps<T></code>, <code>ComponentModels<T></code>, <code>ComponentSnippets<T></code> y <code>ComponentExposed<T></code>, y las declaraciones <code>.d.meeko.ts</code> conservan los parámetros. Límites: los parámetros sólo se infieren de las props, una <code>ref:</code> dentro de <code>each:of</code> usa la restricción, y un componente con snippets obligatorios no puede usarse con <code><component is></code>. El hover de la etiqueta muestra los parámetros resueltos (<code>T = User</code>), la gramática de VS Code resalta el valor de <code>generic</code> como TypeScript y Prettier lo conserva. Nuevo diagnóstico <code>MEEK100</code>: lista no válida, modificadores, nombres que empiezan por <code>__</code> o repetidos, <code>generic</code> en <code><script server></code>, en páginas, layouts, <code>app.meeko</code> o <code>error.meeko</code>, y tipos del script que usan los parámetros (véase <a href="/docs/api#componentes-gen%C3%A9ricos-generic">docs/api.md</a>).</p> </li> <li> <p><strong>Eventos de componente.</strong> La macro <code>defineEmits<{ save: [id: number] }>()</code> devuelve un <code>emit</code> tipado y el padre escucha con <code>on:save="handler"</code> en la etiqueta del hijo. Cada evento es la prop de callback opcional <code>onSave</code>, así que <code>bind:onSave</code> sigue funcionando y <code>ComponentProps</code> incluye esas props. Nuevos diagnósticos <code>MEEK045</code> (ubicación), <code>MEEK046</code> (sin argumento de tipo), <code>MEEK047</code> (argumentos en tiempo de ejecución) y <code>MEEK048</code> (<code>on:save</code> y <code>bind:onSave</code> en la misma etiqueta); un nombre de evento de componente que no es un identificador da <code>MEEK011</code>.</p> </li> <li> <p><strong>Modelos de componente.</strong> La macro <code>defineModel<T>()</code> o <code>defineModel<T>("nombre", { default })</code> devuelve una <code>Signal<T></code> escribible que es la misma señal que pasa el padre con <code>model="signal"</code> o <code>model:nombre="signal"</code>, o una señal local con el <code>default</code>. Sin <code>default</code>, el modelo es obligatorio. La expresión del padre debe ser una señal escribible; un <code>computed</code> es un error de tipos. Los modelos no son props: el módulo compilado exporta su tipo en <code>ComponentModels</code>. Nuevos diagnósticos <code>MEEK063</code> y <code>MEEK064</code> (<code>defineModel</code>) y <code>MEEK066</code> (<code>model</code> en componentes, incluido <code>model:x</code> junto a <code>bind:x</code>).</p> </li> <li> <p><strong><code>model="signal"</code> en controles de formulario:</strong> <code><input></code> de texto y <code><textarea></code> (<code>value</code>, en <code>input</code>, con una señal <code>string</code>; también los numéricos), checkbox (<code>checked</code>, <code>boolean</code>), radio (marcado si la señal vale su <code>value</code>), <code><select></code> (<code>string</code>) y <code><select multiple></code> (<code>string[]</code>). Asignar la señal actualiza la propiedad viva del control, como <code>bind:value</code> desde <code>1.0.1</code>, y un control editado antes de hidratar (o restaurado por el navegador) conserva el valor del usuario, que pasa a la señal al terminar la hidratación, antes de <code>onMounted</code>, así que las regiones <code>if:</code>, <code>each:</code> y <code><render></code> y los padres que leen la señal se hidratan sin desajustes. Nuevo diagnóstico <code>MEEK065</code> (elemento o tipo no admitido, <code>bind:type</code> o <code>bind:multiple</code>, o conflicto con <code>value</code>, <code>checked</code>, <code>bind:value</code>, <code>bind:checked</code>, <code>on:input</code> u <code>on:change</code>).</p> </li> <li> <p><strong>Snippets.</strong> La macro <code>defineSnippets<{ default: []; title?: []; actions?: [close: () => void] }>()</code> declara el contenido con nombre que un componente recibe, <code><render snippet="snippets.title" args="..." /></code> lo pinta e <code>if:when="snippets.title"</code> comprueba si llegó uno opcional. En el padre, el contenido suelto de la etiqueta llena <code>default</code> y <code><snippet name="actions" params="close"></code> llena uno con nombre, con parámetros tipados; el contenido usa el ámbito del padre y sigue siendo reactivo. Los snippets no son props: el módulo compilado exporta su tipo en <code>ComponentSnippets</code>, y <code>@meekojs/meeko</code> exporta el tipo <code>Snippet</code>. Nuevos diagnósticos <code>MEEK059</code> y <code>MEEK060</code> (<code>defineSnippets</code>), <code>MEEK061</code> (<code><snippet></code>) y <code>MEEK062</code> (<code><render></code>); una <code>ref:</code> dentro de un <code><snippet></code> da <code>MEEK052</code>.</p> </li> <li> <p><strong><code>defineExpose(value)</code></strong> publica un valor del componente para el padre que lo nombra con <code>ref:</code>. Cada módulo compilado exporta el tipo <code>ComponentExposed</code>, y la función que devuelve <code>hydrateScope</code> lleva <code>exposed</code>. Las declaraciones <code>.d.meeko.ts</code> de un componente con <code>defineExpose</code> pueden tipar parte del valor como <code>any</code>; <code>meeko check</code> y el editor tienen el tipo exacto. Nuevos diagnósticos <code>MEEK050</code> (ubicación) y <code>MEEK051</code> (argumentos).</p> </li> <li> <p><strong>Referencias a elementos.</strong> La directiva <code>ref:nombre</code> y la macro <code>useElementRef("nombre")</code>, tipada por la etiqueta (<code>HTMLElementTagNameMap</code>/<code>SVGElementTagNameMap</code>) o por el <code>defineExpose</code> del componente. Sin <code>await</code> devuelve una señal que vale <code>null</code> en SSR y mientras el destino no existe; con <code>await</code> devuelve el elemento y el resto del setup continúa en el navegador; dentro de <code>each:of</code> devuelve la lista de filas. Nuevos diagnósticos <code>MEEK052</code> (directiva inválida), <code>MEEK053</code> (nombre repetido), <code>MEEK056</code> (argumento o ref inexistente, o <code>await</code> sobre una ref de lista) y <code>MEEK080</code> (<code>await useElementRef("x")</code> sobre un componente sin <code>defineExpose</code>, que en ejecución rechaza con ese código cuando el componente se hidrata). <code>ref="x"</code> y <code>bind:ref</code> se comportan como en <code>1.0</code>.</p> </li> <li> <p><strong><code>onMounted(fn)</code></strong> en <code>@meekojs/meeko</code>, también autoimportado: se ejecuta una vez en el navegador tras hidratar o montar el componente, con sus refs ya asignadas, y nunca en SSR. Los callbacks esperan al final de la hidratación o del montaje en curso, cuando ya existen los hermanos posteriores y los bindings del padre; los hijos se ejecutan antes que el padre y una función devuelta se registra como limpieza. <code>ErrorSource</code> añade <code>"mounted"</code> para sus fallos: un <code>switch</code> exhaustivo sobre él necesita esa rama.</p> </li> <li> <p><strong><code>each:key</code> opcional.</strong> Sin clave, la clave es el índice y cada fila se actualiza en su sitio. Se retira <code>MEEK023</code>; el código existente no cambia.</p> </li> <li> <p><strong>Directiva <code>html="expression"</code></strong> para insertar HTML sin escapar en un elemento: en SSR se normaliza en el contexto del elemento (se cierran las etiquetas abiertas y se descartan los cierres sobrantes, así que el contenido nunca sale del elemento ni imita marcadores de Meeko fuera de él; el que el navegador sacaría del elemento, como un <code><div></code> en un <code><p></code>, deja el elemento vacío y se llena al hidratar), la hidratación no toca un contenido que coincide (y sustituye <code>innerHTML</code> si difiere) y cada cambio del valor lo sustituye. Meeko nunca ejecuta los <code><script></code> del contenido al insertarlo en el navegador: ni al hidratar, ni al cambiar el valor, ni en un montaje tardío ni al navegar. Es insegura con contenido no confiable. <code>MEEK095</code> señala los usos no admitidos (hijos, elementos vacíos o de texto, <code><template></code>, <code>model</code>). El servidor de lenguaje la tipa (<code>string | null | undefined</code>) y explica su riesgo en el hover, Prettier formatea su valor como expresión y la gramática de VS Code lo resalta como TypeScript.</p> </li> <li> <p><strong><code>await</code> de nivel superior en el <code><script></code></strong> sobre <code>useApi</code>, <code>useRpcQuery</code>, <code>useElementRef</code>, <code>useSocket</code> y <code>useSocketClient</code>. El setup se divide en el primer <code>await</code> de navegador (<code>useElementRef</code>, <code>useSocket</code>, <code>useSocketClient</code>): lo anterior se ejecuta en SSR y al hidratar, y lo posterior sólo en el navegador, una vez montado el componente; tras <code>await useSocket(...)</code>, con el socket ya abierto. La continuación admite, además de declaraciones, cualquier sentencia de expresión, <code>if</code>, bucles, <code>try</code>, <code>switch</code> y bloques. <code>useElementRef</code>, <code>useApi</code>, <code>useRpcQuery</code> y <code>useRpcMutation</code> sólo se llaman en el nivel superior; <code>useState</code>, <code>useSocket</code> y <code>useNavigation</code> siguen pudiendo llamarse desde código anidado. Nuevos diagnósticos: <code>MEEK054</code> (composable fuera del nivel superior), <code>MEEK055</code> (<code>await</code> no admitido), <code>MEEK057</code> (la plantilla usa un nombre declarado tras el primer <code>await</code> de navegador) y <code>MEEK058</code> (macros tras ese <code>await</code>); cualquier otra sentencia de la continuación da <code>MEEK018</code>.</p> </li> <li> <p><strong>Composables de datos</strong> <code>useApi(ruta, opciones)</code>, <code>useRpcQuery(procedimiento, input)</code> y <code>useRpcMutation(procedimiento)</code>, autoimportados y tipados desde los contratos generados; devuelven <code>{ data, error, pending, refresh }</code> o <code>{ mutate, data, error, pending }</code>. Con <code>await</code>, el SSR renderiza en varias pasadas hasta cargar los datos (como mucho 10), los envía en el campo opcional <code>resources</code> del payload y la hidratación los lee sin repetir la petición; una clave que falta da <code>MEEKO_RESOURCE_MISSING</code>. Sin <code>await</code>, la petición empieza en el navegador al montar. Las señales de la entrada recargan los datos y <code>refresh()</code> los vuelve a pedir. Un fallo de un <code>await</code> de datos muestra la página de error, como un fallo del loader. Un componente que se monta más tarde (bajo un <code>if:</code>, en una fila nueva de <code>each:</code>, en otro <code><component is></code> o con props nuevas) y espera datos que no están en caché deja su zona vacía mientras los carga; si se libera antes, la petición se aborta, y si falla, el error va al <code>provideErrorHandler</code> más cercano o al <code>onError</code> de la aplicación con la fuente <code>"mounted"</code>. <code>renderToString</code> fuera del framework lanza <code>MEEKO_SUSPENDED</code> si un componente espera datos. Las opciones de <code>useApi</code>, el <code>input</code> de <code>useRpcQuery</code> y las opciones de los métodos de <code>api.*</code> se pueden omitir cuando el contrato no exige ningún campo; <code>useRpcQuery</code> sin <code>input</code> envía <code>{}</code>. <code>@meekojs/meeko/framework</code> exporta <code>createUseApi</code>, <code>createUseRpcQuery</code>, <code>createUseRpcMutation</code> y sus tipos.</p> </li> <li> <p><strong>Plugin de Prettier <code>@meekojs/meeko/prettier</code></strong> (parser <code>meeko</code>). Formatea <code><script></code> y <code><script server></code> como TypeScript, <code><style></code> como CSS y la plantilla como HTML, con los valores de las directivas y el texto <code>{expr}</code> formateados como expresiones y las etiquetas PascalCase intactas. Distingue los elementos personalizados con la misma regla que el compilador, así que los nombres SVG/MathML reservados con guion (<code><font-face></code>, <code><annotation-xml></code>…) son elementos estándar y su <code>html</code> se formatea como expresión. La opción <code>meekoIndentSections</code> (ajuste <code>meeko.format.indentSections</code> en el editor, por defecto <code>false</code>) indenta un nivel el contenido de cada sección, como <code>vueIndentScriptAndStyle</code>. El servidor de lenguaje formatea ahora con Prettier: el del proyecto y su configuración en un workspace de confianza, o el incluido; el formateador anterior queda sólo como último recurso. Sólo se formatea el documento completo y no un archivo que no compila. <code>prettier</code> pasa a ser una dependencia del paquete (véase <a href="/docs/editors#formato-con-prettier">docs/editors.md</a>).</p> </li> <li> <p><strong>Comando <code>meeko clean [directorio]</code></strong>: borra <code>.meeko/</code> y la caché de Vite; con <code>--all</code>, también <code>node_modules</code>; con <code>--dry-run</code>, sólo informa. Exige un proyecto Meeko, nunca sigue symlinks ni junctions (seguro con <code>link:</code> de pnpm) y no toca lockfiles, <code>.env</code> ni código.</p> </li> <li> <p><strong>Funciones del editor</strong> en el servidor de lenguaje (véase <a href="/docs/editors#funciones-propias-de-meeko">docs/editors.md</a>):</p> <ul> <li>modificadores de token semántico <code>signal</code>, <code>computed</code>, <code>resource</code>, <code>reactive</code> y <code>modification</code>, decididos por el tipo (<code>props.value</code> no es una señal);</li> <li>hovers de señales, <code>computed</code> y recursos con sus lecturas, escrituras y cómo llegan al navegador; de componentes con sus props, eventos, modelos, snippets y valor expuesto (con los parámetros de tipo resueltos en un componente genérico); y de rutas de <code>href</code>, endpoints de <code>useApi</code>/<code>api.*</code> y procedimientos de <code>useRpcQuery</code>/<code>useRpcMutation</code>/<code>rpc.*</code>, con ir a definición hasta la página o el handler;</li> <li>CodeLens de lecturas y escrituras, y de la ruta, el render, los layouts y los datos que una página envía al navegador;</li> <li>acciones rápidas para añadir <code>each:key</code> y mover un sidecar a <code><script server></code>, y completado de <code>model:</code>, de nombres de snippet y de sus parámetros;</li> <li>zonas de ejecución con la petición propia <code>meeko/executionZones</code>: las líneas que se ejecutan sólo en el servidor, en ambos lados o sólo en el navegador, incluidas las funciones del setup que sólo se usan desde <code>on:</code>, <code>onMounted</code> o la continuación de navegador y las flechas de varias líneas de un <code>on:*</code>, con el motivo en el hover;</li> <li>los usos de un símbolo marcado <code>@deprecated</code>, como el alias <code>useSocket</code> de <code>@meekojs/meeko/framework</code>, se publican tachados (<code>DiagnosticTag.Deprecated</code>) como pistas <code>TS6385</code> o <code>TS6387</code> con el motivo de su etiqueta.</li> </ul> <p>La petición <code>meeko/executionZones</code> y los modificadores de token propios son internos de la extensión de VS Code y pueden cambiar en un minor (véase <a href="/docs/stability#fuera-del-contrato">docs/stability.md</a>).</p> </li> <li> <p><strong>Valores en vivo en el editor.</strong> <code>meeko dev</code> publica los valores de las señales de las páginas abiertas en un puente local (SSE y <code>POST</code> con un token por sesión, sólo en loopback y con comprobación de <code>Host</code> y <code>Origin</code>), que la extensión de VS Code muestra junto a cada declaración y permite editar. Cada servidor escribe su descriptor <code>.meeko/dev/editor-bridge-<puerto>.json</code>, así que varios <code>meeko dev</code> funcionan a la vez, y al arrancar borra los descriptores huérfanos de procesos terminados. Un editor nuevo recibe la instantánea cuando las pestañas abiertas envían su estado (como mucho unos 300 ms después). Una señal compartida, como el modelo que un hijo recibe con <code>defineModel</code>, lleva el campo <code>alias</code> con su señal principal: la extensión la muestra como <code>open = true (= dialogOpen)</code>, la describe como «alias de <code>dialogOpen</code>» en el hover y edita la principal. <code>MEEKO_EDITOR_BRIDGE=0</code> desactiva el puente. Su protocolo es sólo de desarrollo y no forma parte del contrato público (véase <a href="/docs/devtools#puente-del-editor">docs/devtools.md</a>).</p> </li> <li> <p><strong>Protocolo DevTools 1:</strong> campo opcional <code>signalSites</code> en <code>DevtoolsInstance</code>, con la declaración (<code>DevtoolsSignalSite</code>: <code>file</code>, <code>line</code>, <code>column</code>) de cada señal.</p> </li> </ul> <h3 id="cambios-7">Cambios<a class="heading-anchor" href="#cambios-7" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><strong>Mensajes en español.</strong> Los textos de la CLI (ayuda, mensajes de éxito y de error, salida de <code>meeko clean</code>), los diagnósticos de Meeko del compilador, de <code>meeko check</code> y del framework, y los hovers, logs y diagnósticos propios del servidor de lenguaje están en español; <code>MEEK001</code> y <code>MEEK008</code> explican el error del parser HTML en español y conservan su código entre paréntesis (<code>(non-void-html-element-start-tag-with-trailing-solidus)</code>). Los códigos (<code>MEEK0xx</code>, <code>MEEK_*</code>) no cambian; una herramienta que lea los diagnósticos debe usar el código y no el texto, que no forma parte del contrato (véase <a href="/docs/stability#fuera-del-contrato">docs/stability.md</a>).</li> <li><strong><code>meeko check</code> es más estricto con las props de los componentes.</strong> Las props de una etiqueta (<code><Etiqueta></code> o <code><component is></code>) se comprueban sólo contra las que declara el hijo: una prop desconocida junto a otras válidas ya es un error (antes pasaba), <code>bind:variant="'secondary'"</code> conserva su tipo literal frente a una unión y una prop obligatoria que falta se señala en la etiqueta, ahora con <code>TS2345</code> en lugar de <code>TS2769</code>. Las aplicaciones que pasaban props sobrantes verán errores nuevos. Además, <code>meeko check</code> informa una sola vez de cada error, aunque el compilador compruebe la misma expresión o etiqueta en varias rutas de render.</li> <li><strong>Nombres reservados en la plantilla.</strong> <code>ref:nombre</code> es una directiva, y <code>model="..."</code> y <code>html="..."</code> en un elemento HTML estándar son directivas en lugar de atributos HTML (no son atributos válidos de ningún elemento estándar; véase la excepción en <a href="/docs/stability#excepciones-aprobadas">docs/stability.md</a>); en un elemento personalizado (<code><x-markdown html="intro"></code>) siguen siendo atributos literales, como en <code>1.0</code>. <code>bind:ref</code> y <code>bind:html</code> siguen escribiendo el atributo. En una etiqueta de componente, <code>is</code>, <code>ref</code> y <code>html</code> no son props estáticas (<code>MEEK032</code>).</li> <li><strong>Render previo de la navegación.</strong> Antes de confirmar cada navegación, el navegador renderiza la página nueva sin mostrarla para cargar sus <code>await</code> de datos, con <code>useNavigation().pending</code> en <code>true</code>. Esa pasada es en seco: no ejecuta <code>effect</code>, <code>onMounted</code> ni la continuación de navegador, y <code>useSocket</code> no conecta. El código del nivel superior del setup de la página y de los layouts nuevos sí se ejecuta una vez más, con un estado provisional que se descarta. La pasada se salta cuando ningún módulo del árbol nuevo tiene un <code>await</code> de datos, según las marcas <code>hasDataAwait</code> y <code>__meekoChildren</code> que el compilador añade a cada módulo; un componente elegido en tiempo de ejecución obliga a hacerla, y uno que pinta, sin ser layout, el componente de una prop <code>outlet</code> no se recorre, y su contenido se monta tarde. En el navegador, <code>useSocket</code> y <code>socket.x</code> tampoco abren conexión en el render que produce el HTML de un componente antes de montarlo: la abre el montaje, una sola vez.</li> <li><strong>Páginas de error al navegar.</strong> Una navegación cliente cuya petición de datos responde <code>404</code> (por <code>notFound()</code> o por un <code>ApiError</code> <code>404</code> del loader) muestra el <code>+error.meeko</code> más cercano, o <code>app/error.meeko</code>, con <code>{ status: 404, message }</code>, como el documento SSR; antes la navegación fallaba con un error. Las páginas de error se titulan <code>Error</code> en SSR y al navegar, incluida la <code>404</code> de <code>app/error.meeko</code> para una URL sin ruta.</li> <li><strong>Páginas de capas y módulos dentro del shell del proyecto.</strong> <code>app/app.meeko</code> y el layout raíz del proyecto envuelven las páginas de <code>extends</code> y <code>modules</code>, y los <code>+layout.meeko</code> de la capa se anidan dentro; si el proyecto tiene <code>app.meeko</code> o layout raíz, sustituyen a los de la capa. Una página de capa que falla usa su <code>+error.meeko</code> más cercano, después el <code>app/error.meeko</code> de la capa y por último la página de error raíz del proyecto. Antes se renderizaban sueltas en <code>#app</code> y el layout desaparecía al navegar hacia ellas. <code>discoverRoutes(root, { shell })</code> y el tipo <code>DiscoverRoutesOptions</code> de <code>@meekojs/meeko/build</code> exponen la opción.</li> <li><strong><code>meeko dev</code> registra archivos nuevos sin reiniciar:</strong> las páginas, layouts, <code>app/app.meeko</code>, <code>app/error.meeko</code>, middlewares y módulos de <code>server/api</code>, <code>server/rpc</code> y <code>server/socket</code> que se crean o se borran, en el proyecto y en sus layers y módulos. Vuelve a descubrir las rutas y crea de nuevo la aplicación, y las peticiones esperan a la nueva. Al recrearla se cierran las conexiones Socket y se vuelve a llamar a <code>server/runtime.ts</code>, así que se pierden las sesiones de un almacén en memoria; si la aplicación nueva falla, sigue la anterior. Editar un canal Socket existente o <code>meeko.config.ts</code> sigue exigiendo reiniciar.</li> <li><strong>Rechazos de sesión y autorización del handshake de Socket.</strong> Un handshake sin sesión en un canal <code>auth: "required"</code>, o que <code>authorize</code> rechaza, ya no recibe <code>401</code>/<code>403</code> por HTTP, que el <code>WebSocket</code> del navegador no expone y que el cliente reintentaba sin fin. Los adaptadores de Node, Bun, Deno y Cloudflare (este último desde el Worker, sin despertar el Durable Object) completan el upgrade y cierran en seguida con <code>4401</code> («Autenticación requerida») o <code>4403</code> («Acceso denegado»), sin llamar a ningún handler ni entregar mensajes; el cliente de Meeko pasa a <code>"unauthorized"</code> también en el navegador. <code>openSocketSession</code> cierra igual cuando el hub rechaza una conexión ya aceptada, como al despertar un Durable Object, en lugar de <code>1008</code>. El Origin no permitido (<code>403</code> <code>INVALID_ORIGIN</code>), el canal inexistente (<code>404</code>), las peticiones inválidas (<code>400</code>) y los límites siguen respondiendo por HTTP: un origen ajeno nunca completa un upgrade. En <code>createSocketUpgradeHandler</code>, la acción <code>reject</code> de <code>SocketUpgrade</code> gana el campo opcional <code>close</code>; un adaptador propio que no lo atiende sigue respondiendo <code>status</code>, y <code>createNodeSocketUpgradeHandler</code> ya no pasa esos dos rechazos a su <code>reject</code>. Un cliente WebSocket propio que esperaba el <code>401</code>/<code>403</code> HTTP debe tratar los cierres <code>4401</code>/<code>4403</code> como rechazo definitivo (véase <a href="/docs/migration-1.1#socket-cierres-4401-y-4403-en-el-handshake">docs/migration-1.1.md</a>).</li> </ul> <h3 id="correcciones-8">Correcciones<a class="heading-anchor" href="#correcciones-8" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Un cliente Socket (<code>createSocketClient</code>, <code>useSocketClient</code>, el autoimport <code>useSocket</code> o <code>socket.x</code>) que el servidor rechazaba por autenticación o autorización reintentaba sin fin e informaba «Socket transport error». Ahora, ante el cierre de política del hub (<code>1008</code> con <code>Unauthorized</code>, <code>Session expired</code> o <code>Session revoked</code>), los códigos <code>4401</code>/<code>4403</code> o un handshake <code>401</code>/<code>403</code> cuyo estado expone la implementación de <code>WebSocket</code> (como <code>ws</code>), no reintenta: <code>state</code> pasa al nuevo estado terminal <code>"unauthorized"</code> y el observador de errores recibe un <code>ClientError</code> <code>401</code> (<code>UNAUTHENTICATED</code>) o <code>403</code> (<code>FORBIDDEN</code>). El <code>WebSocket</code> del navegador no expone el estado de un handshake rechazado; por eso los adaptadores de Meeko cierran ahora esos handshakes con <code>4401</code>/<code>4403</code> (véase «Cambios» y <a href="/docs/framework#websocket">docs/framework.md</a>).</li> <li>Los autoimports de framework (<code>useSocket</code>, <code>api</code>, <code>rpc</code>, <code>useApi</code>…) en los <code>.ts</code> de <code>app/</code> (composables, utils, stores) usaban el cliente del navegador también en SSR, y <code>meeko dev</code> o <code>meeko build</code> fallaban con «Client-only module reached the server bundle». Ahora se resuelven por entorno, como en los <code>.meeko</code>; los <code>.client.ts</code> siguen siendo sólo de navegador.</li> <li>Un clic en un enlace a un fragmento de la página actual (<code>#seccion</code>) se trataba como una navegación completa: Meeko volvía a pedir y renderizar la página y no se desplazaba hasta el ancla. Ahora el navegador lo atiende, y volver atrás o adelante entre fragmentos no renderiza la página. Una navegación nueva empieza arriba o en el elemento de su fragmento; antes conservaba el scroll de la página anterior.</li> <li>Si la petición de datos de una navegación recibe HTML en lugar de un payload (por ejemplo, de un hosting estático que sirve el <code>index.html</code> prerenderizado), Meeko carga el documento. Antes la navegación fallaba y el clic no hacía nada.</li> <li>Al navegar a una página sin <code>title</code>, <code>document.title</code> conservaba el de la página anterior. Ahora vuelve al título del host, o a ninguno, como en SSR.</li> <li>El documento SSR (y el prerenderizado) sólo incluía en <code><head></code> el CSS de la página y de sus layouts: el de los componentes hijos llegaba con el bundle del cliente, así que la página se pintaba primero sin esos estilos y se desplazaba al cargar el JavaScript. Ahora incluye también el CSS de cada componente que renderiza.</li> <li><code>meeko build</code> copiaba <code>public/</code> también en la raíz de la salida de servidor (<code>.meeko/output/node/</code>, Bun y Deno), donde nadie lo sirve. Ahora sólo está en <code>client/</code>.</li> <li><code>meeko dev</code> y el plugin de Vite ya no vigilan <code>.meeko/</code> salvo <code>.meeko/generated/</code>, ni lo incluyen en el escaneo de dependencias, combinando la exclusión con los <code>server.watch.ignored</code> y <code>optimizeDeps.entries</code> del usuario. Antes, <code>meeko check</code>, el servidor de lenguaje o un build que escribían en <code>.meeko/</code> recargaban el navegador, y con carpetas grandes bajo <code>.meeko/</code> Vite tardaba segundos más en arrancar porque abría un <code>fs.watch</code> por archivo. También se respeta <code>server.watch: null</code>, que el plugin reactivaba.</li> <li>Después de que Vite se reiniciara en <code>meeko dev</code> (al cambiar un <code>.env</code> o una dependencia de la configuración, o con <code>server.restart()</code>), todas las rutas, incluida la página de error, respondían <code>500</code> («Vite module runner has been closed») hasta reiniciar <code>meeko dev</code>. Ahora la aplicación de desarrollo se vuelve a crear sobre el servidor de Vite nuevo y se cierra la anterior; las peticiones que llegan mientras tanto la esperan. Como al añadir o borrar una página, lo que la aplicación guardaba en memoria (las sesiones de un <code>MemorySessionStore</code>, el estado de los módulos de servidor) empieza vacío y las conexiones Socket abiertas se cierran.</li> <li><code>useState</code> y el resto del contexto de Meeko fallaban en <code>meeko dev</code> («Missing Meeko context») cuando la aplicación consume Meeko con <code>link:</code>, después de que Vite recargara sus módulos. El SSR de desarrollo externaliza ahora <code>@meekojs/meeko</code>, como el build.</li> <li><code>meeko check</code> comprueba los <code>.ts</code> que importa un <code>.meeko</code> con los autoimports de su ámbito y con las rutas generadas. Antes daba <code>TS2304</code> para composables, stores o utilidades autoimportados dentro de esos archivos, aceptaba <code>href("/ruta-inexistente")</code> y rechazaba <code>href(id, { search })</code> en rutas estáticas. Puede mostrar ahora errores que los proyectos <code>tsconfig.*</code> generados ya daban.</li> <li>Los <code>enum</code> y las clases autoimportados se pueden usar también como tipo, incluidos sus miembros (<code>Scope.App</code>). Un autoimport que sólo se usa como tipo se emite como <code>import type</code>.</li> <li>Los contratos de API, RPC y Socket aceptan schemas autoimportados desde <code>shared/schemas</code>, incluidos los que usan un <code>enum</code> autoimportado. Antes exigían un import explícito («query must come from shared/»).</li> <li>Con resolución <code>NodeNext</code> (la de los proyectos de <code>meeko init-framework</code>), el servidor de lenguaje tipaba las etiquetas de un componente del proyecto con su declaración generada <code>.d.meeko.ts</code> de <code>.meeko/types</code>, que podía estar desactualizada y no lleva los parámetros resueltos de un componente genérico: el hover de la etiqueta no mostraba <code>T = User</code> y los parámetros de <code><snippet params></code> y de los manejadores <code>on:</code> podían mostrar otro tipo. Ahora el editor usa el componente tal como está, también con cambios sin guardar.</li> <li><code>meeko check</code> y el editor informaban dos veces de un error dentro de un <code><snippet></code> (por ejemplo <code>{row.name}</code> sin <code>name</code>), la segunda sobre la última letra. Ahora lo informan una vez, sobre la propiedad.</li> <li>Los hovers, el completado y la ayuda de firmas mostraban <code>{@link X}</code> literal en la documentación. Ahora muestran el nombre en código, su texto o un enlace.</li> <li>Un comando o una opción desconocidos de la CLI (<code>meeko frobnicate</code>, <code>meeko dev --port 1</code>) sólo mostraban el uso. Ahora indican antes el problema (<code>Comando desconocido: frobnicate</code>, <code>Opción desconocida para dev: --port</code>), y la ayuda describe las variables <code>PORT</code>, <code>HOST</code>, <code>PUBLIC_ORIGIN</code>, <code>MEEKO_HMR_PORT</code> y <code>MEEKO_EDITOR_BRIDGE</code>.</li> </ul> <h3 id="deprecado-2">Deprecado<a class="heading-anchor" href="#deprecado-2" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><code>useSocket(url, contract, options)</code> de <code>@meekojs/meeko/framework</code> pasa a llamarse <code>useSocketClient</code>, con la misma firma, los mismos tipos y el mismo comportamiento (ligado al componente, admite <code>await</code> de nivel superior). Así deja de compartir nombre con el autoimport <code>useSocket("canal", opciones)</code> de los clientes generados, que tiene otra firma y no cambia. <code>useSocket</code> sigue exportándose como alias obsoleto (<code>@deprecated</code>; es la misma función) durante toda la serie 1.x y se retirará en <code>2.0</code>: sustituya <code>import { useSocket } from "@meekojs/meeko/framework"</code> por <code>import { useSocketClient } from "@meekojs/meeko/framework"</code>. En un proyecto sin clientes generados, el autoimport <code>useSocket</code> resuelve ahora a <code>useSocketClient</code>, que es la misma función, sin el aviso de obsoleto. <code>createSocketClient</code> no cambia (véase <a href="/docs/framework#clientes-con-url-y-contrato-expl%C3%ADcitos">docs/framework.md</a>).</li> </ul> <h3 id="documentación-3">Documentación<a class="heading-anchor" href="#documentaci%C3%B3n-3" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Las reglas del nivel superior del <code><script></code> (<code>MEEK014</code>, <code>MEEK015</code>, <code>MEEK018</code>), cómo usar un <code>.client.ts</code> de <code>app/</code> desde una página, qué es un store y por qué su estado debe vivir en <code>useState</code>, y en qué se diferencian <code>extends</code> y <code>modules</code>.</li> <li>La <a href="/docs/stability#c%C3%B3digos-de-diagn%C3%B3stico">política de estabilidad</a> lista todos los códigos de diagnóstico en uso y los retirados (<code>MEEK005</code>, <code>MEEK023</code> y <code>MEEK049</code>).</li> </ul> <h2 id="101---2026-10-25">[1.0.1] - 2026-10-25<a class="heading-anchor" href="#101---2026-10-25" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <h3 id="correcciones-9">Correcciones<a class="heading-anchor" href="#correcciones-9" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><code>bind:value</code>, <code>bind:checked</code> y <code>bind:selected</code> actualizan también la propiedad viva de <code>input</code>, <code>textarea</code>, <code>select</code> y <code>option</code>. Antes sólo cambiaban el atributo, que el navegador ignora una vez que el usuario edita el control, así que asignar el signal desde código no limpiaba el campo y el signal quedaba desincronizado de lo que se veía. Al hidratar, un <code>textarea</code> o un <code>select</code> simple que el usuario aún no cambió toma el valor enlazado; un <code>select multiple</code> no se modifica. <ul> <li>Cambio de comportamiento: el control pasa a reflejar siempre el signal. Si el manejador de <code>input</code> guarda un valor transformado (por ejemplo, <code>Number(value)</code> o <code>value.trim()</code>), el campo muestra ese valor transformado mientras el usuario escribe. Guarde el texto tal cual en un signal de tipo <code>string</code> y conviértalo donde se use.</li> </ul> </li> <li>El handshake de Socket acepta los otros nombres de loopback (<code>localhost</code>, <code>127.0.0.1</code>, <code>[::1]</code>) con el mismo esquema y puerto cuando el origen público es de loopback. Antes, una página abierta en <code>http://localhost:4173</code> recibía <code>403 INVALID_ORIGIN</code> de un servidor que escuchaba en <code>127.0.0.1:4173</code>, aunque sus peticiones HTTP sí funcionaban. Los orígenes que no son de loopback siguen sin tomar su identidad de una cabecera.</li> </ul> <h2 id="100---2026-10-25">[1.0.0] - 2026-10-25<a class="heading-anchor" href="#100---2026-10-25" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Primera versión estable. El código es el de <code>1.0.0-rc.1</code>, sin cambios; los cambios respecto a <code>0.1.0</code> se recogen en la sección siguiente y en la <a href="/docs/migration-1.0">guía de migración</a>. Desde esta versión, Meeko sigue SemVer según <a href="/docs/stability">docs/stability.md</a>.</p> <h2 id="100-rc1---2026-10-25">[1.0.0-rc.1] - 2026-10-25<a class="heading-anchor" href="#100-rc1---2026-10-25" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Primera versión estable candidata. Desde 1.0, Meeko sigue SemVer según <a href="/docs/stability">docs/stability.md</a>; la guía <a href="/docs/migration-1.0">docs/migration-1.0.md</a> recoge la migración desde <code>0.1.0</code>.</p> <h3 id="cambios-incompatibles-y-migración">Cambios incompatibles y migración<a class="heading-anchor" href="#cambios-incompatibles-y-migraci%C3%B3n" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>La raíz <code>@meekojs/meeko</code> sólo exporta la API pública documentada: <code>signal</code>, <code>computed</code>, <code>effect</code>, <code>batch</code>, <code>untrack</code>, <code>createRoot</code>, <code>onCleanup</code>, <code>createContext</code>, <code>provide</code>, <code>inject</code>, <code>provideErrorHandler</code>, <code>serializeJson</code> y sus tipos. Los helpers de DOM, SSR, HMR y DevTools (<code>bind*</code>, <code>render*</code>, <code>keyToken</code>, <code>withStateSnapshot</code>, <code>escapeHtml</code>, <code>attributeValue</code>, <code>renderAttribute</code>, <code>enableHotModule</code>, <code>registerHot*</code>, <code>replaceHot*</code>, <code>restoreSignals</code>, <code>snapshotSignals</code>, <code>registerDevtoolsInstance</code>) quedan sólo en <code>@meekojs/meeko/internal</code>, que es lo que importa el código generado desde <code>0.0.2</code>. Vuelva a compilar los módulos generados con <code>0.0.1</code>.</li> <li><code>ComponentErrorHandler</code> recibe un segundo argumento <code>source: ErrorSource</code>. Los handlers de un solo parámetro siguen siendo válidos.</li> <li>El payload de hidratación y navegación lleva <code>v: 2</code>, <code>render</code> y <code>head</code>. La versión 2 añade la lista <code>deferred</code>, <code>null</code> en cada <code>path</code> diferido y la respuesta <code>application/meeko+ndjson</code> de las rutas <code>"stream"</code>. El cliente rechaza un payload sin versión o con otra versión (incluida <code>v: 1</code>) con un mensaje explícito; servidor y navegador deben salir del mismo build, y los <code>index.meeko.json</code> prerenderizados deben regenerarse con <code>meeko build</code>.</li> <li>Se elimina <code>FrameworkHandlerOptions.renderLayout</code>. Los layouts se componen siempre mediante el outlet <code><component is="props.outlet"></code>.</li> <li>El protocolo DevTools pasa a la versión 1: <ul> <li><code>DevtoolsHook</code> exige <code>protocolVersion</code> y <code>setSignal</code>, y <code>DevtoolsSnapshot</code> exige <code>protocolVersion</code>. Un hook o una captura construidos a mano, por ejemplo en pruebas, deben añadir esos miembros.</li> <li><code>DevtoolsReadSite.kind</code> admite además <code>computed</code>, <code>if</code>, <code>each</code> y <code>prop</code>. Un <code>switch</code> exhaustivo sobre <code>text</code>/<code>attribute</code> debe cubrir los nuevos valores.</li> <li>El panel integrado y la extensión de Chrome 1.0.0 rechazan, con un mensaje explícito, los runtimes sin <code>protocolVersion</code>. Use la extensión 1.0.0 con esta versión de <code>@meekojs/meeko</code>, y la extensión anterior con runtimes anteriores.</li> </ul> </li> <li><code>server/session.ts</code> deja de cargarse y se sustituye por <code>server/runtime.ts</code>, que exporta por defecto <code>defineServerRuntime(({ env, production, platform, prerendering }) => ({ sessions, services, socket, publicOrigin, onError, close }))</code>. Mueva el <code>SessionManager</code> de <code>createSessionManager(production)</code> a <code>sessions</code> y elimine el archivo anterior; <code>meeko check</code>, <code>meeko dev</code> y <code>meeko build</code> se detienen con estas instrucciones mientras exista. <code>meeko build</code> llama a la fábrica con <code>prerendering: true</code> para renderizar las páginas prerenderizadas.</li> <li><code>@meekojs/meeko/server</code> es ahora el núcleo portable (Web APIs y <code>node:async_hooks</code>) y ya no carga TypeScript ni el sistema de archivos. Las herramientas de build pasan a la nueva subruta <code>@meekojs/meeko/build</code> (<code>discoverRoutes</code>, <code>discoverConfiguredRoutes</code>, <code>composeFrameworkRoutes</code>, <code>loadMeekoConfig</code>, <code>readMeekoConfigSync</code>, <code>resolveConfigSources</code>, <code>discoverServerManifest</code>, <code>prerenderRoutes</code>, <code>prerenderProject</code>, <code>buildProject</code>) y <code>toNodeListener</code>, <code>attachNodeWebSocketServer</code> y <code>createNodeSocketUpgradeHandler</code> a la nueva subruta <code>@meekojs/meeko/node</code>. Actualice esos imports.</li> <li><code>createServerDispatcher</code>, <code>createLocalCalls</code>, <code>generateOpenApi</code> y <code>loadSocketChannels</code> exigen un cargador de módulos explícito (<code>load</code>); ya no importan rutas del disco por defecto. En Node puede pasar <code>(file) => import(pathToFileURL(file).href)</code>.</li> <li><code>meeko build</code> escribe un build Node autónomo en <code>.meeko/output/node/</code> (<code>index.mjs</code>, <code>chunks/</code>, <code>client/</code>, <code>prerender/</code>) en lugar de <code>.meeko/output/server/entry.js</code>, y el prerender pasa de <code>.meeko/output/prerender/</code> a <code>.meeko/output/node/prerender/</code>, con un índice <code>{ version: 1, pages }</code> en <code>manifest.json</code>. <code>prerenderRoutes</code> requiere que cada documento contenga <code><head></code> y escribe también el payload de navegación.</li> <li>El valor de <code>render</code> de un sidecar se lee sin ejecutarlo: debe ser un literal de texto en <code>definePage({ ... })</code>, en un objeto exportado o en una constante local del mismo archivo. Un valor calculado, una clave computada no seguida de un <code>render</code> literal, un spread sin <code>render</code> explícito posterior o una reexportación detienen el build.</li> <li>Sólo se sirven los archivos públicos listados en el manifiesto del build; un archivo no listado, incluido un enlace añadido a <code>public/</code> después del build, responde como cualquier ruta de la aplicación (normalmente <code>404</code>) en lugar de <code>403</code>.</li> <li>El HTML ya no incluye <code><script id="meeko-routes"></code>: la entrada cliente importa las rutas desde el módulo virtual <code>virtual:meeko-manifest/client</code>. Los módulos virtuales <code>virtual:meeko-server-pages</code> y <code>virtual:meeko-server-routes</code> se sustituyen por <code>virtual:meeko-server-app</code>.</li> <li><code>PageDefinition.render</code> sólo acepta los modos de servidor (<code>"ssr"</code>, <code>"stream"</code> y <code>"prerender"</code>); las páginas <code>render: "client"</code> usan el nuevo tipo <code>ClientPageDefinition</code>. <code>PageRender</code> incluye ahora <code>"client"</code>, de modo que un <code>switch</code> exhaustivo sobre él debe cubrir ese valor.</li> <li>El servidor compara el <code>render</code> del sidecar con el del manifiesto aunque el sidecar lo omita: un manifiesto con <code>render: "prerender"</code> y un sidecar sin <code>render</code> (o con otro valor) responden con error hasta reconstruir. Un manifiesto escrito a mano sin <code>render</code> sigue aceptando sidecars <code>"ssr"</code> y <code>"prerender"</code>.</li> <li>La entrada cliente generada importa <code>virtual:meeko-client-routes</code>; <code>.meeko/types/virtual-pages.d.ts</code> lo declara. Regenere los tipos con <code>meeko check</code> si su proyecto incluye una entrada propia.</li> <li>Cambia el contrato de broadcast de Socket: <ul> <li><code>hub.broadcast()</code> se resuelve cuando el broker acepta el mensaje y ya no rechaza por fallos de entrega a los peers.</li> <li><code>hub.broadcast()</code> rechaza por tamaño: si el mensaje serializado con <code>serializeJson</code> (que escribe <code><</code>, <code>></code> y <code>&</code> con 6 bytes) supera <code>maxMessageBytes</code>, rechaza con <code>SOCKET_LIMIT_EXCEEDED</code> (413) antes de publicar, en lugar de cerrar con <code>1009</code> a todos los peers de la sala.</li> <li>Un peer que falla se cierra (<code>1008</code>, <code>1009</code>, <code>1011</code>, o <code>1013</code> si su cola de entregas se llena) y su error llega a <code>SocketHubOptions.onDeliveryError(error, { channel, room, event })</code> de la instancia que tiene ese peer. <code>createServerApp</code> lo conecta por defecto al <code>onError</code> del runtime.</li> <li><code>LocalSocketPubSub.publish</code> deja de agregar errores de sus listeners y los envía a <code>onListenerError</code>.</li> <li>En un broadcast, <code>authorizeSend</code> que devuelve <code>false</code> omite a ese peer sin cerrarlo.</li> <li>Quien dependía del rechazo de <code>broadcast</code> debe observar <code>onDeliveryError</code> o <code>onError</code>.</li> </ul> </li> <li><code>SocketPubSub.subscribe</code> puede devolver <code>Unsubscribe | Promise<Unsubscribe></code>, y <code>Unsubscribe</code> puede ser asíncrona. El hub espera la suscripción antes de resolver <code>accept</code>. Un broker propio debe aceptar esa firma, y quien llame a <code>subscribe</code> directamente debe esperar el resultado con <code>await</code>.</li> <li><code>RequestContext.signal</code> ya no es <code>request.signal</code> sin más: combina esa señal con la revocación de la sesión y puede abortarse con <code>SessionRevokedError</code> aunque el cliente siga conectado.</li> <li><code>PageRender</code> incluye <code>"stream"</code>, y <code>PageDefinition.render</code> lo acepta: un <code>switch</code> exhaustivo sobre <code>PageRender</code> debe cubrirlo. El payload puede llevar <code>deferred: [{ id, path, status, value?, error? }]</code> con <code>null</code> en cada <code>path</code>.</li> <li>El servidor sella el <code>StateStore</code> de la petición tras el render síncrono y <code>head</code>, en todos los modos de render (<code>ssr</code>, <code>stream</code>, <code>prerender</code> y los layouts de <code>client</code>): un <code>useState</code> con clave nueva, un <code>seed</code> o una escritura posteriores lanzan <code>STATE_SEALED</code>. Migración: el trabajo asíncrono que escribe estado debe esperarse en el loader (<code>await</code>) o devolverse con <code>defer</code>; una promesa suelta que escribe estado tras el render rechaza con <code>STATE_SEALED</code> y, si nadie la captura, es un rechazo no manejado que termina el proceso de Node con su configuración por defecto. <code>head</code> se sigue calculando después del render, con el estado que este escribió.</li> <li><code>PageRequestContext.signal</code> (la <code>signal</code> del loader del servidor) ya no es <code>request.signal</code>: combina <code>RequestContext.signal</code> (desconexión y revocación de la sesión) con la cancelación del trabajo diferido (stream cancelado, <code>HEAD</code> o error de la petición).</li> <li><code>SessionHandle.create</code>, <code>rotate</code> y <code>revoke</code> rechazan con <code>SESSION_LOCKED</code> (<code>500</code>) cuando las cabeceras de una respuesta <code>"stream"</code> ya se enviaron, sin tocar el almacén.</li> <li>Con <code>render: "prerender"</code>, un valor <code>defer</code> rechazado hace fallar la petición con <code>500</code> (y <code>meeko build</code> con la ruta afectada) en lugar de guardar el error en el HTML. <code>prerenderRoutes</code> toma el payload de navegación del propio documento (<code>#meeko-payload</code>) y sólo pide <code>application/meeko+json</code> al handler cuando el documento no lo incluye.</li> </ul> <h3 id="añadido-y-corregido">Añadido y corregido<a class="heading-anchor" href="#a%C3%B1adido-y-corregido" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li> <p>Una navegación cliente cuyo loader o middleware de servidor redirige (por ejemplo, una página privada que envía a <code>/login</code>) ya no falla con «Meeko route data mismatch»: el cliente navega al destino sin recargar si es una ruta de la aplicación en el mismo origen, o hace una carga completa en otro caso. Cubre tanto la redirección que sigue el <code>fetch</code> del navegador como un <code>3xx</code> devuelto por un <code>fetch</code> propio.</p> </li> <li> <p>Streaming SSR con <code>render: "stream"</code> y <code>defer(promise, { timeoutMs })</code> o <code>defer((signal) => promise, { timeoutMs })</code> desde <code>@meekojs/meeko/framework</code> (tipos <code>Deferred</code>, <code>DeferredError</code>, <code>DeferredStatus</code>, <code>DeferOptions</code>, <code>DeferredFactory</code>). La señal de una fábrica se aborta por timeout, desconexión, revocación de la sesión, stream cancelado, <code>HEAD</code> o, en el navegador, al salir de la ruta. Antes del primer byte se ejecutan middleware, validación, el loader crítico, <code>head</code> y el render síncrono de layouts y página; después se sella el estado y se comprueba la sesión con <code>session.verify()</code> (una sesión revocada responde <code>401</code>). La respuesta (<code>cache-control: no-store, no-transform</code>, <code>x-accel-buffering: no</code>; <code>no-transform</code> evita que un intermediario comprima o reescriba el cuerpo con buffer) envía el documento con <code>#meeko-payload</code> y una entrada <code><script type="module" async></code> que respeta el nonce CSP, y luego un <code><script type="application/json" data-meeko-deferred="N"></code> por valor resuelto. Los rechazos se envían como <code>{ code, status }</code> (los <code>5xx</code> llegan a <code>onError</code> con el <code>requestId</code>), <code>DEFERRED_TIMEOUT</code>/<code>504</code> al agotar el plazo (10 s por defecto), y los diferidos se abortan con <code>RequestContext.signal</code>, al cancelarse el stream o en <code>HEAD</code>. Los cambios de sesión en curso terminan antes del primer byte y los posteriores fallan con <code>SESSION_LOCKED</code> sin cerrar la sesión del usuario. El navegador hidrata con los valores pendientes, aplica los bloques recibidos tras la hidratación, detecta los posteriores con un <code>MutationObserver</code>, sólo acepta bloques hijos directos de <code><body></code> situados después de <code>#meeko-payload</code> y rechaza con <code>DEFERRED_INCOMPLETE</code>/<code>502</code> los que nunca llegan. La navegación cliente a una ruta <code>"stream"</code> recibe <code>application/meeko+ndjson</code> (payload en la primera línea, un valor por línea después), informa las líneas mal formadas sin detenerse, rechaza con <code>DEFERRED_INCOMPLETE</code> lo pendiente si la lectura falla y cancela la lectura al salir de la ruta. Los valores diferidos pueden ir bajo claves <code>constructor</code> o <code>prototype</code>; bajo <code>__proto__</code> el servidor responde <code>500</code>. Con <code>render: "ssr"</code> o <code>"prerender"</code>, <code>defer</code> se espera antes de renderizar. La suite de conformidad comprueba en Node, Bun, Deno y workerd que el primer byte llega antes que el valor diferido. En local, <code>wrangler dev</code> y <code>meeko preview --adapter cloudflare</code> (Miniflare) comprimen <code>text/html</code> con gzip aunque la respuesta lleve <code>no-transform</code> y sólo escriben el cuerpo al terminar; un cliente que envía <code>accept-encoding: identity</code> recibe el streaming.</p> </li> <li> <p>Páginas <code>render: "client"</code>: el servidor ejecuta los middlewares, valida <code>params</code> y <code>search</code> y renderiza sólo los layouts con el outlet vacío; el navegador ejecuta <code>load</code> y <code>head</code> con el nuevo <code>ClientPageLoadContext</code> (<code>url</code>, <code>params</code>, <code>search</code>, <code>signal</code>, <code>state</code>) y renderiza la página. La navegación entre páginas SSR y de cliente funciona en ambos sentidos y conserva los layouts comunes. Sólo los sidecars <code>"client"</code> entran al bundle cliente, mediante <code>virtual:meeko-client-routes</code> y la nueva opción <code>mountClientApp({ loadClientRoute })</code>; importar código de servidor desde ellos detiene el build. Declarar <code>prerenderEntries</code> con <code>render: "client"</code> es un error. Sus datos deben llegar por API o RPC con guardas propias, y el HTML inicial no incluye datos ni <code><title></code> de la página.</p> </li> <li> <p><code>useNavigation()</code> devuelve <code>{ pending }</code>, una señal de sólo lectura que indica si hay una navegación en curso (tipo <code>NavigationState</code>). <code>@meekojs/meeko/framework</code> exporta además los tipos <code>ClientPageDefinition</code>, <code>ClientPageLoadContext</code>, <code>PageHead</code> y <code>PageRender</code>.</p> </li> <li> <p><code>RedisSocketPubSub({ publisher, subscriber, prefix, maxMessageBytes?, sharded?, onError? })</code> en <code>@meekojs/meeko/server</code> distribuye los broadcasts de Socket entre instancias mediante Redis pub/sub:</p> <ul> <li>usa un canal Redis por canal y sala, con conteo de referencias por instancia;</li> <li>envía un sobre versionado <code>{ v: 1, event, payload }</code>;</li> <li>limita el tamaño antes de publicar;</li> <li>el receptor vuelve a validar el schema y la autorización;</li> <li><code>sharded: true</code> activa el pub/sub con shards de Redis 7.</li> </ul> <p>Tipos nuevos: <code>RedisPublisherClient</code>, <code>RedisSubscriberClient</code>, <code>RedisMessageListener</code>, <code>RedisSocketPubSubOptions</code>, <code>SocketMessage</code>, <code>SocketDeliveryErrorContext</code>, <code>Unsubscribe</code> y <code>LocalSocketPubSubOptions</code>. <code>ServerRuntime.socket.onDeliveryError</code> sustituye al observador por defecto.</p> </li> <li> <p>Revocación durante una petición:</p> <ul> <li><code>SessionStore.subscribeRevocations?</code> es una capacidad opcional. <code>RedisSessionStore</code> la ofrece con la opción <code>subscriber</code>: el script de <code>revokeFamily</code> publica en <code><prefix>revoked</code>. <code>MemorySessionStore</code> notifica dentro del proceso.</li> <li><code>SessionHandle.signal</code> y <code>RequestContext.signal</code> se abortan con <code>SessionRevokedError</code>, exportado y equivalente a <code>ApiError</code> <code>SESSION_REVOKED</code> con estado <code>401</code>.</li> <li>Los sockets de la familia revocada se cierran con <code>1008</code>.</li> <li><code>SessionHandle.verify()</code> relee el store antes de efectos irreversibles.</li> <li><code>SessionHandle.signal</code> y <code>RequestContext.signal</code> se abortan aunque el código sólo conserve la señal; <code>RequestContext.signal</code> se combina al leerla por primera vez.</li> </ul> </li> <li> <p>Contrapresión de Socket con brokers asíncronos como Redis, configurable en <code>SocketHubOptions</code> y en <code>socket</code> de <code>server/runtime.ts</code>:</p> <ul> <li><code>maxPendingDeliveries</code> (256 por defecto) limita las entregas pendientes de cada peer; un peer que lo supera se cierra con <code>1013</code> y se informa con <code>SOCKET_BACKLOG_EXCEEDED</code> (503) a <code>onDeliveryError</code>.</li> <li><code>sessionRefreshMs</code> (1000 ms por defecto) hace que las entregas de broadcast reutilicen la última lectura de la sesión durante ese intervalo; las revocaciones siguen cerrando el peer al instante y <code>authorize</code>/<code>authorizeSend</code> se ejecutan en cada entrega. Con <code>0</code> se relee en cada entrega, como antes.</li> </ul> </li> <li> <p><code>mountClientApp({ onError })</code> observa los fallos de la aplicación (navegación, Socket, y eventos, efectos o limpiezas sin un <code>provideErrorHandler</code> más cercano) junto con su <code>ErrorSource</code>. <code>provideErrorHandler</code> recibe también los rechazos de <code>effect</code> y <code>onCleanup</code> que devuelven una promesa por error.</p> </li> <li> <p>La navegación cliente es transaccional: la vista nueva se hidrata junto a la actual y la anterior sólo se retira tras una hidratación correcta; un outlet restaura su página anterior. Sólo si también falla esa restauración se recarga la última URL confirmada.</p> </li> <li> <p>La navegación actualiza <code>document.title</code> con el <code>head</code> de la página siguiente.</p> </li> <li> <p><code>FrameworkHandlerOptions.document</code> añade marcado del host a <code><head></code> y al final de <code><body></code>, también en la página <code>+error.meeko</code>, y aplica un <code>nonce</code> CSP por petición a los estilos y al script de entrada. <code>head</code> y <code>bodyEnd</code> pueden ser funciones que reciben la petición y su nonce.</p> </li> <li> <p>Un evento, efecto o limpieza de un componente sin observador antepasado sólo se entrega al <code>onError</code> de la aplicación o a la consola, nunca al <code>provideErrorHandler</code> de otro componente.</p> </li> <li> <p>Las interpolaciones con entidades HTML (<code>©</code>, <code><</code>) o saltos CRLF se ubican en la misma posición en <code>meeko check</code> y en VS Code: el compilador analiza el texto fuente y decodifica cada parte como el parser HTML. El analizador trata como división el <code>/</code> tras <code>i++</code>, <code>i--</code> o una propiedad con nombre de palabra clave (<code>obj.return / 2</code>) y acepta continuaciones de línea CRLF dentro de cadenas.</p> </li> <li> <p><code>meeko --help</code> y <code>meeko --version</code>.</p> </li> <li> <p>DevTools edita señales: <code>setSignal(instanceId, name, value)</code> sustituye el valor de una señal editable de una instancia activa por un valor JSON validado y responde <code>{ ok, error }</code> en lugar de lanzar. Sólo existe en desarrollo. Los dos paneles añaden el formulario <strong>Editar señal</strong>, con el error visible junto a <strong>Aplicar</strong>, y la línea de tiempo marca esas escrituras como «Escrita desde DevTools».</p> </li> <li> <p>La línea de tiempo de DevTools indica qué escribió cada señal. Sólo la compilación de desarrollo (<code>hot</code>) lo instrumenta; el código de producción y el HTML de SSR no cambian. Cubre, en el script <code>.meeko</code> y en las expresiones <code>on:</code> de la plantilla:</p> <ul> <li>las asignaciones <code>.value</code> con <code>=</code>, <code>??=</code>, <code>||=</code> y <code>&&=</code>;</li> <li>las asignaciones compuestas y <code>++</code>/<code>--</code>.</li> </ul> </li> <li> <p>Las lecturas de DevTools se ubican también en <code>computed(() => …)</code>, <code>if:when</code>, <code>each:of</code> y las props de componentes hijos, además de en las expresiones de texto y atributo.</p> </li> <li> <p>Los tipos del protocolo DevTools viven sólo en <code>src/devtools-protocol.ts</code>. La extensión de Chrome usa una copia generada (<code>pnpm run devtools:types</code>) que su <code>tsc</code> con <code>checkJs</code> comprueba, y <code>devtools:check</code> falla si esa copia queda desactualizada. La raíz exporta los nuevos tipos <code>DevtoolsReadSite</code>, <code>DevtoolsReadKind</code>, <code>DevtoolsWriteSite</code>, <code>DevtoolsAssignmentSite</code>, <code>DevtoolsEditSite</code>, <code>DevtoolsCommandResult</code>, <code>DevtoolsEventKind</code> y <code>DevtoolsProtocolVersion</code>.</p> </li> <li> <p>La extensión Meeko DevTools para Chrome pasa a la versión 1.0.0, con edición de señales, ubicaciones de escritura y lectura y aviso de protocolo no compatible.</p> </li> <li> <p>Servidor de lenguaje de Meeko: <code>meeko lsp --stdio</code> y el bin <code>meeko-language-server</code> (también <code>--node-ipc</code>, <code>--socket=<puerto></code> y <code>--pipe=<nombre></code>). Ofrece diagnósticos de <code>meeko check</code>, completado, hover, definición, referencias, renombrado entre archivos <code>.meeko</code> y <code>.ts</code>, ayuda de firma, símbolos, plegado, formato, tokens semánticos y acciones rápidas (añadir imports, resolver un autoimport ambiguo con un import explícito y quitar <code>params</code> de un <code>href</code> estático). <code>initializationOptions</code> admite <code>trusted</code>, <code>projectContracts</code> y <code>diagnosticsDelay</code>. <a href="/docs/editors">docs/editors.md</a> explica la configuración para Neovim, Helix, Zed, JetBrains (LSP4IJ) y Sublime Text. Dependencias nuevas: <code>vscode-languageserver</code>, <code>vscode-languageserver-textdocument</code>, <code>vscode-html-languageservice</code> y <code>vscode-css-languageservice</code>.</p> </li> <li> <p>En un workspace de confianza el servidor de lenguaje ejecuta <code>meeko.config.*</code>, de modo que <code>extends</code>, <code>modules</code> e <code>imports.serverDirs</code> ya no tienen que ser arrays literales para el editor; sin confianza sigue leyéndolos de forma estática.</p> </li> <li> <p>La extensión de VS Code <code>meeko-language</code> 1.0.0 es un cliente del servidor de lenguaje: usa el de <code>@meekojs/meeko</code> del proyecto cuando está instalado y el incluido como alternativa o en modo restringido.</p> </li> <li> <p>Editor: los diagnósticos cubren el token completo en lugar de un carácter, los tokens semánticos de expresiones multilínea se dividen por línea, el renombrado reescribe declaraciones e imports en otros archivos y hover, completado y navegación usan el <code>tsconfig.json</code> real del proyecto.</p> </li> <li> <p><code>meeko check</code> aplica las opciones de resolución del <code>tsconfig.json</code> de la raíz del paquete (<code>paths</code>, <code>baseUrl</code>, <code>types</code>, <code>typeRoots</code>, <code>customConditions</code>, <code>resolveJsonModule</code>, <code>allowImportingTsExtensions</code>), igual que el editor: un alias <code>paths</code> que el editor resuelve ya no se informa como <code>TS2307</code>. <code>baseUrl</code> se traduce a una correspondencia <code>*</code> porque TypeScript 7 no lo admite. Las banderas estrictas de comprobación no cambian.</p> </li> <li> <p><code>createServerApp({ manifest, load, runtime, production })</code> crea una aplicación portable con <code>fetch(request, platform?)</code>, <code>socket</code>, <code>publicOrigin</code>, <code>reportError</code> y <code>close()</code>; <code>defineServerRuntime</code> declara sesiones, servicios por petición, política de Socket, <code>publicOrigin</code>, <code>onError</code> y <code>close</code>. <code>RequestContext.platform</code> expone <code>{ name, env, waitUntil }</code>.</p> </li> <li> <p><code>@meekojs/meeko/node</code> añade <code>serveNode(app, { host, port, publicOrigin, platform, onError, handleSignals, shutdownTimeout })</code>, que conecta también Socket y espera las tareas de <code>waitUntil</code> al cerrar, y <code>createNodeAssetReader</code>. Las respuestas abiertas, como un stream, tienen <code>shutdownTimeout</code> milisegundos (10 000 por defecto) para terminar antes de que se corten sus conexiones, y un fallo al conectar Socket tras escuchar libera el puerto y cierra la aplicación. <code>toNodeListener</code> acepta <code>publicOrigin</code>.</p> </li> <li> <p>Las tareas que un callback de Socket registra con <code>context.platform.waitUntil</code> las espera <code>app.close()</code> (y por tanto <code>serveNode</code>), y sus fallos llegan al observador <code>onError</code> del runtime en lugar de la consola.</p> </li> <li> <p><code>meeko build [directorio] [--adapter <nombre>]</code> y <code>MeekoConfig.server</code> (unión discriminada; Node acepta <code>host</code> y <code>port</code>) eligen el destino del build. Con Node, <code>meeko preview</code> ejecuta el build igual que <code>meeko start</code>. El servidor de producción escucha en <code>HOST</code>/<code>PORT</code> o en los valores de <code>server</code>, con <code>127.0.0.1:4173</code> por defecto; antes sólo podía escuchar en <code>127.0.0.1</code>.</p> </li> <li> <p>Adaptadores Bun y Deno:</p> <ul> <li><code>@meekojs/meeko/bun</code> exporta <code>createBunServer(app, { publicOrigin, platform, onError, maxPayloadLength, backpressureLimit, idleTimeout, sendPings })</code>, que devuelve <code>{ fetch, websocket }</code> para <code>Bun.serve</code>, y <code>createBunAssetReader</code>.</li> <li><code>@meekojs/meeko/deno</code> exporta <code>serveDeno(app, { host, port, publicOrigin, platform, onError, maxMessageBytes, idleTimeout, handleSignals })</code> y <code>createDenoAssetReader</code>.</li> <li><code>@meekojs/meeko/server</code> añade <code>createSocketUpgradeHandler</code>, la comprobación portable de ruta, Origin y sesión previa al upgrade que comparten Node, Bun y Deno.</li> </ul> </li> <li> <p><code>meeko build --adapter bun</code> y <code>--adapter deno</code> escriben <code>.meeko/output/bun/</code> (<code>index.js</code>) y <code>.meeko/output/deno/</code> (<code>main.js</code>), junto con <code>chunks/</code>, <code>client/</code> y <code>prerender/</code>. Cada salida incluye todas las dependencias del servidor y no necesita <code>node_modules</code>. <code>meeko preview [--adapter <node|cloudflare|bun|deno>]</code> ejecuta la salida en su runtime real; para Bun y Deno lo hace como proceso hijo, que debe estar en el <code>PATH</code>.</p> </li> <li> <p>Adaptador Cloudflare Workers:</p> <ul> <li><code>@meekojs/meeko/cloudflare</code> exporta <code>createWorker(app, { socketBinding?, publicOrigin?, onError? })</code>, <code>createSocketRoomClass(app, DurableObject, { maxMessageBytes?, autoResponse?, keepHeaders?, maxPendingPublications?, rebuildTimeoutMs?, onError? })</code>, <code>DurableObjectSocketPubSub</code>, <code>socketRoomName</code>, <code>D1SessionDriver</code> (con <code>schema()</code> y <code>deleteExpired()</code>), <code>createCloudflareAssetReader</code> y <code>createCloudflarePrerenderSource</code>, más sus tipos estructurales (<code>CloudflareApp</code>, <code>CloudflareAppContext</code>, <code>CloudflareWorker</code>, <code>CloudflareWorkerOptions</code>, <code>SocketRoomOptions</code>, <code>MeekoSocketRoom</code>, <code>D1DatabaseLike</code>, <code>DurableObjectNamespaceLike</code>…). No requiere <code>@cloudflare/workers-types</code>.</li> <li>Cada sala de Socket es un Durable Object con la API de hibernación: el Worker comprueba ruta, Origin y sesión antes del upgrade, la conexión se reconstruye al despertar desde su attachment y el hub vuelve a autorizar; <code>ping</code> se responde con <code>pong</code> sin despertar el objeto. <code>DurableObjectSocketPubSub</code> es el broker por defecto y publica entre salas por RPC.</li> <li>El attachment de cada conexión guarda sólo la cookie de sesión de la cabecera <code>Cookie</code>, además de <code>origin</code> y <code>authorization</code>; <code>keepHeaders</code> añade otras cabeceras. Si el estado supera los 16.384 bytes que admite un attachment, el upgrade responde <code>431</code> y el error llega a <code>onError</code>, en lugar de cerrar la conexión con <code>1011</code> tras aceptarla.</li> <li>Una sala entrega cada publicación a los peers ya suscritos sin esperar a una conexión que todavía se autoriza; tras hibernar espera la reautorización como máximo <code>rebuildTimeoutMs</code> (5000 ms) y rechaza con <code>SOCKET_BACKLOG_EXCEEDED</code> (503) por encima de <code>maxPendingPublications</code> (1024) publicaciones sin entregar. Con nombres de más de 1.024 bytes, que el runtime no expone en <code>ctx.id.name</code>, la sala toma su nombre de la primera conexión o publicación y no se llama a sí misma por RPC. Si la aplicación no puede crearse al despertar, la sala cierra con <code>1011</code> el WebSocket que la despertó.</li> <li><code>runtime.socket.pubsub</code> sólo admite <code>DurableObjectSocketPubSub</code> en Workers: otro broker, como <code>LocalSocketPubSub</code> o <code>RedisSocketPubSub</code>, se rechaza al crear la aplicación. <code>socket.maxBufferBytes</code> no se aplica en las salas porque los WebSockets de Workers no informan de <code>bufferedAmount</code>.</li> <li><code>D1SessionDriver</code> implementa <code>SqlSessionDriver</code> con <code>replace</code> y <code>revokeFamily</code> atómicos en una sola sentencia y <code>UNIQUE(family_id)</code>. La documentación incluye el esquema, un adaptador de la API REST de Upstash para <code>RedisSessionStore</code> y por qué KV no es válido.</li> <li><code>meeko build --adapter cloudflare</code> escribe <code>.meeko/output/cloudflare/</code> con <code>worker.js</code> (un único módulo, sin <code>node_modules</code>), <code>assets/</code> (cliente, <code>public/</code> y prerender bajo <code>_meeko/prerender/</code>) y un <code>wrangler.jsonc</code> generado con <code>nodejs_als</code>, assets servidos sólo a través del Worker, el binding <code>MEEKO_SOCKET</code> y la declaración de la clase de salas. La migración <code>meeko-socket-v1</code> sólo se genera cuando <code>server.wrangler.migrations</code> está vacío; un historial existente que no crea la clase detiene el build con la entrada exacta que hay que añadir al final, y con el mapa declarativo <code>exports</code> Meeko añade la entrada de la clase si falta (combinar <code>exports</code> de Durable Objects con <code>migrations</code> es un error). <code>MeekoConfig.server</code> acepta <code>{ adapter: "cloudflare", name?, socketClassName?, compatibilityDate?, wrangler? }</code>; <code>public/_meeko/</code> queda reservado. <code>meeko preview --adapter cloudflare</code> ejecuta <code>wrangler dev</code> sobre la salida.</li> <li><code>@meekojs/meeko/server</code> añade <code>openSocketSession</code>, <code>ServerAppOptions.defaultSocketPubSub</code> y los campos opcionales <code>pubsub</code> y <code>sessionCookieName</code> de <code>ServerAppSocket</code>.</li> </ul> </li> <li> <p>Las conexiones Socket que nunca se cierran, como las de un Durable Object desalojado con sus WebSockets hibernados, ya no acumulan registros de revocación en el <code>SessionManager</code>: los registros de sesiones recolectadas se barren sin depender de los finalizadores.</p> </li> <li> <p>Suite de conformidad <code>tests/conformance/</code> (<code>pnpm run conformance</code>, <code>conformance:node</code>, <code>conformance:bun</code>, <code>conformance:deno</code>, <code>conformance:workerd</code>). Construye la misma aplicación para cada adaptador y la ejecuta sin fuentes. Comprueba SSR, API, RPC, CSRF, <code>404</code>/<code>405</code>, <code>HEAD</code>, assets con <code>ETag</code>/<code>304</code> e intentos de traversal, prerender con CSRF, orden del middleware y Socket (Origin, autenticación, límites, orden y broadcast). La variante <code>workerd</code> ejecuta la salida Cloudflare con el runtime local de Wrangler y prueba además sesiones D1, la hibernación forzada de una sala, la publicación entre salas, una cabecera <code>Cookie</code> mayor que el límite del attachment, una sala con nombre de más de 1.024 bytes y que la salida sea un único módulo. La CI añade los jobs <code>bun</code>, <code>deno</code> y <code>workerd</code> en Ubuntu y la conformidad Node en Windows; el workflow de publicación exige también esos jobs. Nueva devDependency <code>wrangler</code> 4.152.0 (trae workerd 1.20261019.1).</p> </li> <li> <p>Un único <code>publicOrigin</code> (o <code>PUBLIC_ORIGIN</code>) rige las comprobaciones de Origin de HTTP y de Socket, por lo que las mutaciones autenticadas y los WebSocket funcionan tras un proxy que termina TLS.</p> </li> <li> <p>Las páginas <code>render: "prerender"</code> se sirven por fin desde el build, pasando por el middleware de servidor, el contexto de sesión y el middleware de ruta, con la meta CSRF de la sesión insertada en <code><head></code>. Sin sesión llevan <code>ETag</code>, <code>Vary: cookie</code>, <code>cache-control: public, max-age=0, must-revalidate</code> y responden <code>304</code>; con sesión, <code>private, no-store</code>; una CDN delante debe respetar <code>Vary: cookie</code> u omitir la caché en peticiones con cookie de sesión. Un fallo de lectura de una página prerenderizada ya no queda en caché: la siguiente petición vuelve a leer el archivo. Antes el prerender se generaba sin contexto ni CSRF y nunca se servía.</p> </li> <li> <p>Los archivos públicos del build llevan <code>ETag</code>, <code>content-length</code>, <code>HEAD</code> y <code>304</code>; sólo los archivos emitidos por Vite con hash de contenido se sirven con <code>cache-control: public, max-age=31536000, immutable</code>, no los copiados de <code>public/assets/</code>. Cada archivo se sirve en la ruta que pide el navegador, también con nombres como <code>logo@2x.png</code>, <code>a+b.txt</code>, espacios o caracteres no ASCII. El HTML enlaza la entrada, su CSS y sus <code>modulepreload</code> desde el manifiesto de Vite sin reescribir el documento completo.</p> </li> <li> <p><code>toNodeListener</code> interpreta un request-target que empieza por <code>//</code> (por ejemplo <code>//evil.example/api/x</code>) como ruta del propio origen y no como otro host; antes la URL de la petición apuntaba a ese host y podía satisfacer la comprobación de Origin de una mutación con un <code>Origin</code> de ese host. <code>createServerApp</code> aplica lo mismo al reescribir la URL con <code>publicOrigin</code>.</p> </li> <li> <p><code>toNodeListener</code> cancela el cuerpo de la respuesta si el cliente se desconecta antes de recibir las cabeceras o mientras el stream espera datos, de modo que se liberan los archivos abiertos y se detienen los productores.</p> </li> <li> <p>El núcleo de servidor genera los IDs con <code>crypto.randomUUID()</code> y los tokens de sesión con <code>crypto.getRandomValues</code> y un codificador base64url propio, sin <code>node:crypto</code>.</p> </li> <li> <p>Las expresiones de texto admiten llaves anidadas: objetos literales, plantillas literales con <code>${...}</code>, cadenas que contienen <code>{</code> o <code>}</code>, comentarios y expresiones regulares. Compilador y VS Code comparten el mismo analizador, por lo que SSR, hidratación, <code>meeko check</code> y el editor ubican cada expresión en la misma posición. Una interpolación sin cerrar se informa con <code>MEEK010</code> en su llave de apertura, y <code>{}</code> se informa como expresión vacía (<code>MEEK009</code>).</p> </li> <li> <p>El código generado envuelve entre paréntesis las expresiones devueltas por funciones flecha, de modo que una expresión que empieza por <code>{</code>, como <code>bind:title="{ text: label }.text"</code>, no se interpreta como bloque.</p> </li> <li> <p>VS Code mapea los valores de directivas sin comillas, como <code>on:click=handler</code> o <code>each:of=items</code>, con la misma lógica que el compilador; sus diagnósticos, navegación y renombrado ya no se omiten.</p> </li> <li> <p><code><style scoped></code> admite <code>:global(<selector>)</code>: el selector interno se emite sin el atributo de ámbito, que se añade al último compuesto local (<code>.card :global(.icon)</code> produce <code>.card[data-meeko-s-…] .icon</code>). <code>:global</code> sin selector, con una lista de selectores o anidado en otra pseudoclase falla con <code>MEEK019</code> en su posición.</p> </li> </ul> <h3 id="publicación">Publicación<a class="heading-anchor" href="#publicaci%C3%B3n" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Una versión con sufijo de prerelease (<code>1.0.0-rc.1</code>) se publica en npm con el dist-tag <code>next</code> y no mueve <code>latest</code>. La publicación sigue usando OIDC sin token de npm.</li> <li>La etiqueta <code>v<versión></code> adjunta a su release de GitHub los seis VSIX de VS Code, el ZIP de Chrome DevTools y <code>SHA256SUMS.txt</code>, y crea la release como prerelease cuando la versión lo es. Sólo ese job tiene <code>contents: write</code>, e <code>id-token: write</code> queda limitado al job de npm.</li> <li>Nuevos workflows <code>publish-vscode.yml</code> (etiquetas <code>vscode-v*</code>, Visual Studio Marketplace y Open VSX) y <code>publish-devtools.yml</code> (etiquetas <code>devtools-v*</code>, API v2 de Chrome Web Store). Comprueban la versión de la etiqueta y ejecutan las pruebas de la extensión antes de publicar, y omiten cada tienda sin fallar mientras falten sus secretos (<code>VSCE_PAT</code>, <code>OVSX_PAT</code>, <code>CHROME_EXTENSION_ID</code>, <code>CHROME_PUBLISHER_ID</code>, <code>CHROME_CLIENT_ID</code>, <code>CHROME_CLIENT_SECRET</code>, <code>CHROME_REFRESH_TOKEN</code>). <a href="https://github.com/meekojs/meeko/blob/main/docs/releasing.md">docs/releasing.md</a> explica el alta de cada cuenta.</li> <li><code>package-zip.ps1 -RootLayout</code> genera el ZIP de Chrome DevTools con <code>manifest.json</code> en la raíz, como exige Chrome Web Store; sin el switch conserva la carpeta <code>meeko-devtools/</code>.</li> </ul> <h2 id="010---2026-10-25">[0.1.0] - 2026-10-25<a class="heading-anchor" href="#010---2026-10-25" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <p>Este bloque contiene cambios incompatibles respecto de <code>0.0.4</code>. De acuerdo con la política SemVer de Meeko para la serie <code>0.x</code>, se publica como <code>0.1.0</code>, no como un patch.</p> <h3 id="cambios-incompatibles-y-migración-1">Cambios incompatibles y migración<a class="heading-anchor" href="#cambios-incompatibles-y-migraci%C3%B3n-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li><code>effect</code> y <code>onCleanup</code> sólo aceptan callbacks síncronos. Inicie el trabajo asíncrono desde un callback síncrono, observe sus errores y gestione explícitamente su cancelación; no devuelva una promesa al runtime reactivo.</li> <li>Los stores persistentes personalizados deben conservar <code>familyId</code> e implementar <code>replace</code> y <code>revokeFamily</code> de forma atómica. Migre registros e índices antes del arranque en producción: <code>SessionManager({ production: true, ... })</code> rechaza un store incompleto; en desarrollo, la operación que necesite una capacidad ausente falla de forma explícita.</li> <li><code>render: "client"</code> ya no forma parte del contrato de páginas. Elimínelo para usar SSR, que continúa siendo el valor predeterminado, o use <code>render: "prerender"</code> cuando corresponda.</li> <li>Los proyectos generados activan <code>verbatimModuleSyntax</code>, <code>noUncheckedIndexedAccess</code> y <code>exactOptionalPropertyTypes</code>. Use <code>import type</code>, compruebe accesos por índice y declare <code>| undefined</code> explícitamente cuando la ausencia sea un valor permitido.</li> <li>Los contratos Standard Schema públicos deben resolver a tipos concretos. Sustituya <code>any</code>, <code>unknown</code>, <code>never</code>, parámetros genéricos no resueltos y tipos anidados inseguros por tipos públicos concretos de entrada y salida.</li> <li>Las rutas estáticas ya no aceptan <code>params</code>; las rutas API/RPC que forman jerarquías ambiguas o no representables deben renombrarse. Los parámetros dinámicos deben corresponder exactamente con la URL. Las queries públicas deben aceptar texto o listas de texto y modelar como opcionales las claves que puedan faltar; transforme números dentro del schema.</li> <li>Los contratos de componentes, páginas, layouts y errores validan las props que el host realmente suministra. Declare esas props precisas y no ensanche un componente para ocultar requisitos obligatorios.</li> <li>Para migrar un starter full-stack de <code>0.0.4</code>, adopte <code>meeko dev</code>, <code>meeko check</code>, <code>meeko build</code> y <code>meeko start</code>; compare primero cualquier personalización y después retire <code>server.mjs</code>, las entradas cliente/servidor, las configuraciones Vite y los <code>tsconfig.*</code> ahora generados bajo <code>.meeko/</code>. Puede mover el layout raíz a <code>app/layouts/default.meeko</code>, pero no lo conserve a la vez que <code>app/pages/+layout.meeko</code>.</li> </ul> <h3 id="añadido-y-corregido-1">Añadido y corregido<a class="heading-anchor" href="#a%C3%B1adido-y-corregido-1" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>La revocación de sesiones ahora invalida atómicamente la familia activa después de rotaciones concurrentes en memoria, Redis y SQL. Los drivers SQL personalizados deben migrar <code>familyId</code> e implementar <code>revokeFamily</code>; los stores de producción antiguos fallan al iniciar. VS Code aplica las mismas opciones estrictas de TypeScript que la CLI, HMR acepta IDs de módulo con caracteres de selector CSS y Socket comunica errores del transporte al observador activo.</li> <li>El descubrimiento rechaza colisiones jerárquicas que convertirían un miembro <code>api</code> o <code>rpc</code> simultáneamente en función y objeto. El starter independiente observa y conserva los fallos al cerrar HTTP y Vite mediante <code>SIGINT</code> o <code>SIGTERM</code>.</li> <li>La generación de tipos registra las declaraciones de componentes que administra y elimina las huérfanas tras borrar o renombrar una fuente. La adopción desde versiones anteriores usa el AST del contrato generado y conserva declaraciones ajenas.</li> <li>Los autoimports conservan parámetros, restricciones y defaults de tipos genéricos reexportados y deduplican overloads del mismo símbolo. Los proyectos generados usan las mismas opciones estrictas que CLI y VS Code.</li> <li>API, RPC y Socket rechazan schemas Standard Schema degradados a <code>any</code>, <code>unknown</code> o <code>never</code>, incluidos parámetros genéricos no resueltos y tipos inseguros anidados; el descubrimiento rechaza APIs raíz sin clave y rutas jerárquicas imposibles de representar. Si el arranque falla, los errores adicionales de cierre llegan al observador sin sustituir la causa original.</li> <li><code>onCleanup</code> exige callbacks síncronos en tipos y runtime; un retorno thenable se observa sin <code>unhandledRejection</code>, no impide las demás limpiezas y participa en el <code>AggregateError</code> de la raíz.</li> <li>VS Code tipa <code>each:index</code> como <code>number</code>, igual que el compilador. La navegación solicita volver a la URL confirmada si falla <code>pushState</code> o <code>replaceState</code>, y preserva los errores de recuperación.</li> <li><code>+error.meeko</code> conserva el contexto SSR de la petición, incluso en peticiones concurrentes; el cliente ignora tokens CSRF de respuestas anteriores a un cambio de sesión o navegación, y VS Code comprueba los tipos de <code>on:event</code> y <code>each:key</code> como el CLI.</li> <li>HMR restaura listeners y todas las raíces del módulo si falla su limpieza o una actualización posterior, mientras el adaptador Node conserva el <code>requestId</code> ya enviado al cliente cuando falla un stream de respuesta.</li> <li>El outlet del starter y los contratos de layout validan con mayor precisión el <code>Component</code>, sus props y la transferencia de estado SSR; los reemplazos de componentes y listas conservan la región previa cuando falla su hidratación o movimiento, y Socket intenta cerrar el peer aunque falle la desuscripción.</li> <li><code>provideErrorHandler</code> permite observar errores de eventos por raíz de componentes con autoimport y tipo <code>unknown</code>; HMR conserva el contexto padre al reemplazar o restaurar una instancia.</li> <li>La navegación y los canales Socket de una aplicación montada consultan su observador activo; <code>socket</code> autoimportado conserva conexiones por aplicación y libera listeners al desmontar componentes. HMR preserva el fallo original si también falla el rollback.</li> <li>Los scripts <code>.meeko</code> admiten llamadas de expresión durante el setup para registrar hooks sin declaraciones artificiales.</li> <li>Tipado de defaults de <code>defineProps</code>, props de componentes hijos y contratos entre páginas y sidecars de ruta.</li> <li>Hidratación de expresiones de texto inicialmente vacías sin perder eventos, verificada con el componente de login original en Chrome.</li> <li>Comprobación TypeScript por ámbito de las fuentes de app, shared, servidor, layers y módulos configurados.</li> <li>Errores de servidor normalizados con <code>requestId</code> en páginas, API, RPC y WebSocket; cierre más robusto de recursos Node.</li> <li>Los fallos de limpieza de raíces y componentes compilados conservan también el error original; los fallos de navegación cliente por historial y clic se observan sin rechazos pendientes.</li> <li>Los contratos de páginas, layouts y páginas de error rechazan props inseguras; el editor muestra esos diagnósticos sobre <code>defineProps</code> al abrir o guardar el proyecto.</li> <li>Los componentes recibidos como props comprueban también si sus props obligatorias pueden omitirse; el editor actualiza diagnósticos y colores al guardar módulos TypeScript importados.</li> <li>Las rutas sin parámetros rechazan <code>params</code> en TypeScript; el editor vuelve a comprobar contratos de páginas cuando cambia un tipo importado por un sidecar.</li> <li>Las navegaciones descartadas no conservan estado provisional ni tokens CSRF, y los observadores reactivos pendientes terminan de ejecutarse aunque otro falle.</li> <li>Socket comunica fallos de listeners, observadores de estado y reconexión, ignora mensajes de conexiones reemplazadas y continúa un broadcast hacia peers sanos si uno falla.</li> <li>Los observadores de errores de navegación y servidor pueden ser asíncronos sin producir rechazos sin manejar; si fallan, Meeko informa el fallo sin sustituir la respuesta original.</li> <li>Los handlers <code>on:event</code> asíncronos ya entregan su promesa al runtime para registrar rechazos; los errores de TypeScript de módulos <code>.ts</code> importados señalan su archivo y posición reales.</li> <li>Eventos, navegación, Socket y DevTools comparten una captura interna de callbacks síncronos y asíncronos; los E2E fallan también ante errores de consola.</li> <li><code>effect</code> rechaza callbacks que devuelven promesas en tipos y runtime; un rechazo asíncrono concurrente queda observado y registrado. Las aplicaciones que usaban <code>effect(async () => ...)</code> deben iniciar el trabajo asíncrono desde un callback síncrono y manejar su cancelación.</li> <li>Los contratos API rechazan <code>params</code> que no coincidan con la ruta y valores de <code>query</code> incompatibles con el transporte URL.</li> <li>La limpieza de listas libera todos los hijos aunque falle un release o una hidratación posterior; el middleware HTTP propaga fallos de <code>next()</code> aunque su autor no lo espere.</li> <li>El adaptador HTTP Node conserva varias cookies <code>Set-Cookie</code> y detiene el streaming cuando el cliente se desconecta.</li> <li>Comandos de proyecto generados por Meeko, layouts en <code>app/layouts</code>, middleware de rutas y HTTP, y validación ampliada del consumidor externo.</li> <li>CI selecciona el tarball generado por el build en lugar de fijar el nombre de una versión publicada.</li> <li>El workflow de publicación exige ahora las pruebas de la extensión VS Code sobre el SHA del tag.</li> </ul> <h2 id="004---2026-10-24">[0.0.4] - 2026-10-24<a class="heading-anchor" href="#004---2026-10-24" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <h3 id="framework-full-stack">Framework full-stack<a class="heading-anchor" href="#framework-full-stack" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Rutas basadas en archivos con parámetros y navegación tipados, layouts persistentes, SSR e hidratación.</li> <li>Estado <code>useState</code> aislado por petición, prerender y composición de módulos y layers.</li> <li>Starter <code>meeko init-framework</code> y generación de manifiestos mediante CLI y Vite.</li> </ul> <h3 id="autoimports-y-tipos">Autoimports y tipos<a class="heading-anchor" href="#autoimports-y-tipos" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Autoimports tipados en <code>.meeko</code> y <code>.ts</code> para componentes, composables, stores y utilidades; símbolos <code>api</code>, <code>rpc</code>, <code>socket</code> y <code>useSocket</code>.</li> <li>Declaraciones TypeScript generadas por ámbito, con separación entre código cliente, servidor y shared.</li> </ul> <h3 id="servidor">Servidor<a class="heading-anchor" href="#servidor" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>API HTTP y RPC tipados mediante contratos Standard Schema; despacho RPC local durante SSR con la misma validación y autorización.</li> <li>Sesiones con adaptadores Redis y SQL, y canales WebSocket con transporte Node.</li> <li>Validación de entradas y salidas, autorización y errores normalizados.</li> </ul> <h3 id="seguridad-y-correcciones">Seguridad y correcciones<a class="heading-anchor" href="#seguridad-y-correcciones" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Aislamiento de peticiones SSR, protección CSRF y límites de imports entre cliente y servidor.</li> <li>Protección de rutas públicas y layers frente a enlaces simbólicos que salen del proyecto.</li> <li>Comprobaciones de Origin y autorización de WebSocket; <code>ws</code> se carga sólo al activar el adaptador Node.</li> </ul> <h3 id="verificación-y-herramientas">Verificación y herramientas<a class="heading-anchor" href="#verificaci%C3%B3n-y-herramientas" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h3> <ul> <li>Mejoras de Vite y CLI, source maps de JavaScript con fuentes embebidas y baseline reproducible de rendimiento.</li> <li>Consumidor externo desde tarball, integración con Redis real en CI y E2E en Chromium, Firefox y WebKit.</li> </ul> <h2 id="003">0.0.3<a class="heading-anchor" href="#003" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <ul> <li><code>meeko init .</code> configura una carpeta recién preparada con pnpm, conserva su manifiesto y archivos del gestor, y rechaza proyectos que ya contienen código o scripts incompatibles.</li> <li>Hidratación sin escrituras iniciales redundantes de texto y atributos; señales sin lectores y filas que no usan el índice asignan menos memoria.</li> <li>Reconciliación de listas con claves que conserva regiones ordenadas y evita movimientos innecesarios; hidratación inicial sin reconciliación cuando el estado SSR sigue intacto.</li> <li>Aplicación piloto con SSR, hidratación, formularios, navegación, componentes anidados y API asíncrona, probada en desarrollo y producción con Chromium, Firefox y WebKit.</li> <li><code>meeko init <directorio></code> genera un proyecto SSR independiente que fija la versión exacta de su compilador y runtime.</li> <li>Línea de tiempo de señales en ambos paneles DevTools, con componente, valor seguro y expresiones de texto o atributo que leen cada señal, ubicadas en el <code>.meeko</code>.</li> <li>Primera publicación npm mediante Trusted Publishing, con procedencia firmada desde <code>meekojs/meeko</code> y <code>publish.yml</code>.</li> </ul> <h2 id="002">0.0.2<a class="heading-anchor" href="#002" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <ul> <li>DevTools experimental para inspeccionar instancias hidratadas, props, señales, eventos, árbol de componentes y estado de hidratación durante el desarrollo con Vite.</li> <li>Panel integrado y extensión local de Chrome DevTools con selección, resaltado y puntos de parada por instancia.</li> <li>Ruta <code>@meekojs/meeko/internal</code> para el runtime generado por el compilador. Los exports internos anteriores siguen disponibles en la raíz durante la serie experimental para conservar compatibilidad.</li> <li>Configuración de depuración de la extensión de VS Code y ampliaciones de sus verificaciones y de los benchmarks reproducibles.</li> </ul> <p>La sintaxis y las API de la serie <code>0.x</code> siguen siendo experimentales. El compilador y su runtime deben usar la misma versión del paquete.</p> <h2 id="001">0.0.1<a class="heading-anchor" href="#001" aria-label="Enlace a esta sección" data-pagefind-ignore>#</a></h2> <ul> <li>Primera versión pública con componentes <code>.meeko</code>, SSR, hidratación, señales reactivas, plugin de Vite, HMR, CLI y extensión local de VS Code.</li> </ul>

Contenidos

Cambios de Meeko

1.9.0 — 2026-11-05#

1.8.0 — 2026-11-04#

¿Te sirvió esta página?