Diario

Progreso

• TypeScript 7.0.2 fijado en el package.json y el archivo de bloqueo propios del curso, con @types/node 24.13.4 y tsx 4.23.13
• CI: tsc sobre el proyecto y sobre cada fragmento de error, cada ejemplo y cada solución ejecutados con Node.js 24.21.0, las comparaciones en C# y Java compiladas y ejecutadas, todo comparado con su salida esperada en tres SO
• Lección 1: el compilador y las herramientas
• Lección 2: tipado estructural
• Lección 3: uniones y narrowing
• Lección 4: genéricos
• Lección 5: programación a nivel de tipos

QA

El compilador de TypeScript en 7.0.2 — el port a Go — con Node.js 24 y npm 11. La mitad de estas filas son cambios deliberados que rompen una costumbre más que defectos, y la columna Estado dice cuáles. La cuarta fila es el único sitio donde el autor esperaba un error, no lo obtuvo, y resultó que el compilador tenía razón.

No hay tabla de experimentos: esa cuarta fila es la única predicción del diario escrita antes de su prueba, y una tabla de una sola fila se leería como una sección que no se supo llenar.

Esperado	Lo que pasa	Dónde	Medición	Estado
tsc --noEmit con errores devuelve el mismo código de salida de siempre	El código cambió entre la 6.0 y la 7.0	tsc 6.0.3 frente a 7.0.2	La 6.0.3 devuelve 2, la 7.0.2 devuelve 1. En la 7.0.2, 1 significa que los errores impidieron la salida y 2 que se escribió pese a ellos	Por diseño, un cambio con ruptura. Un paso de CI que comprueba el 2 se rompe al actualizar; comprobar que no sea cero 2026-09-15
tsc file.ts junto a un tsconfig.json ignora la configuración en silencio	Desde la 6.0 es un error	tsc 6.0 y posteriores	TS5112. --ignoreConfig restablece el comportamiento antiguo; el curso construye en su lugar un tsconfig pequeño por fragmento erróneo	Por diseño 2026-09-15
Los miembros de una unión se imprimen en el orden en que se declararon	No, y el orden cambió entre versiones	tsc 5.9.3 frente a 7.0.2	Sobre el ForceRadiant.tsx de GA: `“warning”	“error”
Una anotación de varianza out equivocada se rechaza	interface Mislabeled<out T> { accept(value: T): void } compila	tsc 7.0.2	Los parámetros de método son bivariantes, así que T en esa posición satisface ambas anotaciones. C# señala la misma interfaz con CS1961. El fragmento se sustituyó por in T en un método que devuelve T, que tsc sí atrapa con TS2636	Por diseño. El autor esperaba un error y el compilador tenía razón — lo que cambió fue la lección, no él 2026-09-15
Array.isArray estrecha un unknown sin peligro	Lo estrecha a any[]: un acceso a propiedad compila sin comprobación alguna	tsc 7.0.2, la declaración de Array.isArray en la lib	En la solución del ejercicio 2 de la lección 2, item.name compilaba sin comprobación, y tsc nunca pidió los typeof que hacen el código correcto	Por diseño, y conviene saberlo 2026-09-15
Una API estable es silenciosa	module.stripTypeScriptTypes sigue imprimiendo un ExperimentalWarning, aunque el borrado de tipos en sí es estable y mudo	Node.js 24.21.0	El aviso, en cada llamada	Reproducido, no reportado — el mejor candidato aguas arriba de este diario 2026-09-15
El error de Node señala la línea tal como está escrita	La línea de fuente del mensaje lleva espacios donde estaban los tipos	borrado de tipos de Node.js 24.21.0	const guitarSource = instrumentSource; — así es como el borrado preserva los números de línea y columna	Por diseño 2026-09-15
dotnet run file.cs imprime los avisos del compilador en cada ejecución	Construye de forma incremental: una segunda ejecución con la fuente sin cambios los imprime una vez y nunca más	programas de archivo único de .NET 10	La primera pasada de CI falló en los tres sistemas con dos archivos: CS8602 y CS8509 estaban en la salida de la CI y no en la del autor. Corregido con dotnet clean y luego dotnet run --no-cache	Reproducido en CI y en local, no reportado 2026-09-14
Un compilador más nuevo señala los mismos errores	TypeScript 7 encuentra más, y mucho más rápido	tsc 5.9.3 frente a 7.0.2 sobre ga-react-components	180 errores en 14,7 s con la 5.9.3; 197 en 1,9 s con la 7.0.2. Códigos nuevos: TS2591, porque types vale ahora [] por defecto; TS2871 «this expression is always nullish»; TS2550 para .at() con lib en ES2020	Reproducido. El diario deja constancia de su propia reserva: las versiones de las dependencias vienen de una instalación no congelada 2026-09-15
npm ejecuta los scripts de instalación	npm 11.19 ya no los ejecuta por defecto	npm 11.19 con tsx 4.23.13	npm warn install-scripts esbuild@0.28.2 (postinstall: node install.js). tsx funciona igual en los tres sistemas, porque el binario de esbuild llega como paquete de plataforma opcional	Por diseño, valor por defecto cambiado 2026-09-14
TypeScript 7.0 ofrece una API programática	Todavía no tiene ninguna; las herramientas que cargan el compilador como biblioteca usan @typescript/typescript6, un paquete de compatibilidad que da la 6.0 con un comando tsc6	TypeScript 7.0	Leído en la documentación, no ejercitado — el curso no lo necesitó	Por diseño, una carencia conocida del port a Go 2026-09-14
Un archivo de bloqueo escrito en Windows hay que rehacerlo en Linux	Lista los veinte paquetes de plataforma como dependencias opcionales: un solo archivo sirve para los tres sistemas	typescript 7.0.2, el port a Go	@typescript/typescript-win32-x64 en local; el paso de CI lista typescript-linux-x64 y typescript-darwin-arm64	Por diseño, y es lo que abarata la CI a tres sistemas 2026-09-14

2026-09-14 — Instalación de TypeScript 7.0.2

• npm view typescript version da la 7.0.2, el port a Go, publicada el 2026-07-08. El paquete typescript ahora es pequeño: npm instala el compilador como un paquete por plataforma, @typescript/typescript-win32-x64 en mi máquina, y el paso de información de la CI lista typescript-linux-x64 en Linux y typescript-darwin-arm64 en macOS. El archivo de bloqueo lista los veinte paquetes de plataforma como dependencias opcionales, así que npm ci funciona en los tres SO con el único archivo de bloqueo escrito en Windows.
• TypeScript 7.0 todavía no tiene API programática. Las herramientas que cargan el compilador como biblioteca pueden usar @typescript/typescript6, un paquete de compatibilidad que proporciona TypeScript 6.0 con un comando tsc6; no lo necesité para el curso.
• El curso fija sus versiones en code/typescript-for-csharp-java/package.json, no en el del sitio: el propio sitio no tiene ninguna dependencia typescript.
• npm 11.19 ya no ejecuta los scripts de instalación por defecto. Instalar tsx imprimió npm warn install-scripts esbuild@0.28.2 (postinstall: node install.js), y tsx funciona de todos modos, en los tres SO: el binario de esbuild viene de un paquete de plataforma instalado como dependencia opcional.

2026-09-14 — La CI

• typescript-examples.yml instala Node.js 24.21.0, .NET 10 y Java 25, ejecuta npm ci en la carpeta del curso, y luego check.sh con REQUIRE_COMPARE=1, para que la falta de dotnet o java haga fallar la ejecución en lugar de saltarse las comparaciones.
• check.sh ejecuta tsc una vez sobre todo el proyecto, que debe pasar, y una vez por fragmento de error, con un tsconfig generado que extiende el del curso y lista ese único archivo; un fragmento puede pedir opciones adicionales con un comentario // tsc options:, como hace noUncheckedIndexedAccess en la lección 2. normalize.mjs, adaptado del curso de JavaScript, hace relativas las rutas y quita los marcos de la pila y los identificadores de proceso.
• La primera ejecución falló en los tres SO, solo en dos archivos, y por el mismo motivo: las advertencias de C# CS8602 y CS8509 estaban en la salida de la CI y no en la mía. dotnet run file.cs compila un programa basado en archivo de forma incremental, y una segunda ejecución con el fuente sin cambios no llama al compilador, así que sus advertencias solo se imprimen una vez. check.sh ahora ejecuta dotnet clean sobre el archivo antes de dotnet run --no-cache, y las salidas capturadas en Windows coinciden en Linux y macOS. La siguiente ejecución pasó en los tres SO en 2 minutos y 41 segundos, siendo Windows el job más lento.

2026-09-15 — Sorpresas al escribir las lecciones 1-4

El código de salida de tsc cambió entre la 6.0 y la 7.0. Con --noEmit y errores, tsc 6.0.3 devuelve 2, y la 7.0.2 devuelve 1. En la 7.0.2, 1 significa que los errores impidieron la salida, con noEmit o noEmitOnError, y 2 que la salida se escribió a pesar de los errores, lo que la lección 1 muestra con l01-emit. Un paso de CI que compruebe $? -eq 2 se rompería con la actualización; comprueba que el código no sea cero.

tsc file.ts junto a un tsconfig.json es un error desde la 6.0. TS5112 se niega a ignorar la configuración en silencio, como hacían las versiones anteriores; --ignoreConfig restaura el comportamiento anterior. check.sh construye en su lugar un pequeño tsconfig para cada fragmento de error.

Los miembros de una unión no se imprimen en el orden de declaración. La misma comparación en ForceRadiant.tsx de GA imprime "warning" | "error" | "unknown" | "contradictory" con la 5.9.3 y "contradictory" | "error" | "unknown" | "warning" con la 7.0.2. Las notas de la versión 6.0 lo explican: TypeScript 7 ordena los tipos por contenido para que los verificadores en paralelo coincidan. Las salidas esperadas de la lección 3 son solo las de la 7.0.2.

Una anotación out errónea compila. Escribí interface Mislabeled<out T> { accept(value: T): void } para el fragmento de error de la lección 4, esperando un error, y tsc 7.0.2 lo aceptó: accept es un método, los parámetros de los métodos son bivariantes, y T en esa posición satisface las dos anotaciones. C# señala la misma interfaz con CS1961. El fragmento usa ahora el error que tsc sí detecta, in T en un método que devuelve T (TS2636).

Array.isArray trae de vuelta any. En la solución del segundo ejercicio de la lección 2, el valor era unknown, y Array.isArray(value) lo estrechó a any[]: item.name compilaba sin comprobación. Las comprobaciones typeof de la solución la hacen correcta; tsc no las pidió. La lección 2 lo señala.

Node.js imprime la línea sin tipos. Cuando un archivo .ts falla en tiempo de ejecución, la línea del fuente en el mensaje de Node.js tiene espacios donde estaban los tipos, como en el const guitarSource = instrumentSource; de la lección 4. Así es como la eliminación de tipos conserva los números de línea y de columna.

module.stripTypeScriptTypes todavía imprime un ExperimentalWarning en la 24.21.0, aunque la eliminación de tipos en sí es estable y silenciosa; la lección 1 muestra la advertencia.

2026-09-15 — Lo que encontró tsc en GuitarAlchemist/ga (a826864)

Cloné GuitarAlchemist/ga en a826864 en una carpeta de pruebas, instalé los dos frontends, y ejecuté tsc con la 5.9.3, la versión que resuelve el pnpm-lock.yaml de la biblioteca de componentes, y con la 7.0.2.

• Nombres usados y nunca definidos. Apps/ga-client/src/components/Chat/ChatInterface.tsx usa VIRTUALIZATION_THRESHOLD (líneas 69 y 219) y VirtualizedMessageList (líneas 254 y 255), y nada los define ni los importa: TS2304. La ruta /ai-copilot de App.tsx carga ese componente, así que la página debería lanzar un ReferenceError al renderizarse (por verificar en un navegador). Reproducción: cd Apps/ga-client && npm ci && npx tsc -b --pretty false | grep ChatInterface. Parece un bug que merece una issue.
• Los errores de tipo no hacen fallar el build. Los dos frontends se construyen con vite build, que elimina los tipos sin verificarlos; ga-client da 346 errores con tsc -b (165 de ellos TS6133, variables sin usar), y ga-react-components 186. Un paso tsc --noEmit en la CI habría detectado los nombres que faltan.
• Un archivo de bloqueo desactualizado. En ReactComponents/ga-react-components, pnpm install --frozen-lockfile falla con ERR_PNPM_OUTDATED_LOCKFILE: faltan en pnpm-lock.yaml 21 dependencias de package.json, y las versiones de @react-three/drei y @react-three/fiber difieren. Instalé sin --frozen-lockfile, así que los recuentos de errores de la biblioteca de componentes pueden depender de las versiones que obtuve.
• Estados que el tipo excluye. ForceRadiant.tsx, líneas 721 y 725, compara un GovernanceHealthStatus con 'ok' y 'critical', que la unión no contiene (TS2367), y DataLoader.ts, líneas 276-278, pasa el healthStatus: string de un mensaje SignalR a través de as unknown as GovernanceNode. O a la unión le faltan dos estados, o las comparaciones son código muerto (por verificar en el hub de GA). La línea 1464 del mismo archivo compara una severidad de señal, 'info' | 'warning' | 'emergency', con 'critical'. La lección 3 reduce el primer caso.
• noImplicitAny: false junto a strict: true en ga-react-components/tsconfig.app.json. Volver a activarlo solo añade cuatro errores, en BSPDoomExplorer.tsx e IxqlFormPanel.tsx; la lección 2 los lista.
• Datos sin comprobar. La biblioteca de componentes tiene 34 as unknown as, 42 llamadas a JSON.parse y 18 as any. La cámara se restaura desde localStorage con JSON.parse(saved) as { px: number; … } (ForceRadiant.tsx, línea 3558), loadQueue<T> devuelve JSON.parse como un T[] (CourseViewer.tsx, línea 152), y el isApiResponse<T> de ga-client comprueba dos nombres de propiedad antes de prometer un ApiResponse<T>, con json as T como recurso final (musicService.ts, líneas 17-49). Las lecciones 3 y 4 y sus ejercicios escriben las versiones comprobadas.
• TypeScript 7 encuentra más. tsc -p tsconfig.app.json sobre la biblioteca de componentes da 180 errores en 14.7 segundos con la 5.9.3 y 197 en 1.9 segundos con la 7.0.2. Los errores nuevos son nombres de Node.js en dos scripts (TS2591, porque types vale ahora [] por defecto), TS2871 (“this expression is always nullish”) en BrainstormPanel.tsx línea 40 y GitHubPollingManager.ts línea 48, y TS2550 para .at() en ChatWidget.tsx línea 1254, con lib fijado a ES2020; la 5.9.3 no señaló ninguno de esos códigos.
• Detalles. ga-client/tsconfig.json tiene "sourceMaps": true en su nivel superior, donde tsc lo ignora; la opción es sourceMap, dentro de compilerOptions. src/components/PrimeRadiant/index.ts en la biblioteca de componentes exporta RemediationAction dos veces (TS2300, líneas 101 y 129), y ThreeFretboard.tsx línea 780 usa un tipo GuitarModelStyle que no existe. ShowcasePanel.test.tsx de ga-client usa el global de Node.js, que los tipos del proyecto de navegador no declaran.

2026-09-15 — Lo que encontró tsc en este sitio (8ba378e)

npx -p typescript@7.0.2 tsc --noEmit en el commit 8ba378e, con el tsconfig.json del sitio, da tres errores, los mismos con la 6.0.3. Ninguno rompe el sitio.

• astro.config.mjs, línea 146: la barra lateral importada de src/streeling-sidebar.json no coincide con el SidebarItemUserConfig de Starlight, porque la unión inferida de sus entradas añade fr?: undefined a la entrada que solo tiene traducción al español. La lección 3 explica la inferencia.
• code/javascript-for-csharp-java/errors/l04_private_outside.js: el tsconfig.json del sitio incluye **/*, así que tsc verifica el código de los cursos, incluido un fragmento de error que es incorrecto a propósito. Los errors/*.ts del curso de TypeScript se recogerán de la misma manera; excluir code/ en el tsconfig.json del sitio mantendría a los editores y a tsc en los archivos propios del sitio.
• src/content.config.ts: astro:content solo se declara después de astro sync.

Por verificar

• El ReferenceError en la página /ai-copilot de GA, en un navegador.
• Si el hub de gobernanza de GA envía ok y critical como estados de salud.
• Qué hace ForceRadiant de GA con una cámara guardada a la que le falta una coordenada.
• new[] { 1, "two", null } en C#, citado en la lección 2 como rechazado por falta de un mejor tipo común.
• Los comandos de instalación de la lección 1 en Linux y macOS fuera de la CI.