# Construir para producción
Elige el build por toolchains o nativo, configura PWA y presupuestos y verifica los artefactos.
Requiere WU CLI `1.2.0` y, para las APIs de las aplicaciones, WU Framework `4.0.0`. Comprueba `wu --version` y las dependencias del proyecto.
## Dos caminos de construcción
```sh
wu build
wu build --native
wu serve 4100
```
`wu build` conserva el camino por toolchains: construye shell y apps mediante sus comandos, reúne resultados en `dist/`, escribe manifiestos y genera políticas HTTP. `wu build --native` inicia el servidor WU en modo producción, recorre el grafo de módulos y publica sus respuestas como archivos estáticos. Elige un camino por build; ambos requieren revisar el resultado en el navegador.
| Opción | Efecto |
| --- | --- |
| `--native` | Construye desde las respuestas del servidor WU. |
| `--no-pwa` | Desactiva PWA en el build nativo actual. |
| `--budget-warn` | Convierte exceder el presupuesto en aviso. |
| `--jobs `, `-j ` | Entre 1 y 64 builds simultáneos; defecto `min(CPU, 4)`. |
| `--no-cache` | No reutiliza salidas de `.wu-cache/builds/`. |
| `--sign ` | Firma `dist/wu-integrity.json` con ECDSA P-256. |
No hay flags `--watch`, `--app`, `--out-dir` o `--minify`. Un fallo de compilación, una app sin salida, un archivo que no puede escribirse o un presupuesto excedido devuelve `1`. El build trabaja en `dist.tmp-/` y solo reemplaza `dist/` al terminar correctamente; un fallo conserva el build anterior y deja evidencia en `dist.failed/`. Un segundo build concurrente se rechaza mediante `.wu-cache/build.lock`.
## Caché de compilación y builds anteriores
Las apps sin cambios recuperan su salida de `.wu-cache/builds/`. La clave incluye fuentes locales, `.env*`, manifiesto raíz, lockfiles, overrides, comando, framework, módulos compartidos y versión CLI. Fuentes importadas fuera del directorio de app y ediciones en `node_modules` no se detectan: usa `--no-cache`. En Windows tampoco se incluyen variables del proceso; evita reutilizar caché después de cambiarlas.
`build.keepPreviousBuilds` conserva archivos con hash de dos builds anteriores por defecto; `0` conserva solo el actual. El registro privado `dist/.wu-builds.json` permite que pestañas antiguas sigan cargando sus chunks. En CI limpio debes conservar `dist/` entre builds o usar un host que retenga esos archivos. HTML, manifiestos y service worker pertenecen solo al build actual.
```json
{ "build": { "keepPreviousBuilds": 2 } }
```
## Un runtime compartido
La CLI detecta imports `wu-framework` y sus subpaths del navegador, comparte core y crea el import map del build convencional. Para externalizar esos imports, `build_cmd` debe exponer una invocación directa de `vite build`. Un comando opaco como `npm run build` puede impedir que WU inserte externals y aliases; comprueba el aviso y las peticiones de módulos.
`wu create` prepara `shared` para los frameworks generados y `wu add` lo amplía. Compartir React o Preact incluye el runtime JSX que emite el compilador. Importa explícitamente los [subsistemas opcionales](/es/docs/framework/runtime-composition/) que use el shell. Si una toolchain local falta, ejecuta `wu install`; no asumas que la CLI sustituirá esa versión por otra de raíz.
Los import maps se insertan o fusionan en todas las páginas HTML, después de ``; los fragmentos y archivos mayores de 8 MiB se omiten. Compartir un adaptador Qwik o Svelte comparte también su runtime. Las entradas que WU genera incluyen SRI en scripts y modulepreloads, e `integrity` en el import map. Los scripts auxiliares generados son externos.
## Qué publica el build nativo
El build nativo recorre todas las páginas del shell y las entradas de apps. Publica módulos, CSS y assets con nombres derivados de SHA-256; sustituye el antiguo `?v=`. El contenido sin cambios conserva URL e identidad de módulo. Los errores de compilación detienen el build en lugar de publicar el módulo de overlay.
Los imports dinámicos con URL calculada no se descubren recorriendo imports literales. Los `.module.css` todavía conservan la inyección de estilo del servidor de desarrollo. Verifica esos casos antes de elegir el build nativo; conserva el build por toolchains cuando tu aplicación necesita un procesamiento distinto.
## PWA, caché y actualizaciones
El build nativo genera `wu-sw.js`, `wu-sw-register.js`, `manifest.webmanifest` e icono cuando PWA está habilitado. Precarga los archivos descubiertos; navegación y catálogos consultan primero la red y usan caché sin conexión. No precarga automáticamente datos de APIs externas ni archivos que el grafo no descubrió.
`pwa: false` en la raíz de `wu.config.json` o `--no-pwa` desactivan esa generación. Un manifest del shell se conserva. El worker sirve las apps instaladas en `/@wuapp/` desde la caché `wu-apps` y conserva esa caché al actualizar el build. Escucha `wu:update-available` y `wu:sw` si el shell necesita mostrar el estado de actualización.
El nuevo worker espera mientras hay otras ventanas abiertas. El evento `wu:update-available` expone `event.detail.activate()` para activar el reemplazo desde una decisión del shell. Las navegaciones sin red recuperan su propia página; las APIs del mismo origen no entran automáticamente en la caché del sitio.
## Presupuestos por app
```json
{ "budget": "150kb", "apps": [
{ "name": "cart", "dir": "mf-cart", "framework": "react", "port": 5001, "budget": "80kb" }
] }
```
El presupuesto de app prevalece sobre el de raíz. Se aceptan bytes numéricos o unidades como `80kb` y `1.5mb`, con base 1024. Se cuentan `.js`, `.mjs` y `.css` sin comprimir; imágenes y fuentes quedan fuera. Excederlo devuelve `1` y conserva el `dist/` anterior. `--budget-warn` conserva el aviso sin fallar el build. Es un límite de tu proyecto, no una comparación de rendimiento con otros frameworks.
## Revisar el resultado
Comprueba `dist/wu-manifest.json`, las entradas de las apps, `_headers`, `vercel.json` y `wu-security.conf`. Sirve `dist/`, recarga rutas interiores, monta cada app, comprueba CSS, comunicación y consola. Prueba también una recarga sin red cuando uses PWA. Para distribuir una sola app, continúa con [wu pack](/es/docs/cli/pack/).
## Publicar y verificar un build firmado
```sh
wu pack --keygen keys/deploy.pem
wu build --sign keys/deploy.pem
wu doctor --url https://example.com --integrity --pubkey keys/deploy.pub.json --json
```
Guarda la JWK pública que imprime `--keygen` en `keys/deploy.pub.json`. Publica todo `dist/`, incluido `wu-integrity.json`, con los archivos de política del mismo build. El manifiesto firmado registra hashes, tipos, import maps y CSP por página. `doctor --integrity` verifica firma y respuestas; sin `--pubkey` solo comprueba la clave incluida en el propio manifiesto, no una identidad confiable.
El CDN debe conservar bytes, MIME, CSP e import maps: una transformación automática después de firmar invalida la verificación. Usa caché inmutable solo para archivos con hash y revalida HTML, manifiestos y worker. No borres chunks anteriores durante la ventana de retención. WU genera políticas por página para `_headers`, `vercel.json` y `wu-security.conf`, conserva `_headers` del shell y avisa sobre límites de reglas y longitud de Cloudflare.
## Referencia de implementación
- `wu-cli/src/commands/build.zig`
- `wu-cli/src/commands/build-native.cjs`
- `wu-cli/src/commands/deploy.zig`
- `wu-cli/src/commands/build_cache.zig`
- `wu-cli/tests/build-deploy.test.cjs`
- `wu-cli/tests/build-native-pages.test.cjs`
- `wu-cli/tests/build-failures.test.cjs`
- `wu-cli/tests/build-shares-adapter-runtime.test.cjs`