Llevar una aplicación Angular a producción requiere algo más que pulsar un botón. El comando ng build compila y optimiza tu proyecto, pero también te alerta sobre malas prácticas que pueden inflar el peso final. Aquí te muestro qué pasa cuando ejecutas esa compilación, dónde queda el resultado y cómo manejar los warnings sin sacrificar buenas prácticas.

Qué hace ng build cuando preparas tu aplicación Angular

Mientras desarrollas, lo normal es tener ng serve corriendo para ver cambios en tiempo real. Pero ese modo está pensado para debugging, no para entregar tu app al usuario final.

Antes de compilar, apaga el ng serve desde la terminal. Luego ejecuta:

bash ng build

Este comando deja de lado el modo desarrollo y empieza tareas de optimización: minifica archivos, procesa estilos y deja todo lo más liviano posible para que tu aplicación cargue rápido en producción [01:00].

¿Qué diferencia hay entre ng serve y ng build? ng serve levanta un servidor local para desarrollo con recarga automática. ng build compila y minifica los archivos para subirlos a un hosting en producción.

Por qué Angular lanza un error de tamaño en archivos CSS

Al correr ng build por primera vez, es probable que aparezca un error que dice que un archivo CSS excede el máximo permitido. No es un bug, es una de las buenas prácticas que Angular aplica por defecto.

El framework te está avisando que ese archivo de estilos está demasiado pesado y que debería dividirse mejor. La solución correcta a largo plazo es adoptar programación basada en componentes, repartiendo estilos y lógica en piezas más pequeñas y mantenibles [01:30].

Cómo modificar el límite de tamaño en angular.json

Si necesitas compilar de forma puntual sin reestructurar el proyecto, puedes ajustar el límite en el archivo angular.json. Busca la regla anyComponentStyle, que es la que dispara el error cuando un estilo supera cierto peso.

Por defecto, el máximo está en 4 kilobytes. Si tu archivo pesa 4.96 KB, puedes subir el límite a 5 KB y volver a compilar. El proceso queda así:

1. Abre angular.json en la raíz del proyecto.
2. Localiza la propiedad anyComponentStyle dentro de los budgets.
3. Sube el valor maximumError al tamaño que necesites.
4. Guarda y vuelve a ejecutar ng build.

Esta no es una práctica recomendada. Hazlo solo de forma consciente y temporal, sabiendo que más adelante optimizarás con componentes [02:30].

Qué significan los warnings después de compilar con ng build

Una vez ajustado el límite, la compilación se completa, pero Angular sigue mostrando un warning. Ya no es un error que detenga el proceso, sino una advertencia que te recuerda que el archivo sigue siendo pesado y que deberías optimizarlo.

Esa diferencia importa: el error bloquea el build, el warning solo te avisa. Asumir el warning de forma consciente está bien mientras aprendes; ignorarlo siempre, no.

¿Por qué Angular muestra warnings de rendimiento? Porque archivos grandes hacen que tu aplicación cargue más lento para el usuario final. Los warnings son recordatorios de optimización, no obligaciones inmediatas.

Dónde queda el resultado de la compilación de Angular

Cuando ng build termina, genera una carpeta llamada dist en la raíz del proyecto. Dentro encuentras una subcarpeta con el nombre de tu aplicación, que normalmente coincide con el nombre del proyecto.

Si tu proyecto se llama curso-angular, la ruta será dist/curso-angular. Si lo nombraste to-do-app, será dist/to-do-app. Verifica siempre cuál es tu carpeta exacta, porque esa dirección la vas a necesitar al hacer deployment [04:00].

Dentro de esa carpeta encontrarás:

• Archivos JavaScript minificados.
• Estilos CSS ya procesados y comprimidos.
• El index.html listo para servirse.
• Assets y recursos estáticos optimizados.

Todo ese contenido es lo que subes a un hosting de archivos estáticos para que tu aplicación esté disponible en internet. Servicios como Firebase Hosting, Netlify, Vercel o GitHub Pages aceptan este tipo de carpetas sin configuración adicional.

Qué hacer antes de subir tu app Angular a producción

Antes del deploy, conviene revisar un par de cosas para evitar sorpresas:

• Confirma que no quedaron errores activos, solo warnings asumidos.
• Verifica el nombre exacto de la carpeta dentro de dist.
• Revisa que los estilos y componentes pesados estén en tu lista de mejoras futuras.
• Prueba la versión compilada localmente con un servidor estático antes de subirla.

Esa última prueba te ahorra dolores de cabeza, porque a veces algo funciona en ng serve pero falla en producción por rutas o configuraciones específicas del build.

¿Ya intentaste compilar tu primera app Angular para producción? Cuéntame en los comentarios qué warnings te aparecieron y cómo los resolviste.