Entrevista técnica: ¿Cómo migrar de forma segura al compilador nativo de TypeScript 7?

Consigna y contexto

Su equipo mantiene aplicaciones web y paquetes compartidos en un monorepo de TypeScript 6. La verificación de tipos en CI es demasiado lenta y el repositorio utiliza typescript-eslint, un cargador de webpack y herramientas de plantillas para Vue y Angular. Debe evaluar el compilador nativo de TypeScript 7.

Diseñe un plan de migración que mantenga una capa de compatibilidad con TypeScript 6, programe las actualizaciones de la CLI y del editor, controle el riesgo de memoria derivado de la verificación en paralelo y defina compuertas de canary, métricas y reversión.

Qué evalúa el entrevistador

• Si distingue entre dependencias de la CLI tsc, los servicios de lenguaje del editor y la API programática de TypeScript.
• Si las versiones fijadas (pinned), dos compiladores y artefactos comparables pueden reducir el riesgo de la migración.
• Si el paralelismo, la memoria, las diferencias de diagnóstico y la compatibilidad del ecosistema se convierten en compuertas de lanzamiento ejecutables.
• Si puede delimitar la frontera que se crea dado que TypeScript 7 aún no cuenta con una API programática estable.

Preguntas para clarificar

1. ¿CI utiliza tsc --build, un proyecto aislado o una API de compilador personalizada?
2. ¿Qué herramientas importan typescript directamente y cuáles solo leen declaraciones o salidas de la CLI?
3. ¿Está habilitado stableTypeOrdering en TypeScript 6, con líneas base para declaraciones, diagnósticos y tiempo de compilación?
4. ¿Están fijadas las versiones del editor, el límite de memoria de Node y la CPU/memoria del ejecutor de CI?

Respuesta en 30 segundos

Haría un inventario de cada consumidor de la API de TypeScript y luego instalaría la CLI de TypeScript 7 junto con el paquete de compatibilidad de TypeScript 6 con versiones fijadas y un archivo de bloqueo (lockfile). En CI compararía declaraciones, diagnósticos, JavaScript generado, mapas de fuentes (source maps), pruebas y uso de recursos; primero habilitaría stableTypeOrdering en el lado de TypeScript 6. Incrementaría --checkers y --builders de TypeScript 7 únicamente a partir de una línea base, manteniendo --singleThreaded como interruptor de diagnóstico. Las herramientas de Vue, MDX, Astro, Svelte y Angular sin una ruta de API estable se mantendrían en TypeScript 6. Utilizaría canaries, despliegue escalonado en editores y una reversión versionada explícita antes de ampliar la adopción.

Análisis detallado paso a paso

Inventariar las dependencias del compilador y de la API

Registre las versiones de Node, gestor de paquetes, TypeScript, tsconfig, referencias de proyectos, cargadores, plugins y editores. Clasifique a los consumidores en CLI, declaraciones/artefactos generados, servicio de lenguaje o API programática; los usuarios de la API programática necesitan una verificación de compatibilidad por separado.

Instalar TypeScript 7 y TypeScript 6 en paralelo

Actualmente, TypeScript 7 ofrece el compilador nativo pero no una API estable. Deje que tsc utilice 7 mientras un alias de npm preserva tsc6:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Fije las versiones que superaron la validación y confirme (commit) el archivo de bloqueo. Los scripts deben llamar a cada binario explícitamente para que el aplanamiento del gestor de paquetes no seleccione silenciosamente el compilador incorrecto.

Establecer líneas base de artefactos comparables

Habilite primero stableTypeOrdering en TypeScript 6 y luego guarde .d.ts, diagnósticos, JavaScript generado, mapas de fuentes, cachés incrementales y resultados de pruebas. Separe los cambios de orden, los errores de tipo reales y las diferencias de formato de las herramientas; solo los cambios explicables y seguros para la API pertenecen a la lista de permitidos.

Ajustar el paralelismo del verificador y del compilador

TypeScript 7 utiliza cuatro trabajadores (workers) de verificación por defecto, y los compiladores (builders) también pueden ejecutarse en paralelo. Mida con CPU, memoria y orden de proyectos fijos antes de aumentar el paralelismo. Registre el tiempo transcurrido (wall-clock time), el pico de RSS, la recolección de basura (GC) y los reintentos; revierta cuando se exceda el presupuesto de memoria del ejecutor. Utilice --singleThreaded para reproducir el no determinismo y mantenga un recuento fijo de workers en CI.

