Angular 22, lanzado el 3 de junio de 2026, es la última versión estable de marco en el momento de escribir este artículo. En comparación con Angular 21 (noviembre de 2025, que había hecho sin zona el valor predeterminado e introducido Signal Forms como una API experimental), esta versión consolida en una versión estable y lista para producción todo lo que aún estaba en la vista previa del desarrollador: Signal Forms, Resource API y Angular Aria se vuelven oficialmente utilizables en producción, los valores predeterminados de algunos Las API cambian hacia patrones más modernos y llega una primera capa de herramientas de IA integradas en la CLI.
Como siempre con una versión reciente, verifique la versión exacta instalada y las notas de la versión.
oficial antes de planificar una actualización en producción: ng versión y npm view
Las versiones @angular/core devuelven el estado real de su proyecto y el registro npm,
más confiable que cualquier resumen estático.
Resumen rápido
- Stable Signal Forms: El sistema de formularios basado en Signal, experimental en v21, ya está listo para producción.
- Resource API estable:
resource(),rxResource()yhttpResource()pasan de experimental a estable. - Angular Aria estable: paquete
@angular/ariapara que el patrón de accesibilidad pase de la vista previa del desarrollador a la disponibilidad general. - OnPush por defecto: los nuevos componentes usan
OnPushen lugar deEagerpara la detección de cambios. - Fetch API como predeterminado para HttpClient: reemplaza
- Herramientas de IA en CLI: Angular Skills y compatibilidad experimental con WebMCP para agentes de codificación.
- Se requiere TypeScript 6: requisito mínimo aumentado, el nodo 20 ya no es compatible (mínimo del nodo 22).
Característica detallada
Formas de señales: de experimental a estable
Signal Forms combina la tipificación fuerte de las formas reactivas tradicionales con una capacidad de respuesta granular
de Signal, eliminando gran parte del texto estándar de FormGroup/FormControl.
En esta versión llegan los validadores minDate()/maxDate(), rebote nativo
en eventos de desenfoque y un método getError() para recuperar errores específicos sin
recorrer todo el árbol del formulario.
// Signal Forms — validazione con debounce sul blur, stabile da v22
const form = signalForm({
email: field('', { validators: [required(), email()] }),
});
debounce(form.email, 'blur', 300);
API de recursos: obtención de datos reactiva
// httpResource() — fetching dichiarativo, nessun switchMap manuale
userResource = httpResource(() => `/api/users/${this.userId()}`);
// userResource.value(), userResource.isLoading(), userResource.error() sono Signal reattivi
Nuevo en esta versión: un método chain() para componer recursos mutuamente dependientes
por el otro, sin anidar manualmente effect(), y soporte de caché lateral SSR a través de
una opción id, útil para evitar la doble búsqueda entre el servidor de renderizado y el cliente de hidratación.
OnPush de forma predeterminada y Fetch API de forma predeterminada
// Da Angular 22, un componente senza changeDetection esplicito è OnPush per default
@Component({ selector: 'app-widget', template: `...` })
export class WidgetComponent {} // equivalente a changeDetection: ChangeDetectionStrategy.OnPush
HttpClient usa Fetch API en lugar de XMLHttpRequest sin necesidad
withFetch() explícito (ahora obsoleto para su eliminación); ten cuidado si tu
El código depende de reportProgress para la carga, porque los informes de progreso en
La carga no es compatible con la implementación Fetch y debe manejarse con las nuevas.
reportUploadProgress/reportDownloadProgress.
@Service Decorador e injectAsync()
// @Service — scorciatoia per @Injectable({ providedIn: 'root' }), richiede inject() non constructor DI
@Service()
export class NotificationService {
private readonly http = inject(HttpClient);
}
// injectAsync() — lazy loading di un servizio via dynamic import, con prefetch opzionale
const analytics = await injectAsync(() => import('./analytics.service'), { prefetch: 'onIdle' });
Angular Aria: Accesibilidad como infraestructura
@angular/aria, ahora en disponibilidad general, proporciona directivas que manejan
automáticamente atributos ARIA, navegación por teclado y gestión de enfoque para patrones compuestos
(cuadro combinado, pestaña, árbol): el desarrollador se centra en el diseño visual y la lógica empresarial, no
sobre la reimplementación manual de la Guía de prácticas de creación de ARIA para cada componente.
Cambios importantes y obsolescencias
- Se requiere TypeScript 6: 5.9 y versiones anteriores ya no son compatibles: actualice TypeScript antes de ejecutar
ng update. - Nodo 20 eliminado: El mínimo admitido es el Nodo 22 (se admite el Nodo 26).
toucheden Signal Forms cambió: del modelo al par de entrada/salida (touchedentrada,touch()salida): impacto directo en el código que leído/escritotocadocomo modelo.markAsTouched()ahora marca descendientes de forma predeterminada: use{ skipDescendants: true }para preservar el comportamiento anterior si su código lo asumió.- Router:
canMatchrequiere un tercer parámetro obligatorio (currentSnapshot) — las protecciones existentes deben actualizarse en la firma. paramsInheritanceStrategyahora'always'por defecto (era'emptyOnly'): compruebe si su enrutamiento dependía sobre el antiguo comportamiento implícito.- El encadenamiento opcional en plantillas cambia la semántica:
project?.authorahora devuelveundefinidoen lugar denullen valores nulos, alineando con TypeScript. withIncrementalHydration()está en desuso porque ahora es el SSR predeterminado; usewithNoIncrementalHydration()si necesita explícitamente el comportamiento anterior.
Herramientas y construcción
# Migrazione automatica dei test da Karma a Vitest
ng generate migrate-karma-to-vitest
# Build con ottimizzazione dei chunk abilitata di default (disattivabile via env var)
NG_BUILD_OPTIMIZE_CHUNKS=false ng build --configuration production
Rollup sigue siendo el optimizador predeterminado, pero Rolldown está disponible como opción a través de
NG_BUILD_CHUNKS_ROLLDOWN para aquellos que quieran experimentar tiempos de construcción aún más reducidos.
La variable de entorno PORT ahora tiene prioridad sobre la bandera --port para el desarrollador
servidor, útil para configuraciones de CI/CD en contenedores.
Rendimiento y paquete
OnPush de forma predeterminada reduce el número de ciclos de detección de cambios innecesarios que ya existen.
comience desde nuevos proyectos estructurados, sin necesidad de configuración manual. La optimización de
El fragmento habilitado de forma predeterminada en la compilación de producción reduce aún más el paquete inicial en comparación.
a versiones anteriores. Mida siempre antes/después con instrumentos estándar:
ng build --configuration production --stats-json
npx webpack-bundle-analyzer dist/*/stats.json
npx lighthouse http://localhost:4200 --view
Gestión y Reactividad del Estado
Con Signal Forms y Resource API estables, el patrón recomendado para el nuevo código ahora es
Señal primero: estado local con signal()/computed(), obtención de datos con
resource()/httpResource(), formulario con formularios de señal. RxJS permanece completamente
compatible y necesario para transmisiones complejas (WebSockets, múltiples eventos combinados), pero ya no es el
valor predeterminado implícito para cada nuevo componente. Novedad experimental en esta versión: debounced(),
una función que crea una versión antirrebote de una señal que devuelve un objeto Resource.
// debounced() — sperimentale, debounce di un Signal senza RxJS
const query = signal('');
const debouncedQuery = debounced(query, { delay: 300 });
Renderizado y borde del lado del servidor
La hidratación incremental ahora es el comportamiento SSR predeterminado (ya no se puede optar a través de
withIncrementalHydration(), que de hecho está en desuso precisamente porque es superfluo).
provideServerRendering() ahora acepta un objeto de opciones, incluido
maxResponseBodySize para limitar el tamaño de la respuesta representada del lado del servidor:
útil en plataformas de borde con límites estrictos de carga útil por función única.
// provideServerRendering con opzioni — utile su piattaforme edge con limiti di response size
provideServerRendering({ maxResponseBodySize: 5_000_000 });
Compatibilidad y dependencias
| Angular | TypeScript | Nodo | Nota |
|---|---|---|---|
| 21 | 5.6+ | 20 / 22 | Predeterminado sin zona, formularios de señal experimentales |
| 22 | 6.0 mínimo | 22/26 (20 eliminados) | Signal Forms/Resource API/Aria estable |
Para Angular Material, NgRx y otras bibliotecas de ecosistemas, verifique siempre la compatibilidad
declarado en peerDependencies del paquete específico antes de actualizar:
npm ver @angular/material peerDependencies. Bibliotecas que dependen en gran medida de
Los tradicionales FormControl/FormGroup siguen siendo compatibles — Signal Forms
coexiste con API heredadas reactivas/basadas en plantillas, no las reemplaza por la fuerza.
Plan Operativo y de Migración
# Verifica prima di aggiornare
ng version
npm outdated
# Aggiornamento a v22 con dry-run preventivo
ng update @angular/core@22 @angular/cli@22 --dry-run
ng update @angular/core@22 @angular/cli@22
Lista de verificación mínima previa a la actualización: TypeScript ya en 6.x, Node ya en 22+, rama dedicada, compilación y prueba verde como línea base. Después de la actualización, ejecute todo el conjunto de pruebas y una versión de producción completa. antes de proceder con cualquier adopción opcional (Signal Forms, Aria) en componentes existentes: el Las actualizaciones de versiones y la adopción de nuevas API son dos actividades distintas y no deben combinarse en una sola. mismo compromiso. Para la reversión, la etiqueta Git previa a la actualización sigue siendo el mecanismo más rápido y confiable.
Pruebas y control de calidad
// TestBed.getLastFixture() — nuova utility per recuperare l'ultima fixture creata
it('renderizza correttamente', () => {
TestBed.createComponent(WidgetComponent);
const fixture = TestBed.getLastFixture();
expect(fixture.nativeElement.textContent).toBeTruthy();
});
Vitest ahora tiene soporte nativo para Zone.js a través de zone.js/plugins/vitest-patch, y el
migración automática migrate-karma-to-vitest cubre la mayoría de los proyectos de Karma
existente; para aquellos que ya han migrado a Jasmine/Vitest, la bandera --fake-async en migración
refactor-jasmine-vitest cubre patrones de prueba asincrónicos basados en temporizador.
Seguridad y mejores prácticas
No hay cambios predeterminados relacionados con las cookies o CSP en esta versión específica, pero el cambio a Fetch
Vale la pena comprobar la API para HttpClient: si su aplicación depende de comportamientos
específico para XMLHttpRequest (por ejemplo, encabezados personalizados en solicitudes de origen cruzado), pruebe explícitamente i
flujos de autenticación después de la actualización. Las mejores prácticas restantes (HttpOnly/SameSite en cookies
sesión, CSP restrictivo) no cambian y deben mantenerse independientemente de la versión de Angular.
Casos de uso
Caso 1: Panel empresarial con formularios complejos
Un panel empresarial con más de 40 formularios distribuidos en varios módulos ha adoptado la suite Signal Forms. Nuevos formularios con funciones después de actualizar a v22, manteniendo los formularios heredados en formularios reactivos tradicionales. gracias a la plena coexistencia de las dos API. Resultado: el modelo estándar se redujo en aproximadamente un 30 % en el caso de los nuevos. formulario, validación con rebote nativo que eliminó el código de rebote escrito a mano personalizado en RxJS anteriormente.
Caso 2: Aplicación con estrictos requisitos de accesibilidad
Una aplicación pública sujeta a los requisitos WCAG AA ha reemplazado la implementación personalizada de
cuadro combinado y pestaña (con administración ARIA escrita manualmente) con @angular/aria después del
estabilización en v22. Resultado: La auditoría de accesibilidad automática se aprobó sin intervención manual
Además de los patrones migrados, reducción del código de gestión de teclado/enfoque específico para
componente de aproximadamente 200 líneas en total.
Preguntas frecuentes
¿Necesita migrar inmediatamente todos los formularios a Signal Forms?
No, Signal Forms coexiste con formularios heredados reactivos/basados en plantillas; la migración puede ser gradual y oportunista.
¿OnPush, por defecto, rompe los componentes existentes?
No, el valor predeterminado solo se aplica a componentes nuevos sin changeDetection explícito; Los componentes existentes mantienen la estrategia ya declarada.
¿Debo actualizar Node antes de actualizar Angular?
Sí, el Nodo 20 ya no es compatible con v22; verifique y actualice Node a 22+ antes de ejecutar ng update.
¿Fetch API interrumpe de forma predeterminada las llamadas HTTP existentes?
En la mayoría de los casos no, pero verifique el informe de progreso de carga, que requiere las nuevas opciones dedicadas en lugar de las antiguas reportProgress.
Angular Aria reemplaza Angular Material?
No, son complementarios: Aria proporciona patrones de accesibilidad de comportamiento, Material proporciona componentes visuales ya estilizados.
¿Qué sucede si no actualizo TypeScript a 6?
ng actualización a v22 fallará o informará incompatibilidad: TypeScript 6 es un requisito obligatorio, no opcional.
¿Vitest necesariamente reemplaza al Karma?
No es necesario de inmediato, pero Karma está en desuso en el ecosistema Angular; La migración automática hace que el cambio a Vitest sea de bajo riesgo.
¿Son necesarias las herramientas AI/MCP para usar Angular 22?
No, es opcional y está diseñado para quienes utilizan agentes de codificación asistidos por IA; no afecta el funcionamiento estándar de la aplicación.
Cómo comprobar
- Compruebe la versión y las dependencias:
ng versiónynpm desactualizado. - Compilación de producción completa:
ng compilación --producción de configuración. - Ejecute todo el conjunto de pruebas:
ng test(ovitest runsi ya está migrado). - Prueba de humo manual en flujos críticos (autenticación, formularios principales) después de la actualización.
- Prueba E2E completa:
npx cypress runo equivalente. - Compruebe el tamaño y el rendimiento del paquete: analizador de paquetes más
npx lighthouse http://localhost:4200, en comparación con la línea base previa a la actualización.
Conclusión
Angular 22 no introduce tanto un cambio de paradigma como una consolidación: nacen las API basadas en señales en versiones anteriores (Signal Forms, Resource API) finalmente se vuelven estables y listos para producción, los valores predeterminados avanzan hacia patrones de mayor rendimiento (OnPush, Fetch API) y llega el primero Capa de herramientas diseñada para el desarrollo asistido por IA. Para la mayoría de los proyectos, actualizar desde v21 es de bajo riesgo si TypeScript y Node ya están actualizados; la adopción de otros nuevos Sin embargo, la API sigue siendo opcional y puede continuar gradualmente después de la actualización de la versión.
¿Quiere una lista de verificación de migración detallada para su proyecto o una evaluación? del esfuerzo de actualización? Solicitar una auditoría técnica: en unas pocas horas de análisis es posible Estime los riesgos, los cambios importantes relevantes para su base de código y las prioridades de adopción de nuevas API.