El log de CI marcaba 77.8s para la comprobación de tipos, y ya nadie en el equipo levantaba la vista. Esa cifra corresponde al millón y medio de líneas de VS Code con el antiguo compilador en JavaScript, y con TypeScript 7.0, el port nativo que Microsoft empezó en marzo de 2025 como Project Corsa, el mismo trabajo termina en 7.5s. He leído una docena de opiniones apresuradas sobre por qué el equipo eligió Go en lugar de Rust. Esta es mi postura, y va un poco a contracorriente: el debate sobre el lenguaje es lo menos interesante de esta versión, y lo que los desarrolladores de PHP deberían estudiar es la letra pequeña sobre lo que no se publicó.

Primero, el reconocimiento, porque se lo han ganado. El razonamiento detrás de Go fue refrescantemente poco glamuroso. El equipo quería un port que se comportara exactamente igual que el compilador anterior, rarezas incluidas, así que tradujo el código existente archivo por archivo en vez de rediseñarlo. Un compilador es una maraña de nodos que guardan punteros a sus padres, sus hijos y sus declaraciones, y un lenguaje con recolector de basura y punteros simples permite que ese grafo sobreviva a la mudanza intacto. Súmale paralelismo con memoria compartida para el parseo y la comprobación, algo que un único hilo de Node nunca ofreció, y obtienes el rango de 8x a 12x que se reporta en proyectos grandes. TypeORM vio 13.5x. date-fns, con 104K líneas, consiguió 9.5x. Son horas reales devueltas a personas reales.

Ahora, la letra pequeña. TypeScript 7.0 no tiene una API programática estable; está prevista para la 7.1. Hasta entonces, todo lo que habla directamente con el compilador se queda en TypeScript 6, y en esa lista están typescript-eslint y las herramientas de plantillas de Vue, Svelte, Astro, MDX y Angular. Además, las deprecaciones pasaron a ser errores duros y el modo estricto viene activado por defecto. Así que una buena parte del ecosistema ve la mejora de velocidad desde el otro lado del cristal.

Aquí es donde empiezo a pensar en nuestra propia casa. El análisis estático de PHP está escrito en PHP, y su valor nunca ha sido solo el motor central. Está en la capa de extensiones: los plugins que conocen el framework y le enseñan al analizador qué devuelve una facade, qué hidrata un método de repositorio, qué propiedad mágica existe de verdad. La mitad de los equipos de PHP que conozco no usarían análisis estático en absoluto sin esos plugins, porque los hallazgos en bruto sobre un código basado en un framework son casi todo ruido. Cada vez que alguien propone reescribir nuestros analizadores en nativo, y siempre hay alguien, la diapositiva del benchmark se lleva los aplausos, pero lo que decide si alguien puede cambiarse de verdad es la API de plugins.

El contraargumento más sólido merece que lo escuchemos con justicia. La velocidad cambia los hábitos. Cuando un análisis completo tarda noventa segundos, la gente lo ejecuta en CI y en ningún otro sitio; cuando tarda nueve, lo ejecuta al guardar, y los bugs que detecta pasan del pull request al editor, lo cual vale más que cualquier plugin. Se puede defender que Microsoft acertó al publicar primero el núcleo rápido y dejar que las integraciones se pusieran al día, porque esperar a tenerlo todo habría retrasado la mejora para la mayoría, que simplemente ejecuta tsc. Creo que es lo correcto para TypeScript, con la plantilla de Microsoft y una 7.1 ya en el calendario. Estoy mucho menos seguro de que funcione en un ecosistema como el nuestro, donde los analizadores los mantiene un puñado de personas y los plugins una multitud dispersa de voluntarios que no pueden absorber una API rota al ritmo que marque otro.

Así que si tuviera que aconsejar a alguien que mantiene una herramienta de PHP y siente la tentación de ir a lo nativo, le daría la vuelta al orden de TypeScript. Primero define y congela el contrato de extensiones, en la implementación actual, y solo después cambia el motor que hay debajo. El enfoque de port fiel que usó el equipo de TypeScript de hecho lo facilita: si el código nuevo refleja la estructura del antiguo línea por línea, la frontera que tocan los plugins también puede reflejarla. Y no olvides cuánto nos ha dado ya PHP gratis. Muchas de las mejoras que antes exigían salir del lenguaje ahora llegan de un motor cada vez más rápido y de repartir el trabajo en procesos paralelos, algo que nuestros analizadores ya hacen.

Nada de esto hace que los números me impresionen menos. Ver cómo una comprobación de un minuto se reduce a lo que tardas en cambiar de pestaña es emocionante, y confieso que cronometré un proyecto de TypeScript en el trabajo por pura curiosidad. Pero una herramienta solo es tan rápida como la pieza más lenta de tu flujo de trabajo real, y si tu paso de lint está anclado a la versión 6, el reloj de tu CI apenas se ha movido.

Así que esto es lo que me encantaría que me contaras, sobre todo si mantienes plugins de analizadores o dependes mucho de ellos: si una reescritura nativa de tu analizador estático de PHP prometiera diez veces más velocidad pero dejara rotas tus extensiones del framework durante seis meses, ¿te cambiarías el primer día o esperarías a la API?