Angular ha llevado a beta Angular Preprocessor (ngp), una nueva pieza de su cadena de compilación escrita en Rust. Su objetivo es desacoplar el análisis de Angular de las interfaces internas de TypeScript y facilitar la adaptación a TypeScript 7, cuya reescritura en Go eliminó una API que el compilador actual de Angular utiliza.
El cambio no sustituye de golpe al compilador existente ni implica que los proyectos deban migrar ya. La propuesta divide el trabajo en etapas: ngp analiza los archivos y encuentra las declaraciones de Angular; después, el compilador de plantillas de TypeScript genera los artefactos necesarios; por último, otra herramienta se encarga de la comprobación de tipos y de emitir JavaScript. La beta permite evaluar esa arquitectura, pero la información publicada sitúa la producción todavía en el compilador actual, ngc.
La incompatibilidad que motiva el cambio
El compilador de Angular, ngc, se apoya en el compilador de TypeScript, tsc. Entre otras tareas, emplea la API ts.Transformer para convertir elementos como los decoradores @Component y @Pipe en instrucciones que el código pueda ejecutar. Según la noticia de InfoQ sobre la beta de ngp, TypeScript 7.0, reescrito en Go, eliminó esa API y no ofrece un equivalente que permita a Angular mantener el mismo mecanismo.
Una opción sería comunicar JavaScript y Go para cada archivo, pero el equipo de Angular considera que ese cruce repetido entre lenguajes resultaría demasiado costoso. ngp aborda el problema separando el análisis propio de Angular de las API de TypeScript. Así, la lógica necesaria para descubrir componentes y resolver sus metadatos deja de depender de que TypeScript exponga la interfaz concreta que utilizaba ngc.
Tres etapas para compilar una aplicación Angular
La primera etapa de ngp es un frontend escrito en Rust que utiliza Oxc, una cadena de herramientas de Rust para JavaScript y TypeScript que también impulsa Vite. Analiza los archivos en paralelo para localizar declaraciones de Angular y resolver sus metadatos. El paralelismo forma parte de esta fase de análisis; no significa que todo el proceso de compilación pase a estar implementado en Rust.
En la segunda etapa sigue interviniendo el compilador de plantillas existente de TypeScript. Este genera dos artefactos: un archivo de ejecución con el componente transformado y otro llamado .ngtypecheck.ts. Este último contiene el Type Check Block (TCB), una representación que permite comprobar los tipos de las plantillas.
La tercera etapa queda en manos de una herramienta posterior. La fuente menciona tsgo, tsrs, esbuild y Rolldown como opciones para realizar la comprobación de tipos y emitir JavaScript de forma independiente. La separación permite que el análisis de Angular y esas tareas posteriores no tengan que resolverse mediante una única herramienta. También deja claro que ngp no equivale por sí solo a un compilador completo que reemplace cada componente de la cadena.
Qué indican las pruebas de rendimiento publicadas
La noticia recoge una evaluación de la beta realizada por Cédric Exbrayat, de Ninja Squad, en tres proyectos con tamaños de entre 15 y 1.714 componentes. En esas pruebas, las compilaciones en frío fueron entre dos y tres veces más rápidas que con la referencia comparada, y el consumo de memoria del proyecto mayor bajó de 2,8 GB a 1,4 GB. Son resultados atribuidos a esos proyectos y a esa evaluación; no garantizan el mismo efecto en cualquier aplicación Angular.
La combinación de ngp con tsrs y Rolldown fue la más rápida en las mediciones citadas. tsgo con esbuild quedó algo por detrás, aunque la diferencia se describió como pequeña. Esto ilustra que el rendimiento final no depende solo del preprocesador: también intervienen las herramientas elegidas para las fases posteriores.
InfoQ también describe un prototipo distinto, vite-plugin-ngp, desarrollado por Christopher Holder para compilar archivos Angular bajo demanda. En Super Productivity, un proyecto con 252 componentes, el servidor de desarrollo llegó a la primera página en 10,5 segundos, frente a 17,4 con ng serve; las modificaciones de plantillas se aplicaron en 112 milisegundos, en vez de requerir una recarga completa de 2,6 segundos. En una aplicación generada de 5.000 componentes, la comparación fue de 1,6 frente a 28,4 segundos. El propio Holder advirtió que el plugin era un prototipo construido sobre otro prototipo y estaba fijado a la versión 22.3.0-next.2, por lo que esas cifras no describen una configuración general disponible para producción.
La beta no implica una migración inmediata
La ruta prevista, según la noticia, es incorporar ngp en una versión menor de Angular 22 cuando TypeScript 7.1 restaure la API del compilador. Hasta entonces, se recomienda mantener ngc para las compilaciones de producción. Los equipos que utilicen versiones anteriores de Angular deberían seguir la guía estándar de actualización para llegar a la versión 20 o posterior antes de plantearse este paso.
La apuesta de Angular es, por tanto, más amplia que acelerar una fase concreta: busca reducir la dependencia entre su compilador y las interfaces de TypeScript, a la vez que separa análisis, comprobación de tipos y emisión de código. Para quienes mantienen aplicaciones Angular, la beta aporta señales de rendimiento y una arquitectura que podrán valorar, pero no cambia por sí sola el flujo de producción actual.
