TypeScript 6.0 RC: características, cambios importantes y cómo prepararse

Home » Python » TypeScript 6.0 RC: características, cambios importantes y cómo prepararse

TypeScript 6.0 ha alcanzado oficialmente el hito de Release Candidate (RC).Y no se trata de una simple actualización incremental. Esta es la última versión importante que se ejecuta en la implementación de JavaScript de larga trayectoria del compilador y el servicio de lenguaje, justo antes de que el proyecto dé el salto a un motor completamente nuevo basado en Go en TypeScript 7.0. Solo por eso, la versión 6.0 es un lanzamiento crucial: es el puente que hay que cruzar antes de que cambie todo internamente.

Puedes empezar a probar la versión candidata hoy mismo instalándola desde npm. con:

npm install -D typescript@rc

La idea central detrás de TypeScript 6.0 es la preparación y la alineación.Esta versión facilita la transición de la 5.9 a la 7.0, ajustando los valores predeterminados, eliminando elementos obsoletos y añadiendo algunas características específicas que reflejan el comportamiento futuro o exponen capacidades de JavaScript futuras como Temporal, las API de ES2025 y los métodos "upsert" de Map. En el proceso, se incluyen algunos ajustes sutiles del sistema de tipos, nuevas banderas del compilador y valores predeterminados de configuración que afectarán sin duda a los proyectos reales, especialmente en torno a types, rootDiry rigor.

TypeScript 6.0 como puente hacia la versión 7.0 basada en Go.

TypeScript 6.0 está diseñado explícitamente como la última versión principal del código base de JavaScript existente.El equipo de TypeScript ha estado reescribiendo el compilador y el servicio de lenguaje en un motor nativo en GoAprovechando el rendimiento nativo y el paralelismo de memoria compartida, este nuevo motor debutará con TypeScript 7.0 y versiones posteriores, mientras que la versión 6.0 se sitúa justo antes como etapa de transición.

La mayoría de los cambios incompatibles y las funciones obsoletas en la versión 6.0 están ahí para que tu futura actualización a la versión 7.0 sea viable.Las opciones que no se pueden admitir de manera eficiente en la arquitectura nativa, los sistemas de módulos antiguos y las peculiaridades de larga data se están eliminando o se marcan claramente como obsoletas con una vía de escape: puede configurar "ignoreDeprecations": "6.0" en tu tsconfig.json para suprimir los diagnósticos de obsolescencia en la versión 6.0. Pero esa opción no te servirá en la versión 7.0, ya que está previsto que desaparezcan por completo.

Si tienes la tentación de "esperar a la versión 7.0" antes de realizar cualquier limpieza de configuración, estás cayendo en una trampa.. La versión 6.0 RC es donde se supone que debes arreglar tu tsconfigNormalizar los tipos y gestionar las banderas obsoletas. Dar dos saltos gigantescos (5.x → 7.0) siempre será más perjudicial que ir de 5.x → 6.0 → 7.0 con cambios más pequeños y controlados.

¿Qué ha cambiado desde la versión beta 6.0?

Entre la versión beta y la RC, el equipo de TypeScript se centró principalmente en alinear el comportamiento con el futuro motor 7.0., además de algunos ajustes específicos en la comprobación de tipos y las definiciones de tipos del DOM.

Un cambio importante afecta a la comprobación de tipos de las expresiones de función pasadas a las llamadas genéricas.especialmente en contextos JSX. Cuando se invocan funciones genéricas con devoluciones de llamada (por ejemplo, en React u otros componentes JSX), la RC ajusta la inferencia para que refleje con mayor precisión lo que hará la versión 7.0. En la práctica, es posible que observe que algunas llamadas que dependían de la inferencia implícita ahora requieren un argumento de tipo explícito para que la comprobación de tipos funcione correctamente, pero también detectará más errores reales en el código existente.

