Angular CLI más allá de ng serve: generadores, destinos, caché y estadísticas de compilación

La mayoría de los desarrolladores de Angular se limitan desde el principio a cuatro comandos: ng serve, ng build, ng generate y ng test, sin buscar más allá. Eso funciona para una aplicación pequeña, pero a medida que el espacio de trabajo crece, el tiempo dedicado a escribir código genérico, buscar números de versión, estimar el tamaño del paquete y solucionar problemas en los cachés se acumula. La CLI ya cuenta con soluciones para la mayoría de estas tareas. Esta guía explica las opciones que vale la pena hacer habituales, indica cuándo ayuda cada una y termina con un flujo de trabajo diario compacto que puedes adoptar tal como está.

Si aún estás en la fase de crear el espacio de trabajo, la guía sobre configurar un proyecto moderno de Angular aborda esa parte; todo lo que sigue supone que ya existe un proyecto.

Saque el máximo provecho de ng generate

El generador es la orden que todos conocen en su forma completa:

ng generate component user-profile

Cada generador tiene un alias corto; por lo tanto, generate se convierte en g y component en c:

ng g c user-profile

El verdadero ahorro proviene de las banderas. Cuando un componente presentacional pequeño no requiere un archivo de especificaciones, --skip-tests impide que la CLI cree uno:

ng g c user-profile --skip-tests

Por defecto, cada componente se guarda en su propia carpeta. --flat escribe los archivos directamente en el directorio actual, lo cual es adecuado para componentes pequeños que se encuentran junto a su carpeta padre:

ng g c user-profile --flat

Las banderas se combinan, por lo que puede solicitarlas ambas al mismo tiempo:

ng g c user-profile --flat --skip-tests

Las mismas opciones se aplican a servicios, directivas, tuberías, protectores y los demás esquemas. Permitir que el generador cree archivos mantiene la consistencia en los nombres y la estructura entre todo el equipo. Añada --dry-run para ver qué crearía un esquema sin escribir nada.

Pregunte a la CLI en lugar de buscar en Internet

La forma más rápida de descubrir qué puede hacer un generador es preguntándoselo. Esto muestra todos los esquemas disponibles:

ng generate --help

El alias funciona de la misma manera:

ng g --help

Agregar --help después de un esquema específico muestra todas sus opciones con descripciones breves:

ng g component --help

Las opciones cambian entre versiones, y las respuestas en los foros suelen describir flags antiguos; la salida de ayuda siempre coincide con la CLI instalada en su proyecto.

Lea y modifique las configuraciones con ng config

La configuración del espacio de trabajo se encuentra en angular.json, y es tentador editar ese archivo directamente. La CLI ofrece una orden para leer y escribir esos valores:

ng config

Al ejecutarse por sí solo, muestra la configuración para que pueda ver qué está establecido:

ng config

También puede pasar una ruta JSON para leer un valor, o una ruta seguida de un valor para establecerlo, por ejemplo para cambiar una opción de la CLI para todo el espacio de trabajo. En los scripts, una llamada repetible a ng config es mejor que ediciones manuales frágiles de JSON: cuando la CLI gestiona un archivo, utilícela para modificarlo.

Informe sobre su entorno con la versión de ng

Cuando algo falla, las versiones exactas son importantes. En lugar de abrir package.json y intentar armar las piezas, ejecute:

ng version

o su forma abreviada:

ng v

La salida muestra en un mismo bloque la versión de Angular CLI, los paquetes de Angular instalados, Node.js, el gestor de paquetes y el sistema operativo. Esto es exactamente lo que necesita un compañero de equipo o el mantenedor cuando se solicita ayuda. Un informe que solo indica que el proyecto dejó de funcionar no les proporciona ninguna pista, mientras que pegar la salida del siguiente comando responde de antemano a sus primeras cinco preguntas:

ng version

Mida el paquete de producción en lugar de adivinar

Este indicador de compilación merece ser utilizado mucho más de lo que se hace actualmente:

