Después de la migración: mantener el frontend al día

Se borró el último archivo AngularJS. El código es moderno hoy y volverá a ser legacy en unos años, salvo que alguien lo mantenga al día. Esta guía cubre la rutina que evita una segunda migración.

Termina bien la migración

Antes de pasar a otra cosa, cierra lo que la migración dejó abierto:

• Elimina la capa de upgrade, el router legacy y todos los paquetes de AngularJS del archivo de dependencias.
• Borra los flags de migración que queden y los caminos de código detrás de ellos.
• Cancela cualquier suscripción de soporte extendido.
• Informa a tu auditor o a tu equipo de seguridad que el framework sin soporte ya no está, con la evidencia.

Cómo funcionan las versiones de Angular

Angular sigue un calendario publicado. Hasta la versión 21 llegaba una versión mayor nueva cada seis meses aproximadamente; desde la versión 22 el calendario pasó a una versión mayor por año. Cada versión mayor tiene soporte por un período limitado: una fase activa seguida de una fase de soporte de largo plazo, que solo recibe correcciones críticas y parches de seguridad. Después, la versión queda sin soporte.

La consecuencia práctica: una aplicación Angular que nunca se actualiza se convierte en software sin soporte en un par de años. Es la misma situación de la que acabas de salir, alcanzada más lentamente. Revisa las fechas de soporte vigentes en el sitio oficial de Angular y ponlas en tu calendario de planificación.

Define una cadencia de actualización

Actualizar una versión mayor es una tarea pequeña y rutinaria. El framework trae migraciones automáticas mediante ng update, que reescriben buena parte del código afectado. Saltarse varias versiones lo convierte en un proyecto, porque los pasos automáticos están pensados para ejecutarse de una versión mayor a la vez.

Elige una regla y déjala por escrito:

Elijas la que elijas, dale un nombre, un responsable y tiempo en el plan. "Actualizaremos cuando haya tiempo" es la forma en que se creó el legacy anterior.

Haz que actualizar sea barato

• Conserva las pruebas end-to-end escritas durante la migración. Son la red de seguridad de cada actualización.
• Corrige las advertencias de deprecación a medida que aparecen. Angular anuncia con anticipación lo que va a eliminar. Una advertencia ignorada hoy es un cambio incompatible más adelante.
• Usa solo APIs públicas. El código que se mete en los internos del framework se rompe con las actualizaciones.
• Adopta las novedades del framework de forma gradual. Con casi todas las versiones llegan sintaxis y patrones nuevos. Úsalos primero en el código nuevo, y convierte el código antiguo donde las migraciones oficiales lo hagan por ti. Evita detener las funcionalidades para reescribir todo por cada novedad.
• Automatiza la actualización de dependencias. Un bot que abre pull requests con las versiones nuevas mantiene la brecha pequeña y visible.

Mantén corta la lista de dependencias

Las librerías de terceros causaron buena parte del dolor en la migración de AngularJS. Lo van a hacer otra vez si la lista crece sin control.

• Antes de agregar una librería, revisa quién la mantiene, cada cuánto publica versiones y si sigue las versiones mayores de Angular.
• Prefiere las capacidades del propio framework y de la plataforma antes que los paquetes utilitarios pequeños.
• Envuelve cada componente de UI de terceros en un componente tuyo. Las pantallas dependen de tu wrapper, y reemplazar la librería más adelante cambia un solo archivo.
• Revisa la lista de dependencias dos veces al año. Quita lo que no se usa y marca lo que parece abandonado.

El índice de migración de librerías muestra cuántas librerías de AngularJS que fueron populares terminaron sin mantenedores. A algunas de las librerías de hoy les va a pasar lo mismo.

Asigna un responsable

El legacy se forma cuando nadie responde por la plataforma. Nombra a un responsable de la base del frontend: la versión del framework, el build, los componentes compartidos y el calendario de actualizaciones. En una empresa pequeña es un desarrollador senior con tiempo reservado. En una más grande es un equipo de plataforma o un guild con un mandato claro.

Señales de que se está formando el próximo legacy

Cuando aparezcan dos o tres de estas señales, actúa mientras la solución todavía es una tarea pequeña.

Qué cambia para el negocio

Mantenerse al día es un costo recurrente pequeño que reemplaza a uno grande y ocasional. Debe aparecer en el presupuesto como mantenimiento, igual que la infraestructura. Si armaste un caso de negocio para la migración, agrégale una línea: el esfuerzo anual que evita que el resultado se deteriore.

Para equipos que siguen en versiones antiguas de Angular, la referencia de AngularJS a Angular muestra los equivalentes actuales de los patrones antiguos.

Más en esta sección

• Costo de una migración de AngularJS: qué lo determina y cómo estimarlo
• ¿Cuánto tarda una migración de AngularJS?
• Riesgo de seguridad y cumplimiento de AngularJS
• Soporte extendido de AngularJS: un puente y sus límites