La obsolescencia de la sintaxis de aserción de importación también se ha extendido.TypeScript ya estaba advirtiendo sobre el antiguo import ... assert {...} sintaxis en importaciones estáticas debido a la propuesta de ECMAScript que cambia a importar atributos con withAhora, esa obsolescencia también se aplica a las importaciones dinámicas que utilizan import() con objetos de aserción como import(..., { assert: {...}})La dirección es clara: importar atributos en todas partes.

Los tipos de la biblioteca DOM se han actualizado para que coincidan con los estándares actuales de la plataforma web.Esto incluye actualizaciones de las API relacionadas con Temporal en contextos web. Si desarrollas aplicaciones para navegador, te beneficiarás de tipados más precisos y mejores herramientas de edición en torno a estas nuevas API.

Menor sensibilidad al contexto para funciones que nunca se utilizan this

TypeScript 6.0 introduce un cambio sutil pero muy práctico en la forma en que trata las funciones sin una declaración explícita. this uso durante la inferencia de tiposHistóricamente, las funciones con parámetros que carecen de tipos explícitos podrían considerarse "sensibles al contexto", lo que significa que su parámetro y this Los tipos dependían del contexto en el que se utilizaban. Esto afecta a la inferencia genérica y puede provocar un comportamiento anómalo según la sintaxis de la función.

Consideremos una función auxiliar genérica que utiliza un par productor-consumidor.:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

Pero con la sintaxis de métodos, el comportamiento anterior podría resultar sorprendente.. La misma lógica, escrita como métodos, podría fallar cuando se reordenan las propiedades, porque TypeScript omitió las funciones "sensibles al contexto" al inferir argumentos genéricos. Los métodos implícitamente tienen una this parámetro, que los colocó en esa categoría sensible incluso si this Nunca se hizo referencia a ello.

En 6.0, funciones que nunca leen this Ahora se les trata como menos sensibles al contexto.Dicho de otro modo, si el compilador ve que this Si no se utiliza dentro de una función, no penalizará dicha función durante la inferencia. Esto significa que la sintaxis de métodos y la sintaxis de flechas ahora son mucho más consistentes en escenarios de inferencia genéricos, y el comportamiento extraño de "funciona en un orden de propiedades, pero falla en otro" desaparece en estos casos.

Este cambio mejora la priorización de candidatos para la inferencia de tipos.: funciones sin un uso this se convierten en fuentes de información de mayor prioridad al inferir argumentos de tipo como TEl efecto es menos misterioso. unknown tipos y una inferencia más estable entre refactorizaciones. Este trabajo fue aportado por Mateusz Burzyński.

Soporte para Node #/ importaciones de subrutas

La función "importaciones de subrutas" de Node permite que los paquetes definan alias de importación internos a través de imports campo en package.jsonEstos alias simplifican las importaciones al evitar rutas relativas profundas. Anteriormente, cada clave de subruta tenía que tener al menos un segmento después de la ruta inicial. #, lo cual era una limitación pequeña pero molesta para las personas acostumbradas a las convenciones de empaquetadores como @/....

TypeScript 6.0 ahora admite importaciones de subrutas que comienzan con #/, en consonancia con el comportamiento más reciente de Node 20. Esto significa que puede utilizar una configuración como la siguiente:

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

Con esta configuración, los módulos dentro del paquete, e incluso los consumidores, pueden importar a través de un código conciso. #/... prefijo en lugar de largas rutas relativas como ../../utils.jsTypeScript entiende este patrón cuando --moduleResolution esté configurado como node20, nodenext o bundler, reflejando la semántica de Node moderno. Esta mejora fue implementada por el colaborador magic-akari.

El uso de --moduleResolution bundler con --module commonjs

Anteriormente, --moduleResolution bundler solo se puede usar con --module esnext or preserve. Con la descontinuación de la versión anterior node/node10 En el modo de resolución de módulos, muchos proyectos necesitaban una ruta de migración que se ajustara a su salida CommonJS actual.