ng build --stats-json

Escribe un archivo de estadísticas que describe qué contenido se incluye en cada bloque de salida. Al pasar ese archivo a un analizador de paquetes, se obtiene un desglose visual del origen de los bytes. Tenga en cuenta que el formato del archivo depende del generador: las compilaciones antiguas basadas en webpack producen estadísticas de webpack, mientras que los generadores más recientes basados en esbuild emiten metadatos de esbuild; por lo tanto, elija un analizador que entienda la salida de su generador y consulte la documentación actual de Angular para su versión.

Los hallazgos típicos cuando una aplicación parece lenta incluyen:

• una biblioteca de terceros de gran tamaño
• bloques que son mucho más grandes de lo esperado
• la misma dependencia incluida varias veces
• algunos componentes pesados que se cargan al inicio
• funcionalidades cargadas de forma diferida que resultaron ser más grandes de lo planeado

Ninguno de estos se puede ver solo desde el código fuente. Comparar las estadísticas antes y después de una actualización de dependencias es una forma sencilla de detectar regresiones.

Limpiar la caché de compilación antes de reinstalar todo

La CLI mantiene una caché en disco persistente para que las compilaciones repetidas sean más rápidas. La orden ng cache la gestiona; ng cache info muestra dónde se encuentra la caché y si está activada:

ng cache

Cuando las compilaciones comienzan a comportarse de forma extraña, limpiar esa caché suele ser la solución:

ng cache clean

Las entradas de caché obsoletas suelen aparecer después de un cambio en las dependencias, una actualización de Angular o al cambiar entre ramas con versiones diferentes de paquetes. Limpiarla toma segundos, así que inténtelo antes de recurrir al método lento de eliminar node_modules e reinstalarlo.

Revisar errores de formato localmente y en CI

Si su proyecto tiene un analizador de errores configurado, ejecútelo con:

ng lint

Las versiones recientes de Angular no incluyen un linter por defecto, por lo que ng lint solo funciona después de agregar uno, generalmente a través de la integración con Angular ESLint. Una vez configurado, detecta problemas antes de que un revisor tenga que:

• variables e importaciones no utilizadas
• Inconsistencias en el formato
• Bug potenciales
• Patrones no recomendados
• Problemas generales de calidad del código

Ejecutar la misma orden en el pipeline de CI significa que el código problemático se marca antes de llegar a la rama principal, y nadie tiene que depender de recordar ejecutarla.

Ejecutar pruebas una vez en la automatización

Localmente, las ejecuciones de pruebas suelen permanecer en modo de vigilancia y se vuelven a ejecutar con cada guardado:

ng test

Un trabajo de CI no tiene utilidad alguna para un proceso que espera cambios en archivos. Desactivar el modo de vigilancia hace que la orden ejecute el conjunto de pruebas una sola vez y se cierre:

ng test --watch=false

El código de salida refleja entonces si las pruebas se superaron, y es esto lo que utiliza la pipeline para marcar el trabajo como verde o rojo. Una pipeline en modo de vigilancia simplemente permanece bloqueada hasta que expira el tiempo asignado. El desarrollo local y las pruebas continuas tienen necesidades diferentes, y una sola línea de comandos no necesita satisfacer ambas.

Dirigirse a un único proyecto en un espacio de trabajo multi-proyecto

Los repositorios más grandes de Angular suelen contener varias aplicaciones y bibliotecas en un mismo espacio de trabajo. La mayoría de los comandos aceptan el nombre de un proyecto, por lo que se puede compilar solo una aplicación:

ng build my-app

o probar solo una:

ng test my-app

En un espacio de trabajo de estilo monorepo, esto se vuelve algo habitual:

ng build admin
ng build customer
ng test shared-ui

Trabajar en la biblioteca de UI compartida no debería significar tener que volver a compilar cada aplicación; delimitar los comandos permite mantener ciclos de retroalimentación cortos.

Llamar a cualquier objetivo de arquitectura con ng run

