TypeScript 7.1 beta salió el 20 de octubre de 2026. Trae lo que 7.0 dejó afuera en julio: una API programática para las herramientas que se construyen sobre el compilador, más un punto de extensión llamado content mappers que le permite a tsc chequear archivos .vue, .svelte o .mdx. Además suma import attributes en módulos ambientales, source phase imports para WebAssembly, un target es2026 estable y dos cambios de comportamiento que pueden poner en rojo un build que estaba verde.
Instalé 6.0, 7.0 y 7.1 beta en paralelo en un proyecto descartable, reproduje los dos tipos de rotura, probé los fixes en los tres compiladores y armé un script chico de benchmark. Esta es la guía que le pasaría a un equipo de Next.js o Node: cómo probar la beta sin romper el editor ni el CI, cómo medir tu propia mejora y cuándo conviene esperar.
1. El Problema: 7.0 Era Rápido, pero Medio Toolchain No Lo Podía Seguir
TypeScript 7.0 salió el 8 de julio de 2026 como el port nativo del compilador a Go. Microsoft reportó mejoras típicas de 8–12× en builds completos; el codebase de VS Code pasó de 125,7 s a 10,6 s con los cuatro hilos de type-checking por defecto. La trampa estaba escrita en el anuncio: 7.0 salió sin API. Todo lo que importa el compilador como librería — las reglas type-aware de typescript-eslint, Volar para Vue, svelte-check, el chequeo de templates de Angular — tuvo que quedarse en 6.0.
Cómo llegamos acá (fechas verificadas)
Nombres y fechas que circulan mal
Algunas notas fechan la beta el 6 de octubre; el post del devblog y la fecha de publicación en npm dicen 20 de octubre de 2026. El paquete es el typescript de siempre (npm install -D typescript@beta resuelve a 7.1.0-beta) y el binario sigue siendo tsc. @typescript/native-preview era el canal nightly previo a 7.0; las nightlies ahora salen como typescript@next. Las fechas de RC el 10 de noviembre y estable el 24 de noviembre que quizás viste vienen de posts de terceros — Microsoft solo dice “aproximadamente un mes”.
Así que la pregunta para un equipo de Next.js o Node no es si 7.x es rápido — lo es. Es si todo tu toolchain puede correr sobre el mismo compilador, y qué cambia 7.1 en código que compilaba limpio en 7.0.
2. Conceptos Mínimos: Qué Cambia de Verdad en 7.1
Seis cosas, en el orden en que te van a llegar. Las dos primeras son la razón de ser de esta versión; la última es la razón por la que tu build puede fallar.
Una API programática nueva
typescript/sync · /async · /fs · /ast
No es la API de 6.0 portada: entry points separados para un cliente síncrono y uno basado en Promises, file systems virtuales, snapshots y helpers de AST. Los objetos API, Program y Snapshot viven en parte del lado de Go, así que los tenés que liberar (con using, o con close() y dispose()). No lee tsconfig.json ni soporta --project.
Content mappers
contentMappers en tsconfig · --runExternalCode
Un plugin se registra para extensiones como .vue y le entrega a tsc una vista virtual en TypeScript con mapeos al archivo original. Microsoft menciona prototipos o implementaciones para Astro, CSS Modules, Ember, MDX, Svelte y Vue. Como ejecutan código de paquetes, tsc solo los corre con --runExternalCode.
Import attributes en módulos ambientales
declare module "*" with { type: "css" }
Tipás los imports por su atributo y no por la extensión del archivo: CSSStyleSheet para type: "css", string para "text", Uint8Array para "bytes". Un import que omite el atributo falla con TS2307. Estas declaraciones las escribís vos; no vienen en las libs incluidas.
Source phase imports
import source · import.source() · WebAssembly
import source X from "./x.wasm" te da un WebAssembly.Module antes de instanciarlo, listo para WebAssembly.instantiate. Necesita module esnext, nodenext o preserve, más la lib o el target esnext.
Target y lib es2026 estables
--target es2026 · --lib es2026
Math.sumPrecise, Error.isError, Array.fromAsync, Iterator.concat, JSON.rawJSON, getOrInsert en Map y WeakMap y los métodos base64/hex de Uint8Array pasan a una lib estable. 6.0 y 7.0 rechazan ese valor con TS6046.
Dos cambios de comportamiento
DOM lib.d.ts · parámetros de tipo distributivos
Los tipos del DOM regenerados pueden destapar errores nuevos, y dentro de un tipo condicional distributivo el parámetro chequeado ahora cuenta como uno nuevo y más estrecho, así que las restricciones que se apoyaban en el original fallan con TS2344.
Los números de Microsoft: 7.0 vs 7.1 beta
Medido por Microsoft con --noEmit y los cuatro hilos de type-checking por defecto. Comparan 7.1 contra 7.0, no contra 6.x: el gran salto ya pasó en julio. Los benchmarks del fabricante sobre repos conocidos son una referencia, no una promesa para el tuyo.
| Codebase | 7.0 | 7.1 beta | Mejora | Memoria 7.0 → 7.1 beta |
|---|---|---|---|---|
| mui-docs | 22,2 s | 11,9 s | 1,9× | 8.093 → 4.079 MiB (−49,6%) |
| t3code-server | 26,5 s | 19,1 s | 1,4× | 6.894 → 5.197 MiB (−24,6%) |
| sentry | 19,6 s | 15,1 s | 1,3× | 6.587 → 5.216 MiB (−20,8%) |
| vscode | 21,6 s | 17,7 s | 1,2× | 8.387 → 6.943 MiB (−17,2%) |
| bluesky | 4,48 s | 3,89 s | 1,2× | 2.017 → 1.698 MiB (−15,8%) |
La fila de vscode no coincide con los 10,6 s de julio, y Microsoft no explica la diferencia entre ambas corridas. Compará filas dentro de una misma tabla, nunca entre posts.
3. Tutorial: 7.1 Beta en un Proyecto Next.js Sin Romper Nada
Todo lo que sigue corrió en mi sandbox con Windows 11, Node 22.22 y npm 11.11, contra typescript 7.1.0-beta, 7.0.2 y @typescript/typescript6 6.0.2 (cuyo tsc6 reporta 6.0.3). Solo probé con npm; las salidas de los comentarios son las que obtuve.
Paso 1 — Anotá una línea base antes de tocar nada
Anotá qué compilador corre de verdad hoy y guardá su lista de errores. Vas a comparar contra ella después de cada cambio, y la línea de versión detecta una sorpresa que cuento en la sección de errores comunes.
node -v npx tsc -v # el compilador que corren de verdad tus scripts npm ls typescript # quién más trae un TypeScript npx tsc --noEmit --pretty false > typecheck-before.txt
Paso 2 — Instalá 7.1 beta al lado de lo que ya tenés
Elegí el camino que coincide con tu setup de lint. El camino A sirve para proyectos que ya están verdes en 7.0 y no usan linting type-aware. El camino B es el layout con alias que Microsoft recomendó para 7.0, apuntado a la beta: el nombre typescript resuelve a 6.0 para las herramientas que lo importan (typescript-eslint, Angular), y el binario tsc sale de 7.1. En los dos casos fijá la versión exacta, porque el tag beta se va a mover al RC.
# Camino A: ya en verde con 7.0, sin reglas type-aware de typescript-eslint
npm install -D --save-exact typescript@7.1.0-beta
# Camino B: "typescript" sigue en 6.0 para las herramientas, tsc sale de 7.1
npm install -D --save-exact "typescript@npm:@typescript/typescript6@6.0.2" "@typescript/native@npm:typescript@7.1.0-beta"
npx tsc -v # Version 7.1.0-beta
npx tsc6 -v # Version 6.0.3 (solo camino B)
// package.json después del camino B
"devDependencies": {
"@typescript/native": "npm:typescript@7.1.0-beta",
"typescript": "npm:@typescript/typescript6@6.0.2"
}Qué hace next build con todo esto
Según la documentación actual de Next.js, next build corre por defecto el tsc local del proyecto en vez de la API de JavaScript del compilador (experimental.useTypeScriptCli), y así soporta TypeScript 7. Los diagnósticos salen directo de tsc sin los code frames de Next.js, se chequea todo el proyecto que selecciona tu tsconfig y typescript.tsconfigPath sigue eligiendo la config. Si ponés useTypeScriptCli en false estando en TypeScript 7, el build termina porque la API que necesita no existe. La documentación no dice qué binario gana en un layout con alias como el camino B, así que corro tsc --noEmit como paso propio del CI y leo la línea de versión en vez de suponer.
Paso 3 — Scripts y un job de CI que no te pueda bloquear
Corré la beta como un job aparte que tiene permitido fallar hasta que 7.1 sea estable, e imprimí primero la versión para que el log demuestre qué compilador corrió. Microsoft sugiere menos checkers en máquinas con menos núcleos y memoria, como los runners de CI; ajustá --checkers a los tuyos.
// package.json
"scripts": {
"typecheck": "tsc --noEmit",
"typecheck:6": "tsc6 --noEmit",
"bench:tsc": "node scripts/bench-tsc.mjs 5 tsconfig.json"
}
# .github/workflows/ci.yml — un job extra al lado de tu build normal
typecheck-ts71-beta:
runs-on: ubuntu-latest
continue-on-error: true # informativo hasta que 7.1 sea estable
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
with:
node-version: 22
cache: npm
- run: npm ci
- run: npx tsc -v
- run: npx tsc --noEmit --checkers 2Paso 4 — Medí tu propia mejora
Las tablas de Microsoft son de sus repos. Este script corre cada compilador instalado por su ruta explícita, nunca a través de node_modules/.bin, descarta una corrida de calentamiento, desactiva los builds incrementales (los tsconfig de Next.js traen incremental: true, que les regalaría una caché a las corridas siguientes) e imprime la mediana del tiempo real más la memoria que reporta cada compilador. Si querés también la fila de 7.0, agregá "ts70": "npm:typescript@7.0.2" un rato y después sacalo. En mi sandbox de dos archivos la diferencia fue casi todo arranque del proceso (unos 0,9 s para 6.0 contra 0,27 s para 7.x), lo que no dice nada: correlo sobre tu repo real, y otra vez con CHECKERS=2.
// scripts/bench-tsc.mjs · uso: node scripts/bench-tsc.mjs [corridas] [tsconfig]
import { spawnSync } from "node:child_process";
import { existsSync } from "node:fs";
const RUNS = Number(process.argv[2] ?? 5);
const PROJECT = process.argv[3] ?? "tsconfig.json";
const CHECKERS = process.env.CHECKERS; // p. ej. CHECKERS=2 para imitar un runner de CI chico
// Rutas explícitas: nunca confíes en lo que apunte hoy node_modules/.bin/tsc.
const compilers = [
{ label: "6.0", bin: "node_modules/typescript/bin/tsc6" },
{ label: "7.0", bin: "node_modules/ts70/bin/tsc" },
{ label: "7.1-beta", bin: "node_modules/@typescript/native/bin/tsc" },
].filter((c) => existsSync(c.bin));
const median = (xs) => [...xs].sort((a, b) => a - b)[Math.floor(xs.length / 2)];
for (const { label, bin } of compilers) {
const args = [bin, "-p", PROJECT, "--noEmit", "--incremental", "false", "--extendedDiagnostics"];
if (CHECKERS && label !== "6.0") args.push("--checkers", CHECKERS);
const version = spawnSync(process.execPath, [bin, "-v"], { encoding: "utf8" }).stdout.trim();
const wall = [];
const mem = [];
let exit = 0;
for (let i = 0; i <= RUNS; i++) {
const t0 = performance.now();
const r = spawnSync(process.execPath, args, { encoding: "utf8", maxBuffer: 256 * 1024 * 1024 });
const ms = performance.now() - t0;
exit = r.status;
if (i === 0) continue; // calentamiento: llena la caché de archivos del SO, no cuenta
wall.push(ms);
const m = /Memory used:\s+(\d+)K/.exec(r.stdout);
if (m) mem.push(Number(m[1]) / 1024);
}
console.log(
label.padEnd(9),
version.padEnd(20),
"median " + (median(wall) / 1000).toFixed(2) + " s",
"| memory " + (mem.length ? median(mem).toFixed(0) + " MiB" : "n/a"),
"| exit " + exit,
);
}
// Camino A: la ruta por defecto de arriba pasa a ser node_modules/typescript/bin/tsc.Paso 5 — Arreglá la rotura #1: parámetros de tipo distributivos
Este es el ejemplo de Microsoft. Compila en 6.0 y 7.0 y falla en 7.1 exactamente con el error de abajo; lo reproduje. Los tres fixes compilan en los tres compiladores, pero no significan lo mismo, así que elegí según la intención y fijá el resultado con un test de tipos.
type Show<A extends number, B extends A> = `${B} extends ${A}`;
type Issue<A extends number, B extends A> =
A extends B ? never : Show<A, B>;
// 7.1: error TS2344: Type 'B' does not satisfy the constraint 'A'.
// 'B' is only assignable to the non-distributed 'A', but 'A' has been distributed here.
// Fix A: volvé a chequear la relación dentro de la rama (las combinaciones inválidas pasan a never)
type FixA<A extends number, B extends A> =
A extends B ? never : B extends A ? Show<A, B> : never;
// Fix B: sacá una restricción que el helper nunca necesitó (mantiene el resultado de 7.0)
type ShowLoose<A extends number, B extends number> = `${B} extends ${A}`;
type FixB<A extends number, B extends A> =
A extends B ? never : ShowLoose<A, B>;
// Fix C: dejá de distribuir, si querías la unión completa (el resultado cambia)
type FixC<A extends number, B extends A> =
[A] extends [B] ? never : Show<A, B>;
// FixA<0 | 1, 0> = never
// FixB<0 | 1, 0> = "0 extends 1"
// FixC<0 | 1, 0> = "0 extends 0" | "0 extends 1"Paso 6 — Arreglá los errores de config y de lib
Si saltás desde 6.x, las opciones que 6.0 deprecó son errores duros en cualquier 7.x, y los tsconfig viejos de Next.js suelen traer baseUrl y moduleResolution: node. Los paths se resuelven relativos al tsconfig, así que sacar baseUrl en general no pide otro cambio; con esas dos líneas corregidas, la config de mi sandbox pasó en 6.0, 7.0 y 7.1, y la entrada plugins del plugin de editor de Next no molestó en la CLI. En 7.x, types vale [] por defecto, así que si dependés de globales como jest, listá sus paquetes @types explícitamente. Para los tipos del DOM regenerados, Microsoft remite al issue #63702 en vez de listar cada cambio: compará typecheck-before.txt con la salida nueva y arreglá uno por uno los puntos que más tocan el DOM, en vez de fijar una lib vieja.
// Lo que imprimió 7.1 para un tsconfig viejo de Next.js en mi sandbox
// error TS5108: Option 'moduleResolution=node10' has been removed. Please remove it from your configuration.
// error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
// Use '"paths": {"*": ["./*"]}' instead.
// tsconfig.json
{
"compilerOptions": {
- "moduleResolution": "node",
+ "moduleResolution": "bundler",
- "baseUrl": ".",
"paths": { "@/*": ["./src/*"] },
+ "types": ["node", "jest"], // solo si dependés de esos globales
"plugins": [{ "name": "next" }]
}
}Paso 7 — Probá la API nueva: chequeá tipos de código generado en memoria
La API es la novedad principal, y no es solo para autores de frameworks. Este script chequea los tipos de un snippet — por ejemplo, código que acaba de generar un LLM — con settings estrictos sobre un file system virtual, sin escribir nada en disco. Lo corrí en Node 22 con el camino B, por eso los imports de @typescript/native; con el camino A, importá desde typescript/sync, typescript/fs y typescript/ast. Fijate en la forma nueva: los diagnósticos exponen fileName, code y text, no los file y messageText de 6.0.
// check-snippet.mjs: chequeo de tipos en memoria de código generado con la API de TypeScript 7.1
import { API } from "@typescript/native/sync";
import { createFileSystemWithLib } from "@typescript/native/fs";
import { ScriptTarget } from "@typescript/native/ast";
import { resolve } from "node:path";
export function typecheck(code) {
const fileName = resolve("virtual/generated.ts"); // nunca se escribe en disco
const api = new API();
const snapshot = api.createSnapshot({
fileSystem: createFileSystemWithLib([[fileName, code]]),
createPrograms: [
{ rootFiles: [fileName], compilerOptions: { strict: true, noEmit: true, target: ScriptTarget.ES2022 } },
],
});
const program = snapshot.operation.createdPrograms[0];
try {
return program.getSemanticDiagnostics().map((d) => "TS" + d.code + ": " + d.text);
} finally {
program.dispose(); // estos objetos viven del lado de Go: liberalos explícitamente
snapshot.dispose();
api.close();
}
}
console.log(typecheck('export const total = (xs: number[]): number => xs.reduce((a, b) => a + b, "0");'));
// [ "TS2322: Type 'string' is not assignable to type 'number'." ]
console.log(typecheck("export const ok = (xs: number[]): number => xs.length;"));
// []Regla de oro para la beta
Un solo compilador es la fuente de verdad por job, y su versión queda impresa en el log. Adoptá sintaxis exclusiva de 7.1 solo cuando todas las herramientas que leen esos archivos corran 7.1.
4. Estado del Ecosistema (26 de Octubre de 2026) y la Tabla de Decisión
Revisé hoy la metadata de npm y los issues de seguimiento. Un rango de peer dice qué acepta un paquete, no que funcione, pero un rango que excluye 7.x significa que npm se va a quejar y que la herramienta normalmente ni arranca.
typescript-eslint
8.72.0 sigue declarando typescript >=4.8.4 <6.1.0. El issue de seguimiento #10940 está abierto; el 29 de septiembre un maintainer escribió que el soporte de 7.1 se ve “cada vez más estable”, con el PR #12803 en revisión interna, y que no esperan que al principio sea mucho más rápido que con TS6. Quedate con el camino B.
Next.js
16.3 (3 de agosto) sumó el chequeo de tipos con TypeScript 7 en next build, y la documentación actual pone la CLI local de tsc por defecto; la última estable hoy es 16.4.3. El plugin de IDE de Next.js es un plugin de TypeScript aparte, del lado del editor, y el post de 7.0 de Microsoft recomendaba TypeScript 7 donde no hagan falta plugins del language server, así que revisá que sus ayudas sigan apareciendo en tu editor.
Vue
@vue/content-mapper 4.0.0-alpha.0 llegó a npm el 23 de octubre (peer typescript >=7.1.0-beta). El pull request de Vue Language Tools v4 (#6170) sigue en borrador: reemplaza vue-tsc por tsc --runExternalCode y lista regresiones conocidas, como renombres que no tocan los shorthands del template y algunos destinos de go-to-definition.
Svelte y Astro
Microsoft enlaza trabajo de content mappers para ambos (PR #3111 de language-tools de Svelte, PR #17835 de Astro), pero los checkers publicados siguen fijando TypeScript 5 o 6: svelte-check 4.7.7 y @astrojs/check 0.9.12 declaran ^5.0.0 || ^6.0.0.
Angular
@angular/compiler-cli 22.2.3 exige typescript >=6.0 <6.1. El consejo de Microsoft para 7.0 sigue vigente: tsc 7 en la línea de comandos para detectar errores rápido en todo el proyecto, 6.0 para el soporte del editor.
VS Code
Según Microsoft, la extensión de TypeScript 7 pasa a ser la experiencia por defecto al instalarla y se alterna con los comandos Enable/Disable TypeScript 7 Language Server. El issue #64565, todavía abierto, reporta que no detecta un typescript 7.x del workspace y corre su compilador incluido; un comentario dice que configurar js/ts.tsdk.path en node_modules/typescript lo soluciona. Con la beta, confiá en el CI más que en los subrayados.
Tu editor y el CI pueden no coincidir
Con el camino B, typescript-eslint y el language service de 6.0 ven un compilador y el tsc del CI ve otro. Para una prueba está bien, y es justamente por eso que el job de la beta no bloquea y que la sintaxis exclusiva de 7.1 espera hasta que todo migre.
Tabla de decisión: probar la beta, esperar la estable o quedarte en 6.x
| Tu situación | Veredicto | Por qué |
|---|---|---|
| App Next.js o Node, ya en verde con 7.0, sin lint type-aware | Probá ya (job de CI) | Camino A en un job que no bloquea. Microsoft midió chequeos 1,2–1,9× más rápidos que 7.0 y entre 16 y 50% menos memoria; tu riesgo son los dos cambios de comportamiento. |
| Construís herramientas sobre el compilador (codemods, generadores, chequeo de código de LLMs) | Probá ya (rama) | Es la versión en la que aterriza la API, y Microsoft pide feedback antes del RC. Contá con que la superficie va a cambiar. |
| Monorepo grande con mucho código a nivel de tipos | Probá ya (job de CI) | El cambio distributivo pega primero en los helpers de tipos. Mejor encontrar esos errores mientras la beta todavía recibe reportes de bugs. |
| Reglas type-aware de typescript-eslint en el pipeline | Esperá la estable | Su rango de peer termina en <6.1.0. Usá el camino B solo para tsc y migrá del todo cuando typescript-eslint publique soporte para 7.1. |
| Vue, Svelte, Astro o MDX | Esperá la estable | Los content mappers son la solución, pero el de Vue es una alpha con regresiones conocidas en el editor y los checkers de Svelte y Astro siguen fijando 5–6. Experimentá solo en CI. |
| Angular | Quedate en 6.x | @angular/compiler-cli 22.2.3 exige typescript >=6.0 <6.1. tsc 7 igual puede correr como chequeo extra rápido. |
| Todavía en 5.x, o en 6.x con ignoreDeprecations | Quedate en 6.x | Primero limpiá las deprecaciones de 6.0 (baseUrl, moduleResolution node, target es5…). Son errores duros en cualquier 7.x, así que 7.1 no te suma nada hasta resolverlas. |
5. Errores Comunes (Casi Todos Me Pasaron en el Sandbox)
Más o menos en orden de cuánto tiempo te hacen perder.
1. Confiar en npx tsc
Cuando varios paquetes instalados exponen un binario tsc, node_modules/.bin/tsc apunta al que haya quedado enlazado. En mi sandbox, agregar un tercer alias (7.0.2) cambió en silencio npx tsc de 7.1.0-beta a 7.0.2, y otro layout lo resolvió al compilador 6.0.3 que trae @typescript/typescript6. Imprimí tsc -v en el CI y llamá a los binarios por ruta en tus scripts.
2. Instalar el tag beta flotante
typescript@beta se mueve cuando sale el RC, así que la misma instalación te puede dar otro compilador el mes que viene. Usá --save-exact 7.1.0-beta y subí de versión a propósito.
3. Escribir sintaxis exclusiva de 7.1 mientras compiladores viejos leen los archivos
6.0 y 7.0 no pueden parsear declare module "*" with { … } (TS1005) ni import source, y rechazan target es2026 (TS6046). Con el camino B, typescript-eslint y tu editor siguen en 6.0, así que son lo primero que se rompe.
4. Usar import source con el target es2026
es2026 es la lib estable; los source phase imports viven en esnext. Con target es2026 obtuve TS2318: Cannot find global type 'AbstractModuleSource'. Usá la lib o el target esnext, con module esnext, nodenext o preserve.
5. Medir con la caché incremental caliente
Los tsconfig de Next.js traen incremental: true, así que una segunda corrida lee .tsbuildinfo y parece mágicamente rápida. Pasá --incremental false, descartá la primera corrida, compará medianas y usá el mismo valor de --checkers en todas las máquinas.
6. Esperar que el lint vaya más rápido
El maintainer de typescript-eslint espera que su primer soporte de TS 7 rinda más o menos igual que con TS6. La ganancia está en tsc y en el editor, no necesariamente en ESLint.
7. Portar código de la API de 6.0 línea por línea
La API de 7.1 es nueva: los diagnósticos traen fileName y text, no carga tsconfig.json ni soporta --project, y los objetos API, Program y Snapshot se tienen que liberar o pierden memoria del lado de Go.
8. Tratar --runExternalCode como un flag inofensivo
Microsoft describe los content mappers como “en la práctica, ejecutables arbitrarios”. Activá el flag solo para paquetes de mappers a los que les confiarías un script de instalación, y fijá sus versiones.
Conclusión
TypeScript 7.1 es la versión que convierte a 7.x en un toolchain completo en vez de un tsc rápido corriendo al lado de uno de 6.0: la API y los content mappers son lo que esperaban typescript-eslint, Vue, Svelte y Astro. Encima, los propios números de Microsoft muestran otro 1,2–1,9× sobre 7.0 con bastante menos memoria.
Sigue siendo una beta y el ecosistema todavía no cruzó. Instalala en paralelo, fijá la versión, correla en un job de CI que no te pueda bloquear, medí sobre tu propio repo y arreglá ya los errores de tipos distributivos, mientras los reportes todavía pueden influir en el RC.
7.1 beta en una pantalla
Hacé ya
- • 7.1.0-beta fijada en paralelo
- • Job de CI que no bloquea + tsc -v
- • Benchmark sobre tu propio repo
Arreglá
- • Restricciones distributivas TS2344
- • Remociones de baseUrl y node10
- • Diferencias de la lib del DOM
Esperá
- • Soporte 7.1 en typescript-eslint
- • Mappers estables de Vue y Svelte
- • Sintaxis 7.1 en archivos compartidos
Fuentes
- Microsoft — Anuncio de TypeScript 7.1 Beta
- Microsoft — Anuncio de TypeScript 7.0
- Issue #63702 de TypeScript — actualizaciones de lib.d.ts para TypeScript 7.1
- PR #64237 de TypeScript — chequeos más estrictos en parámetros de tipo distributivos
- PR #4712 de typescript-go — content mappers
- Post de lanzamiento de Next.js 16.3
- Documentación de Next.js — useTypeScriptCli
- Issue #10940 de typescript-eslint — usar TS 7 para la información de tipos
- PR #6170 de Vue Language Tools — content mapper (v4 alpha)
- Issue #64565 de TypeScript — extensión de VS Code y TypeScript 7.x del workspace
- Digital Applied — TypeScript 7.1 beta: qué probar