TypeScript 6.0 ahora permite combinar --moduleResolution bundler con --module commonjsEsta combinación suele ser un paso práctico para las bases de código que aún generan CommonJS pero que se están orientando hacia flujos de trabajo centrados en empaquetadores o una lógica de resolución más reciente. A partir de ahí, los proyectos pueden planificar una migración a largo plazo hacia cualquiera de las siguientes opciones:

• module: "preserve" con moduleResolution: "bundler" para aplicaciones web empaquetadas y configuraciones similares, o
• module: "nodenext" para entornos que utilizan directamente Node.js moderno.

Este cambio es especialmente relevante para los equipos que se marchan moduleResolution: node detrás de pero aún no estamos listos para adoptar por completo los resultados de ESM. Te ofrece una ruta por fases en lugar de un salto al vacío.

La --stableTypeOrdering bandera para emular el ordenamiento 7.0

Una de las principales mejoras arquitectónicas que trae TypeScript 7.0 es la comprobación de tipos en paralelo.Ejecutar varios verificadores en paralelo implica que diferentes partes del programa pueden visitarse en distintos órdenes. Si los identificadores de tipo y el orden de los símbolos dependen del orden de visita, se puede producir un ordenamiento de uniones no determinista, un ordenamiento de propiedades e incluso raras diferencias en los diagnósticos.

Las versiones anteriores de TypeScript asignan identificadores de tipo internos en función del orden de aparición.Esos identificadores se utilizan luego para ordenar cosas como tipos de unión y propiedades. Por eso, las ediciones aparentemente inofensivas, como la introducción de un nuevo const antes de una función existente, puede invertir el orden de las uniones literales en los datos emitidos. .d.ts archivos, o cambiar la forma en que se imprimen algunos tipos en su editor.

TypeScript 7.0 cambia a un ordenamiento determinista basado en el contenido para los objetos internos.Cada tipo o símbolo se ordena según su estructura, no según el orden de visita fortuito, por lo que el mismo programa producirá siempre el mismo orden, independientemente del paralelismo o del orden de compilación. Esto elimina el misterio de "¿por qué mi unión cambió de repente?".

Para ayudarle a comparar el comportamiento entre 6.0 y 7.0, el RC presenta: --stableTypeOrderingCuando esta opción está activada, TypeScript 6.0 adopta el mismo algoritmo de ordenación de tipos determinista que utiliza la versión 7.0. El resultado son muchas menos diferencias en los archivos de declaración generados y comparaciones más predecibles entre las salidas de las versiones 6.x y 7.x.

Sin embargo, el determinismo no es gratuito.. Habilitar --stableTypeOrdering Puede ralentizar la comprobación de tipos hasta en un 25%, dependiendo del código fuente. Está pensada como una herramienta de diagnóstico y migración, no como una configuración de rendimiento permanente.

Si solo ve errores de tipo cuando --stableTypeOrdering está prendidoPor lo general, esto significa que tu código anterior dependía del antiguo ordenamiento casi accidental de tipos para que la inferencia funcionara sin problemas. Las soluciones suelen consistir en hacer explícitos los tipos: añadir un argumento de tipo a una llamada genérica problemática o anotar una variable con una interfaz específica en lugar de depender completamente de la inferencia para un objeto complejo.

New es2025 Opciones de destino y biblioteca

TypeScript 6.0 agrega un es2025 opción para ambos target además lib. Si bien ES2025 no introduce una nueva sintaxis central en comparación con años anteriores, sí incorpora varias API estandarizadas que antes estaban restringidas. esnext.

Al apuntar o incluir es2025, obtienes tipados actualizados para nuevos integrados como RegExp.escapey algunas API se trasladan fuera de esnext cobren es2025Eso incluye cosas como Promise.try, ayudantes de iterador y extra Set métodos que han alcanzado la madurez de especificación completa. Este trabajo fue aportado por Kenta Moriuchi.