Detrás de los comandos familiares existe uno más general que pocos desarrolladores utilizan directamente:

ng run

Este ejecuta un objetivo de arquitectura con nombre desde la configuración del espacio de trabajo, utilizando el formato project:target, opcionalmente seguido por un nombre de configuración:

ng run my-app:build

Los comandos estándar son en realidad atajos para objetivos comunes. ng run se vuelve útil cuando un espacio de trabajo define objetivos personalizados, como por ejemplo un generador de código, uno que despliega una versión preliminar o uno que ejecuta un conjunto de pruebas especializado. Piénselo como “ejecutar exactamente este objetivo de este proyecto”, sin ninguna inferencia adicional.

Abre la documentación desde la terminal

Cuando necesitas consultar una API rápidamente, la CLI puede iniciar la búsqueda por ti:

ng doc

Introduce una palabra clave y buscará en la documentación oficial de Angular:

ng doc signals

Tenga en cuenta que los resultados se abren en su navegador en lugar de imprimirse en la terminal, por lo que esto es un acceso directo a la página correcta y no una referencia sin conexión.

Deje que la ayuda reemplace el memorización

Tal vez el hábito más útil de todos sea este comando:

ng help

Enumera cada comando de nivel superior. Para las opciones de un comando específico, agregue --help:

ng build --help

Lo mismo funciona con los generadores, incluso con un único esquema:

ng generate service --help

Nadie necesita memorizar todas las banderas. Los desarrolladores productivos rara vez son aquellos que recuerdan todo; son aquellos que saben dónde buscar en el momento en que lo olvidan.

Un flujo de trabajo diario que lo integra todo

Una rutina práctica podría verse de la siguiente manera. Inicie el servidor de desarrollo:

ng serve

Al desarrollar funcionalidades, genere lo que necesite con las banderas adecuadas:

ng g c profile --skip-tests

Antes de hacer el commit, ejecute lint y las pruebas una vez:

ng lint
ng test --watch=false

Para una compilación de producción, utilice explícitamente la configuración de producción:

ng build --configuration production

Cuando el tamaño del paquete sea un problema, genere estadísticas:

ng build --stats-json

Cuando la compilación comience a comportarse de forma incorrecta, borre primero la caché:

ng cache clean

Y cada vez que se le olvide alguna opción, pregúntele al propio comando:

ng <command> --help

Conclusión

Angular CLI es una capa de productividad que rodea todo el ciclo de desarrollo, y los mayores beneficios provienen de unas pocas opciones que eliminan el trabajo repetitivo:

• generar código con banderas en lugar de escribir código genérico a mano
• limitar los comandos a un proyecto en entornos de trabajo multi-proyecto

Mida los paquetes con estadísticas en lugar de adivinar sobre el rendimiento

Limpie la caché antes de recurrir a una reinstalación completa

Ejecute pruebas sin el modo de observación en CI y realice análisis de formato con cada cambio

Confíe en --help, que siempre coincide con su versión instalada

La próxima vez que abra una terminal en un proyecto Angular, recuerde que hay mucho más detrás de ng que esto:

ng serve

Lecturas relacionadas

• Angular más rápido haciendo menos: diez técnicas más allá de OnPush y trackBy — Reduzca el uso innecesario de la red, así como el trabajo en Reactivo, DOM y CPU en Angular moderno mediante @defer, hidratación incremental, resource(), señales calculadas, fases de renderizado y Web Workers.
• Migrar una app Angular del Webpack Builder a @angular/build — Una guía paso a paso para reemplazar el compilador de navegador Webpack de Angular por el compilador de aplicaciones basado en esbuild, corrigiendo las rutas de salida, el SSR, los cargadores y los tipos de tsconfig.
• Generadores de sitios estáticos desde cero: vocabulario, historia y primer compilación — Aprenda los términos que los documentos de SSG suponen que ya conoce, cómo se combinan los diseños, las partes parciales y el front matter, de dónde provienen los generadores y cómo elegir uno sin complicaciones.