Aislar las herramientas del ecosistema y el despliegue en editores

No fuerce la actualización de las herramientas de plantillas antes de que exista una API programática estable. Las herramientas de Vue, MDX, Astro, Svelte y Angular pueden seguir dependiendo de las API de TypeScript 6, así que permita que consuman tsc6 o mantengan un servicio de lenguaje TS6 por separado. Habilite la extensión de editor correspondiente primero para un canal reducido de desarrolladores y observe las tasas de autocompletado, navegación, diagnósticos y bloqueos (crashes).

Canary, métricas y reversión

Comience con paquetes de bajo riesgo y un canary en CI. Compare el tiempo de compilación, las diferencias de diagnóstico, la compatibilidad de declaraciones, el pico de memoria, los errores en editores y la tasa de aprobación de pruebas. En caso de fallo, restaure el archivo de bloqueo antiguo, los scripts y el canal de editor TS6; eliminar únicamente el paquete TS7 puede dejar un cargador desalineado. Amplíe a otros workspaces solo después de que todas las compuertas se superen de forma reiterada.

Respuesta modelo

El valor de TypeScript 7 radica en un compilador nativo y una CLI más rápida, pero los consumidores de la API definen la frontera de la migración. Ejecutaría un plan de dos vías: TS7 para el trabajo de CLI y TS6 para compatibilidad. Fijaría ambas versiones, expondría tsc y tsc6, y enrutaría los cargadores, herramientas de plantillas y editores según su dependencia de la API programática. Primero habilitaría stableTypeOrdering y compararía declaraciones, diagnósticos, artefactos generados, mapas de fuentes, pruebas y uso de recursos. Ajustaría la configuración paralela frente a un ejecutor fijo, utilizando --singleThreaded para la reproducción. Expandiría mediante canaries y la adopción escalonada en editores; cualquier regresión de diagnóstico, ruptura de declaraciones, sobrecosto de memoria o falla del editor activará la reversión. Debido a que TypeScript 7 aún no cuenta con una API programática estable, mantenga TS6 hasta que las herramientas del ecosistema completen su validación.

Errores comunes

• Reemplazar la versión de typescript sin verificar los cargadores, plugins y herramientas de plantillas que importan su API.
• Atribuir cada aceleración al compilador nativo sin una línea base del repositorio o un presupuesto de memoria.
• Tratar los cambios de orden en declaraciones como regresiones de tipo sin habilitar stableTypeOrdering.
• Maximizar el paralelismo en CI ignorando la memoria del ejecutor y el comportamiento de los reintentos.
• Asumir la compatibilidad del editor y de la API programática solo porque la CLI funciona.
• Planear una reversión verbal de "desinstalar TS7" sin preservar archivos de bloqueo, scripts y versiones del editor.

Preguntas de seguimiento

Si un cargador depende de la API de TypeScript 6, ¿puede actualizarse únicamente CI?

Sí. Actualice primero solo un canary de verificación de tipos, mantenga el cargador en tsc6 o en la API de TypeScript 6 y verifique los artefactos y declaraciones generados antes de actualizar el cargador.

¿Es siempre mejor un valor más alto de --checkers?

No. La CPU, la memoria, el grafo del proyecto y la recolección de basura importan. Elija según el tiempo transcurrido y el pico de RSS en un ejecutor fijo, y mantenga un valor más bajo como alternativa de respaldo.

¿Cuándo se puede eliminar TypeScript 6?

Una vez que cada consumidor de la API programática, herramienta de plantillas, editor y plugin de compilación supere la validación de compatibilidad y las métricas canary permanezcan dentro de las compuertas. Reevalúe la capa de compatibilidad cuando TypeScript 7 disponga de una API estable.

¿Cómo demuestra que los resultados de tipos no cambiaron?

Compare diagnósticos, declaraciones, JavaScript generado, mapas de fuentes y pruebas, clasificando las diferencias de orden y formato. La igualdad en el código de salida por sí sola no es suficiente.