La historia más amplia es que el predeterminado target En la versión 6.0, ahora se realiza un seguimiento del año ECMAScript actual., lo que en la práctica te lleva a ES2025 cuando no especificas un destino. Esto se ajusta mejor a la realidad de los entornos de ejecución permanentes y las herramientas modernas.

Tipos integrados para la API temporal

La tan esperada propuesta Temporal ha llegado a la etapa 3 y se espera que reemplace a la infame Date API para operaciones serias de fecha/horaTypeScript 6.0 ahora incluye definiciones de tipos de primera clase para Temporal, por lo que puedes empezar a escribir código basado en Temporal con total seguridad de tipos y compatibilidad con el editor.

Para habilitar los tipos temporales, puede usar --target esnext o configure sus bibliotecas explícitamente a través de algo como:

{
  "compilerOptions": {
    "lib": 
  }
}

O puede optar por solo el subconjunto temporal con "esnext.temporal" Si desea una configuración más detallada, una vez habilitada, puede escribir código similar a este:

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

Temporal ya es compatible con algunos entornos de ejecución y puede implementarse mediante polyfills en otros.Por lo tanto, estos tipos son realmente utilizables hoy en día. La documentación está surgiendo en MDN (aunque aún quedan algunos detalles por completar). Las definiciones de tipos fueron aportadas por el usuario de GitHub Renegade334.

Soporte para Upsert: Map.getOrInsert además getOrInsertComputed

Los desarrolladores de JavaScript han estado escribiendo manualmente patrones "check-then-set-then-get" en Map por añoUn patrón típico consiste en comprobar si existe una clave, establecer un valor predeterminado si no existe y, finalmente, devolver un valor; un código repetitivo que es fácil de interpretar erróneamente o de repetir en todas partes.

La propuesta “upsert” de ECMAScript (ahora en etapa 4) introduce getOrInsert además getOrInsertComputed on Map además WeakMap. TypeScript 6.0 agrega soporte de tipos para estos métodos en el esnext lib, para que puedas empezar a escribir más actualizaciones e inserciones declarativas de inmediato.

Con getOrInsert, un patrón detallado como este:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

Se puede contraer a una sola línea.:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

La compañia getOrInsertComputed es ideal para impagos costosos—Requiere una función de devolución de llamada que solo se invoca si falta la clave. Esta función puede incluso recibir la clave como parámetro, lo que permite derivar el valor predeterminado a partir de la clave misma. Las definiciones de tipos de TypeScript capturan estos comportamientos con precisión, gracias nuevamente a las contribuciones de Renegade334.

RegExp.escape y una construcción de expresiones regulares más segura

Si alguna vez has concatenado cadenas proporcionadas por el usuario en una expresión regular, sabrás que primero debes escapar los caracteres especiales.—pero la mayoría de las bases de código o bien reimplementan el escape en una función auxiliar o lo olvidan por completo. La propuesta RegExp Escaping (ahora en la etapa 4) estandariza esto con RegExp.escape.

TypeScript 6.0 expone tipos para RegExp.escape (Lazy section loading) bajo la sección es2025 libEsto significa que cuando se utiliza ES2025 como objetivo o se incluye en él, se pueden escribir funciones auxiliares como:

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

Ya no es necesario un mecanismo de escape manual.y TypeScript comprenderá y verificará completamente la API. Esta adición, al igual que el trabajo relacionado con el estándar ES2025, proviene de Kenta Moriuchi.

dom La biblioteca ahora incluye API de iteración e iteración asíncrona.

Históricamente, TypeScript dividió el soporte del iterador DOM en dom, dom.iterabley el ámbito dom.asynciterable. Si quisieras iterar sobre NodeList or HTMLCollection con for...of, tenías que acordarte de añadir dom.iterable en tu "lib" configuración junto con domEsto era una fuente común de confusión, especialmente porque todos los navegadores modernos admiten iterables e iterables asíncronos en colecciones DOM.

