@wu-framework/cli 0.5.0 → 0.5.2

package/CHANGELOG.md

@@ -2,12 +2,79 @@
 
 Todos los cambios notables de wu-cli. Formato basado en [Keep a Changelog](https://keepachangelog.com/) y [SemVer](https://semver.org/).
 
+## [0.5.2] — 2026-08-29 — resolución Angular en Windows
+
+### Corregido
+
+- El compilador de desarrollo Angular usa el resolvedor de Node como puente en
+  Windows cuando esbuild no puede enumerar un directorio padre. Esto evita el
+  falso `Cannot read directory "../../..": Access is denied` y los errores
+  derivados que afirmaban que `zone.js`, Angular, Wu y los imports locales no
+  existían aunque estuvieran instalados.
+- El resolvedor cubre paquetes, chunks relativos e imports TypeScript sin
+  extensión, y conserva el diagnóstico original de esbuild cuando Node tampoco
+  puede resolver la solicitud.
+- Una prueba de regresión fija el comportamiento para paquetes con `exports`,
+  chunks internos, módulos locales TypeScript y rutas realmente ausentes.
+
+## [0.5.1] — 2026-08-29 — fiabilidad del desarrollo local
+
+### Corregido
+
+- El compilador Angular resuelve las hojas CSS importadas desde TypeScript sin
+  tratarlas como imports JavaScript, tanto en desarrollo como en HMR.
+- `wu dev` y `wu serve` rechazan de forma inmediata y legible un puerto ya
+  ocupado, incluido Windows, en vez de anunciar un servidor que no inició o
+  dejar dos procesos disputando el mismo listener.
+- `wu doctor` reconoce dependencias locales absolutas `file:C:/...` en Windows.
+- Los scaffolds conservan metadatos completos, usan estilos externos compatibles
+  con CSP y evitan HTML dinámico inseguro en el shell vanilla.
+- Las plantillas Vanilla, Svelte, Solid, Stencil, Alpine, HTMX y Stimulus usan
+  CSS externo y controles accesibles, sin atributos de estilo que la CSP de
+  producción termine bloqueando.
+- El scaffold Stimulus conserva el contrato `{ controllers, template }` que
+  consume su adapter; el controlador y sus acciones se mantienen aislados en
+  la configuración generada.
+- Alpine se genera con el runtime oficial `@alpinejs/csp` inyectado y un
+  proveedor aislado por app; HTMX se importa realmente, desactiva evaluación y
+  scripts inline mediante su meta-config previa al import, usa estilos de
+  indicadores externos y limpia sus listeners al desmontar.
+- Los proyectos nuevos fijan `wu-framework@^3.0.1`, la primera versión estable
+  que expone la inyección de runtime usada por estos scaffolds.
+
 ## [0.5.0] — 2026-08-29 — alineación con wu-framework 3
 
 ### Cambiado
 
-- Los proyectos nuevos usan `wu-framework@^3.0.0-beta.2`, declaran Node 20+ y
+- Los proyectos nuevos usan la versión estable `wu-framework@^3.0.0`, declaran Node 20+ y
   `wu doctor` detecta rangos de registro que todavía resuelven a V2.
+- Los shells generados conservan el objeto completo de cada micro-app al
+  inicializar Wu; ya no pierden `framework`, ownership DOM, grants ni
+  compatibilidad al recalcular su URL.
+- Los shells Vite nativos usan una hoja CSS externa compartida y el shell
+  vanilla construye sus nodos con DOM seguro. Esto elimina atributos `style`
+  dinámicos y concatenaciones `innerHTML` sin relajar la CSP de producción.
+- Cada shell incluye un favicon SVG real en `public/`; desarrollo ya no genera
+  un 404 por depender del icono implícito del navegador.
+- `wu install` conserva correctamente rutas `file:C:/...` y `file:C:\\...` en
+  Windows; antes las convertía en junctions relativos inválidos aunque npm
+  terminara con éxito. Las pruebas de `install.zig` ya forman parte de la suite
+  agregada y dejan de ser tests escritos que nunca se ejecutaban.
+- `wu doctor` reconoce esas mismas rutas absolutas de Windows y UNC como un
+  único destino en todos los `package.json`; ya no inventa rutas como
+  `shell/C:/...` ni contradice el resultado correcto de `wu install`.
+- Los listeners de `wu dev` y `wu serve` ya no solicitan `SO_REUSEADDR` ni
+  `SO_REUSEPORT`; además mantienen una lease de host/puerto entre procesos Wu
+  en Windows, donde el backend AFD de Zig acepta dos binds aun sin reuse. Un
+  segundo servidor termina con un error claro en vez de arrancar aparentemente
+  y repartir tráfico entre dos proyectos; `wu serve` sólo anuncia su URL
+  después de poseer realmente el puerto.
+- Las apps React generadas inyectan en el adapter el mismo runtime que compiló
+  el componente y esperan su registro. Esto evita dos copias de React en chunks
+  de producción y el fallo de hooks que sólo aparecía después de `wu build`.
+- El componente React inicial usa `App.css`, clases y controles accesibles en
+  lugar de objetos `style`; el scaffold funciona con la CSP estricta que el
+  propio `wu build` publica.
 - `apps[].grants` y `apps[].compatibility` forman parte del schema del CLI y se
   propagan sin pérdida por desarrollo, build, `apps.json`, `wu-manifest.json` y
   shells generados.

package/README.md

@@ -32,7 +32,7 @@
 
 **Wu CLI** es un CLI + dev-server nativo en **Zig 0.16** para arquitecturas microfrontend ([wu-framework](https://www.wu-framework.com)). Reemplaza **N procesos Vite** (uno por micro-app) con **un único proceso en un solo puerto** que descubre, compila, sirve y hace HMR. Sin dependencias Zig, binario de ~250-460 KB por plataforma, distribuido vía npm.
 
-## Estado actual (código v0.5.0)
+## Estado actual (código v0.5.2)
 
 Las versiones de `package.json`, `src/main.zig` y `build.zig.zon` están
 sincronizadas y una invariante de CI evita que vuelvan a divergir. Consulta el

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wu-framework/cli",
-  "version": "0.5.0",
+  "version": "0.5.2",
   "description": "Native Zig dev server + CLI for wu-framework microfrontends. One binary, one port, all your micro-apps.",
   "license": "MIT",
   "author": "Wu Framework Team",