Cómo actualizar una app Angular con muchas versiones de atraso

Una app en Angular 9, 12 o 15 no llega a la versión actual con un solo comando. Este es el orden de trabajo que la mantiene publicable en cada paso.

¿Una versión mayor a la vez, o un solo salto?

La política oficial de actualización es explícita: ng update soporta pasar de una versión mayor a la siguiente, y una actualización de varias versiones mayores se hace una a la vez.

La razón son las migraciones. Cada versión mayor trae transformaciones de código que solo corren en ese paso. Ejemplos: los formularios tipados en la v14, standalone: false en la v19, provideZoneChangeDetection() en la v21 y ChangeDetectionStrategy.Eager en la v22. Si te saltas una versión, te saltas sus migraciones y corriges a mano lo que la herramienta habría reescrito.

La alternativa es crear un workspace nuevo en la versión actual y mover el código adentro. Eso implica corregir a mano todos los cambios incompatibles de una sola vez. Puede funcionar en una app pequeña. Para una más grande, compara las opciones en Reescribir, híbrido o microfrontends.

Bloqueos por dependencias

Estos rangos salen de la tabla oficial de compatibilidad de versiones.

• Node.js y TypeScript. Las máquinas locales, el CI y los servidores de build avanzan con el framework, y cada actualización del compilador puede traer errores de tipos nuevos.
• RxJS. Angular 9 a 12.1 requieren RxJS 6. Desde la v13 el rango aceptado es ^6.5.3 || ^7.4.0, igual que en la v22. El paso a RxJS 7 puede ir aparte.
• Angular Material. Actualízalo con la misma versión mayor. Planifica una revisión visual en la v15, con el paso a MDC, y en la v17, cuando los componentes legacy salieron del paquete.
• NgRx. Cada versión mayor de NgRx requiere la misma versión mayor de Angular y trae sus migraciones de ng update, así que avanza en el mismo salto.
• Librerías de View Engine. Funcionaron con ngcc hasta la v15. Angular 16 eliminó ngcc. Encuentra esas librerías temprano y reemplázalas.
• Herramientas y navegadores. TSLint quedó deprecado en la v11. El soporte para IE11 termina con la v12. El builder de Protractor se eliminó en la v19. Los builders de webpack quedan deprecados en la v22.

Primero, la red de seguridad de pruebas

• Escribe pruebas end-to-end para los flujos críticos antes del primer salto, en una herramienta que no dependa de la versión de Angular.
• Mantén las pruebas unitarias en verde en cada salto. La v13 (teardown de TestBed) y las v18 a v21 (detección de cambios y manejo de errores) piden correcciones en las pruebas.
• Corre build, lint y pruebas en CI en cada salto, así una falla apunta a una sola versión mayor.

El orden de trabajo

1. Inventaría la versión de Angular, Node.js, TypeScript, cada librería y el rango de Angular que soporta.
2. Borra el código muerto y las dependencias sin usar.
3. Arma la red de seguridad.
4. Para cada versión mayor: último parche, ng update para core y CLI, luego Material, NgRx y las demás librerías. Corrige, prueba y haz commit.
5. Publica en puntos de control donde la app está estable. Una publicación por cada versión mayor es opcional.
6. Deja las migraciones opcionales (standalone, control flow, signals, application builder) para cuando la app esté en una versión con soporte.

Por áreas, con microfrontends

Con microfrontends, un host compone aplicaciones que se construyen y despliegan por separado, así que se puede actualizar por áreas: un equipo actualiza y publica su área mientras los demás siguen trabajando.

Hay una condición. Si los microfrontends comparten una sola instancia de Angular en runtime, tienen que coincidir en la versión y la actualización deja de ser independiente. Para actualizar de forma independiente, cada microfrontend lleva su propia copia del framework, lo que cuesta tamaño de bundle, y las librerías compartidas, como el design system, deben soportar todas las versiones de Angular en uso. Esto rinde cuando varios equipos son dueños de áreas separadas. Para un solo equipo agrega costo.

Cuándo conviene pedir ayuda

Conviene pedir ayuda cuando la app tiene varias versiones mayores de atraso, poca cobertura de pruebas, librerías clave sin camino de actualización, o un equipo que no puede detener el desarrollo de funcionalidades. Si todavía hay código AngularJS en el producto, esa parte sigue otro camino: mira Migración de AngularJS. Las fechas de soporte están en Soporte y fin de vida de las versiones de Angular.

Más en esta sección

• Soporte y fin de vida de las versiones de Angular
• Angular 9: fin de soporte y cómo actualizar
• Angular 10: fin de soporte y cómo actualizar
• Angular 11: fin de soporte y cómo actualizar