En TypeScript 6.0, lib.dom.iterable.d.ts además lib.dom.asynciterable.d.ts se fusionan efectivamente en lib.dom.d.tsEso significa usar "dom" Ahora, por defecto, solo te proporciona un comportamiento iterable e iterable asíncrono.

Aún puedes mencionar dom.iterable además dom.asynciterable en tu tsconfigpero esos archivos ahora son cáscaras vacías. Si tu configuración anterior se veía así:

{
  "compilerOptions": {
    "lib": 
  }
}

Puedes simplificarlo de forma segura a solo "dom"y la iteración sobre colecciones DOM como document.querySelectorAll("div") Seguirá realizando la comprobación de tipos:

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

Esta es una limpieza pequeña pero bienvenida. Esto adapta la biblioteca DOM predeterminada a la realidad de los navegadores actuales y elimina otro inconveniente en la configuración del proyecto.

Valores predeterminados, funciones obsoletas y cambios incompatibles en TypeScript 6.0

Más allá de las API brillantes, la versión 6.0 introduce algunos de los cambios más radicales en la configuración predeterminada de TypeScript desde la versión 1.0.Estos cambios reflejan el ecosistema actual de JavaScript: entornos de ejecución siempre actualizados, ESM como base, uso generalizado de empaquetadores y un fuerte interés por el tipado estricto y el rendimiento.

El equipo destaca algunas tendencias generales que sustentan estas decisiones.ES5 y los navegadores verdaderamente heredados están prácticamente desaparecidos; los sistemas de módulos AMD/UMD son un nicho de mercado; casi todo se distribuye ahora como módulos; la tipificación estricta es la norma; y el rendimiento debe seguir siendo primordial, especialmente ahora que la versión 7.0 introduce la comprobación paralela.

Como resultado, TypeScript 6.0 y 7.0 se están diseñando con valores predeterminados modernos y menos "válvulas de escape heredadas".Para 6.0 RC, puede silenciar temporalmente las obsolescencias configurando "ignoreDeprecations": "6.0" en tu tsconfig, pero esas opciones no existirán en la versión 7.0. Algunos ajustes se pueden automatizar con herramientas como la experimental. ts5to6 codemod, que puede ayudar a reescribir cosas como baseUrl además rootDir configuraciones en todo un proyecto.

Dos ajustes que muchos proyectos necesitarán de inmediato

Si bien existe una larga lista de funciones obsoletas, es probable que dos cambios de configuración afecten a la mayor cantidad de bases de código.:

• Establecer explícitamente el types matriz (muy a menudo) más su marco de prueba). Sin esto, perderá los tipos ambientales incluidos automáticamente de @types/*.
• Establecer explícitamente rootDir (comúnmente "./src") Si te basabas en la antigua "inferencia de raíz común". De lo contrario, la estructura de archivos generada podría variar sutilmente.

Síntomas de ausencia types incluir una avalancha de errores sobre variables globales como process, fs, path o describe ser indefinidoSíntomas de un cambio rootDir se trata más bien de rutas de salida que ganan inesperadamente un extra src segmento (por ejemplo dist/src/index.js en lugar de dist/index.js).

Valores predeterminados actualizados para proyectos modernos

Varias opciones del compilador ahora tienen nuevos valores predeterminados que coinciden con la forma en que se compilan la mayoría de las aplicaciones nuevas.:

• strict ahora el valor predeterminado es trueEl modo estricto ya no es un lujo opcional; es la opción básica. Si anteriormente dependía del comportamiento no estricto, deberá configurarlo explícitamente. "strict": false (aunque te perderás una gran categoría de controles de seguridad).
• module ahora el valor predeterminado es esnext, lo que refleja que ESM es el formato de módulo dominante y que funciona mejor con los empaquetadores y las versiones modernas de Node.
• target Por defecto, se utiliza el año actual de ECMAScript (que actualmente es ES2025)., reconociendo que la mayoría de las implementaciones se dirigen a entornos siempre actualizados o pasan por un empaquetador que puede degradar aún más el nivel cuando sea realmente necesario.
• noUncheckedSideEffectImports es ahora true por defecto, ayudándote a detectar errores tipográficos o rutas incorrectas en importaciones que se incluyen solo para efectos secundarios.
• libReplacement por defecto es false, evitando una gran cantidad de resoluciones de módulos fallidas adicionales y la sobrecarga de supervisión hasta que un proyecto opte explícitamente por comportamientos de biblioteca especializados.

Si alguno de estos nuevos valores predeterminados rompe su compilación, todos ellos pueden ser anulados explícitamente en tsconfig.jsonPero la intención es que los nuevos proyectos "simplemente hagan lo correcto" sin necesidad de configuración adicional.

rootDir ahora usa por defecto el directorio de configuración.

Anteriormente, si no especificaba rootDirTypeScript intentó inferir una raíz de origen común. Basándose en todos los archivos que no son declaraciones en el programa. Eso dificultó el razonamiento sobre los límites del proyecto y requirió examinar muchas rutas de archivo solo para decidir dónde debía ubicarse la función emit.

En TypeScript 6.0, el valor predeterminado rootDir es simplemente el directorio que contiene tsconfig.jsonEl comportamiento de inferencia anterior solo se aplica cuando ejecuta tsc en la línea de comandos sin ningún tsconfig en absoluto.

Este cambio significa que los proyectos con archivos fuente más profundos que el directorio de configuración deben configurarse explícitamente. rootDirUna configuración común sería:

{
  "compilerOptions": {
    // ...
    "rootDir": "./src"
  },
  "include": 
}

Si su configuración hace referencia a archivos por encima de la tsconfig ubicación, también necesitará extender rootDir en consecuencia, Por ejemplo "rootDir": "../src" para directorios de código fuente compartidos.

types ahora por defecto es un array vacío.

Este es posiblemente el cambio de mayor impacto para los proyectos del mundo real.Históricamente, si no especificabas types in compilerOptions, TypeScript incluiría automáticamente todo lo que esté bajo node_modules/@typesEso era conveniente, pero también caro y frágil: los repositorios modernos a menudo extraen cientos de @types paquetes de forma transitiva.

En TypeScript 6.0, types por defecto es []lo que significa que no se cargan automáticamente paquetes de tipo ambiental.Ahora usted elige explícitamente los entornos globales que realmente necesita, por ejemplo:

{
  "compilerOptions": {
    "types": 
  }
}

Esto puede reducir los tiempos de compilación entre un 20 % y un 50 % en algunos proyectos., porque el compilador ya no tiene que recorrer cada archivo de declaración en @types. Si realmente desea el comportamiento anterior de “cargar todo”, puede especificar:

{
  "compilerOptions": {
    "types": 
  }
}

Si de repente ve errores como “No se puede encontrar el nombre 'process'” o “No se puede encontrar el módulo 'fs'”, esa es tu señal para agregar node (y cualquier otro tipo de prueba/tiempo de ejecución en el que confíe) a su types formación.

Obsoleto: target: es5 además --downlevelIteration

El uso de ES5 como objetivo ya no está recomendado.Dado que todos los navegadores relevantes llevan años implementando ES2015 o superior, e Internet Explorer ya no recibe soporte, la complejidad de la salida ES5 ya no justifica su complejidad interna en TypeScript. El objetivo mínimo compatible de ahora en adelante es ES2015. Si realmente necesita implementar ES5, se recomienda usar un transpilador externo (como Babel o un empaquetador) ya sea en el código fuente de TS o en la salida de TS.

La --downlevelIteration La bandera también está obsoleta., porque su único caso de uso significativo era ajustar el comportamiento de emisión para objetivos ES5. En TypeScript 6.0, configurar downlevelIteration En cualquier caso, se producirá un error de obsolescencia. Si estás usando ES2015 o una versión posterior, la bandera nunca tuvo ningún efecto.

Obsoleto: --moduleResolution node y legado classic

La node (aka node10El modo de resolución de módulos está obsoleto.Modelaba el comportamiento de Node 10, pero no coincide con la semántica ESM y de resolución de Node moderno. Los proyectos deberían migrar a uno u otro. nodenext (para destinos de nodo directos) o bundler (para entornos controlados por empaquetadores como aplicaciones web o Bun).

El original moduleResolution: classic La estrategia también ha sido eliminadaEsta fue la historia de resolución de TypeScript antes de Node. Hoy en día, todos los escenarios prácticos se resuelven mejor con nodenext or bundler, por lo que se elimina lo clásico para reducir la complejidad y los casos límite.

Obsoleto: AMD, UMD, SystemJS y module: none

Las siguientes module Estos valores ahora están obsoletos y prácticamente no reciben soporte.:

• amd
• umd
• systemjs
• none

Estos formatos fueron fundamentales en la era anterior al ESM.En el pasado, cuando los navegadores carecían de soporte nativo para módulos y los desarrolladores recurrían a AMD, UMD o SystemJS para suplir esta carencia, hoy en día ESM, junto con empaquetadores o mapas de importación, cubre prácticamente todos los casos de uso reales, y el concepto de "ninguno" nunca estuvo particularmente bien definido.

Si aún estás utilizando estos formatos de módulo heredadosLa recomendación es migrar hacia un destino que emita ESM y depender de un empaquetador o compilador alternativo para el empaquetado final, o permanecer en TypeScript 5.x hasta que se establezca un plan de migración. Como parte de esta limpieza, el antiguo amd-module La directiva también se elimina.

Obsoleto: baseUrl

La baseUrl Esta opción ha sido durante mucho tiempo una fuente de comportamiento extraño y difícil de depurar en la resolución de módulos.Muchos proyectos lo usaron simplemente como un prefijo para paths entradas, pero TypeScript también lo trató como una raíz de búsqueda general, lo que provocó importaciones como "someModule" resolver src/someModule.js inesperadamente cuando todo lo que el desarrollador pretendía era admitir alias personalizados como @app/*.

En 6.0, baseUrl está obsoleto y ya no se utilizará como raíz de búsqueda.No se ha requerido el mapeo de rutas baseUrl durante bastante tiempo, por lo que la migración recomendada es simplemente incorporar el prefijo en cada uno. paths entrada. Por ejemplo:

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

Solo en casos excepcionales en los que realmente usaste baseUrl como raíz de búsqueda genérica ¿Sería necesario reproducir ese comportamiento con una asignación de ruta general como esta?

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

Para la mayoría de los equipos, simplemente eliminar baseUrl y prefijos en línea en paths será más claro y seguro..

Interoperabilidad y rigor: esModuleInterop, allowSyntheticDefaultImportsy el ámbito alwaysStrict

TypeScript 6.0 también consolida lo que durante mucho tiempo ha sido el comportamiento de interoperabilidad predeterminado recomendado.Ya no puedes configurar esModuleInterop or allowSyntheticDefaultImports a falseEstas opciones se concibieron originalmente como opcionales para evitar que se estropearan los proyectos más antiguos, pero hoy en día, si se mantienen desactivadas, a menudo se producen problemas sutiles en tiempo de ejecución al mezclar CommonJS y ESM.

Con la interoperabilidad siempre habilitada, es posible que sea necesario actualizar ciertos patrones de importación.. Por ejemplo:

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

La alwaysStrict tampoco se puede establecer la bandera en false nunca más. TypeScript ahora asume la semántica del modo estricto de JavaScript en todos los aspectos, incluyendo cómo las palabras reservadas y this comportarse. Si tiene un código realmente antiguo que utiliza palabras reservadas como await or static Como identificadores, tendrás que cambiarles el nombre.

Obsoleto: outFile, espacio de nombres heredado module palabra clave e importación asserts

La --outFile Esta opción se elimina en la versión 6.0.Concatenar múltiples entradas en un único paquete JS es una tarea que se maneja mejor con herramientas como Webpack, Rollup, esbuild, Vite, Parcel o similares. TypeScript está reforzando la verificación de tipos y la generación de declaraciones en lugar de intentar ser un empaquetador.

El uso heredado de module Declarar espacios de nombres ahora es un error grave.Se permitía TypeScript en sus primeras etapas:

module Foo {
  export const bar = 10;
}

La sintaxis moderna y compatible utiliza namespace:

namespace Foo {
  export const bar = 10;
}

Este cambio es necesario para evitar conflictos con posibles futuras versiones de ECMAScript. module bloquesDeclaraciones de módulos ambientales como declare module "some-module" { ... } Siguen recibiendo todo nuestro apoyo.

Importar aserciones usando asserts también están obsoletos, porque la propuesta subyacente evolucionó en atributos de importación utilizando with. Código como:

import blob from "./data.json" asserts { type: "json" };

Debe migrarse al nuevo formulario.:

import blob from "./data.json" with { type: "json" };

Obsoleto: no-default-lib Referencias y listas de archivos de línea de comandos con tsconfig

La /// <reference no-default-lib="true" /> La directiva ya no es compatible.A menudo se malinterpretaba. Si necesita excluir la biblioteca predeterminada, utilice --noLib or --libReplacement en cambio, que expresan más claramente la intención a nivel de configuración.

Otra fuente de confusión de larga data es cómo tsc trata los argumentos de archivo explícitos cuando un tsconfig.json está presenteAnteriormente, corriendo tsc foo.ts En un directorio de este tipo, el archivo de configuración se ignoraría silenciosamente. En la versión 6.0, ese escenario produce un error explícito:

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

Si realmente quieres omitir la configuración y simplemente compilar un solo archivo con valores predeterminados, ahora puedes usar tsc --ignoreConfig foo.ts para dejar clara esa intención.

Preparándonos para TypeScript 7.0

TypeScript 6.0 está completo en cuanto a funcionalidades y se encuentra mayormente en modo de estabilización.Desde ahora hasta su disponibilidad general, el equipo prevé únicamente correcciones de errores críticos. Se publican versiones diarias con regularidad, y el equipo también distribuye versiones diarias de la próxima versión nativa (basada en Go) de TypeScript 7.0 junto con una extensión específica para VS Code que permite experimentar con el nuevo motor.

La hoja de ruta es intencionadamente estricta: se espera que la versión 7.0 siga a la 6.0 poco después.Por lo tanto, el ciclo de retroalimentación sobre las dificultades de actualización y los problemas de migración será breve. Si ve advertencias de obsolescencia en la versión 6.0, se recomienda encarecidamente abordarlas ahora en lugar de esperar a que la versión 7.0 obligue a ello.

El flujo de trabajo práctico para la mayoría de los equipos se ve así:: actualiza a TypeScript 6.0 RC, corrige tu types además rootDir, abordar las funciones obsoletas (o restringirlas temporalmente) "ignoreDeprecations": "6.0" mientras iteras), y ejecuta con --stableTypeOrdering Si necesitas comparar resultados o preparar pipelines de CI para el ordenamiento determinista de la versión 7.0. Una vez hecho esto, el cambio al compilador basado en Go debería percibirse como una mejora de rendimiento en lugar de una reescritura que rompa el equilibrio del código.

En conjunto, TypeScript 6.0 RC se centra menos en una sintaxis brillante y más en preparar el terreno.Velocidad nativa en la versión 7.0, configuraciones más limpias, valores predeterminados modernos y API estandarizadas como Temporal y las funciones integradas de ES2025 que facilitan la programación diaria. Si lo adoptas ahora, corriges los problemas y aprovechas los nuevos valores predeterminados, estarás en una posición mucho mejor cuando se lance el compilador nativo.