TypeScript 6.0 RC: característiques, canvis importants i com preparar-se

Inici » Pitó » TypeScript 6.0 RC: característiques, canvis importants i com preparar-se

TypeScript 6.0 ha arribat oficialment a la fita de Release Candidate (RC), i no és només una altra actualització incremental. Aquesta és l'última versió important que s'executa a la implementació de JavaScript de llarga data del compilador i el servei d'idiomes, just abans que el projecte passi a un motor totalment nou basat en Go a TypeScript 7.0. Només això fa que la versió 6.0 sigui una versió crucial: és el pont que s'ha de creuar abans que tot el que hi ha sota el capó canviï.

Pots començar a provar l'RC avui mateix instal·lant-lo des de npm amb:

npm install -D typescript@rc

La idea central darrere de TypeScript 6.0 és la preparació i l'alineacióAquesta versió suavitza el camí de la versió 5.9 a la 7.0, reduint els valors per defecte, desaprovant el bagatge històric i afegint algunes funcions específiques que reflecteixen el comportament futur o exposen les futures capacitats de JavaScript com ara Temporal, les API ES2025 i els mètodes "upsert" de Map. Pel camí, hi ha alguns ajustos subtils del sistema de tipus, nous indicadors de compilació i valors per defecte de configuració que afectaran absolutament els projectes reals, especialment al voltant de... types, rootDir, i rigor.

TypeScript 6.0 com a pont cap al 7.0 basat en Go

TypeScript 6.0 està dissenyat explícitament com la versió principal final de la base de codi JavaScript existent.L'equip de TypeScript ha estat reescrivint el compilador i el servei d'idiomes en un motor natiu en Go, aprofitant el rendiment natiu i el paral·lelisme de memòria compartida. Aquest nou motor debutarà com a TypeScript 7.0 i posteriors, i la 6.0 se situa just al davant com a etapa de transició.

La majoria dels canvis importants i les obsolescències de la versió 6.0 són per fer que la futura actualització a la versió 7.0 sigui viable.Les opcions que no es poden suportar de manera eficient a l'arquitectura nativa, els sistemes de mòduls antics i les peculiaritats de llarga data s'eliminen o es marquen clarament com a obsoletes amb una porta d'escapament: podeu definir "ignoreDeprecations": "6.0" en el seu tsconfig.json per suprimir els diagnòstics de desactivació a la versió 6.0. Però aquest indicador no us ajudarà a la versió 7.0; està previst que aquestes opcions desapareguin completament.

Si teniu la temptació d'"esperar la versió 7.0" abans de fer cap neteja de configuració, això és un parany.La 6.0 RC és la versió on se suposa que has d'arreglar el teu tsconfig, normalitzar els tipus i gestionar els indicadors obsolets. Fer dos salts gegants (5.x → 7.0) sempre farà més mal que anar de 5.x → 6.0 → 7.0 amb canvis més petits i controlats.

Què ha canviat des de la versió beta 6.0

Entre la versió beta i la RC, l'equip de TypeScript es va centrar principalment en alinear el comportament amb el futur motor 7.0., a més d'alguns ajustos específics en la comprovació de tipus i els tipatges DOM.

Un canvi important afecta la comprovació de tipus de les expressions de funció que es passen a les crides genèriques., especialment en contextos JSX. Quan s'invoquen funcions genèriques amb callbacks (per exemple, a React o altres components JSX), l'RC restringeix la inferència perquè reflecteixi amb més precisió el que farà la versió 7.0. A la pràctica, podeu observar que algunes crides que es basaven en la inferència implícita ara requereixen un argument de tipus explícit per mantenir la comprovació de tipus satisfactòria, però també detectareu més errors genuïns en el codi existent.

També s'ha ampliat la desaprovació de la sintaxi d'asserció d'importació.TypeScript ja advertia contra l'antic import ... assert {...} sintaxi en importacions estàtiques a causa del canvi de la proposta d'ECMAScript per importar atributs amb withAra, aquesta obsolescència també s'aplica a les importacions dinàmiques que utilitzen import() amb objectes d'asserció com ara import(..., { assert: {...}})La direcció és clara: passar a importar atributs a tot arreu.

Els tipus de biblioteques DOM s'han actualitzat per adaptar-se als estàndards actuals de la plataforma web., incloent-hi actualitzacions de les API relacionades amb el temporal en contextos web. Si esteu creant aplicacions de navegador, us beneficiareu d'escriptures més precises i de millors eines d'edició al voltant d'aquestes API més noves.

Menys sensibilitat al context per a funcions que no utilitzen mai this

TypeScript 6.0 introdueix un canvi subtil però molt pràctic en la manera com tracta les funcions sense una definició explícita. this ús durant la inferència de tipusHistòricament, les funcions amb paràmetres que no tenen tipus explícits es podien considerar "sensibles al context", és a dir, els seus paràmetres i this els tipus depenien d'on s'utilitzaven. Això afecta la inferència genèrica i pot provocar un comportament estrany depenent de la sintaxi de la funció.

Considereu un ajudant genèric que utilitza un parell de productor i 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,
});

Però amb la sintaxi del mètode, el comportament anterior podria ser sorprenent.La mateixa lògica, escrita com a mètodes, pot fallar quan les propietats es reordenen, perquè TypeScript omet les funcions "sensibles al context" en inferir arguments genèrics. Els mètodes tenen implícitament un this paràmetre, que els va situar en aquesta categoria sensible fins i tot si this mai no s'ha fet mai referència.

A la versió 6.0, funcions que mai no llegeixen this ara es tracten com a menys sensibles al context. Dit d'una altra manera, si el compilador veu que this Si no s'utilitza en absolut dins d'una funció, no penalitzarà aquesta funció durant la inferència. Això significa que la sintaxi del mètode i la sintaxi de les fletxes ara són molt més consistents en escenaris d'inferència genèrica, i el comportament estrany de "funciona en un ordre de propietats, falla en un altre" desapareix en aquests casos.

Aquest canvi millora la priorització dels candidats per a la inferència de tipus.: funcions sense un utilitzat this esdevenen fonts d'informació de més alta prioritat a l'hora d'inferir arguments de tipus com ara TL'efecte és menys misteriós unknown tipus i una inferència més estable entre refactors. Aquest treball va ser contribuït per Mateusz Burzyński.

Suport per a Node #/ importacions de subcamí

La funció "importacions de subrutes" de Node permet que els paquets defineixin àlies d'importació interns a través de imports camp en package.jsonAquests àlies simplifiquen les importacions evitant camins relatius profunds. Anteriorment, cada clau de subcamí havia de tenir com a mínim un segment després de la inicial. #, que era una petita però molesta limitació per a la gent acostumada a agrupar convencions com ara @/....

TypeScript 6.0 ara admet importacions de subcamins que comencen amb #/, alineant-se amb el comportament més recent del Node 20. Això vol dir que podeu utilitzar una configuració com ara:

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

Amb aquesta configuració, els mòduls dins del paquet (i fins i tot els consumidors) poden importar-se mitjançant un enllaç concís. #/... prefix en lloc de llargs camins relatius com ../../utils.js. TypeScript entén aquest patró quan --moduleResolution està establert a node20, nodenext, O bundler, reflectint la semàntica del Node modern. Aquesta millora va ser implementada pel col·laborador magic-akari.

Ús --moduleResolution bundler amb --module commonjs

Anteriorment, --moduleResolution bundler només es podia utilitzar amb --module esnext or preserveAmb la depreciació dels més antics node/node10 mode de resolució de mòduls, molts projectes necessitaven una ruta de migració que s'ajustés a la seva sortida actual de CommonJS.

TypeScript 6.0 ara permet combinar --moduleResolution bundler amb --module commonjsAquesta combinació sovint és un trampolí pràctic per a les bases de codi que encara emeten CommonJS però que s'orienten cap a fluxos de treball centrats en els agrupadors o cap a una lògica de resolució més nova. A partir d'aquí, els projectes poden planificar una migració a llarg termini cap a:

• module: "preserve" amb moduleResolution: "bundler" per a aplicacions web agrupades i configuracions similars, o
• module: "nodenext" per a entorns que tenen com a objectiu directe Node.js modern.

Aquest canvi és especialment rellevant per als equips que marxen moduleResolution: node darrere però encara no està a punt per adoptar completament la sortida de l'ESM. Et dóna una ruta per etapes en lloc d'un penya-segat.

La --stableTypeOrdering bandera per emular l'ordre de la versió 7.0

Una de les principals millores arquitectòniques que arriba a TypeScript 7.0 és la comprovació de tipus paral·lel.Executar diversos verificadors en paral·lel significa que es poden visitar diferents parts del programa en ordres diferents. Si els identificadors de tipus i l'ordre dels símbols depenen de l'ordre de visita, podeu acabar amb un ordre d'unió no determinista, un ordre de propietats i fins i tot diferències poc freqüents en els diagnòstics.

Les versions anteriors de TypeScript assignen identificadors de tipus interns basats en l'ordre de trobades.Aquests identificadors s'utilitzen per ordenar coses com ara tipus d'unió i propietats. És per això que les edicions aparentment inofensives, com ara introduir un nou const abans d'una funció existent: pot invertir l'ordre de les unions literals en emeses .d.ts fitxers o canviar la manera com s'imprimeixen alguns tipus a l'editor.

TypeScript 7.0 canvia a un ordre determinista i basat en contingut per als objectes interns.Cada tipus o símbol s'ordena segons la seva estructura, no segons l'ordre incidental de visita, de manera que el mateix programa produirà el mateix ordre de manera consistent independentment del paral·lelisme o l'ordre de compilació. Això elimina el misteri de "per què la meva unió es va invertir de sobte?".

Per ajudar-vos a comparar el comportament entre 6.0 i 7.0, l'RC introdueix --stableTypeOrderingQuan aquest indicador està habilitat, TypeScript 6.0 adopta el mateix algorisme determinista d'ordenació de tipus que utilitza la versió 7.0. El resultat són moltes menys diferències en els fitxers de declaració emesos i comparacions més predictibles entre les sortides de la versió 6.x i la 7.x.

Tanmateix, el determinisme no és gratuït. Habilitant --stableTypeOrdering pot alentir la comprovació de tipus fins a un 25% aproximadament, depenent de la base de codi. Està pensat com una ajuda de diagnòstic i migració, no com una configuració de rendiment permanent.

Si només veieu errors de tipus quan --stableTypeOrdering està activat, normalment significa que el codi anterior es basava en l'antic ordre quasi accidental de tipus perquè la inferència "simplement funcionés". Les correccions solen implicar fer que els tipus siguin explícits: afegir un argument de tipus a una crida genèrica problemàtica o anotar una variable amb una interfície específica en lloc de confiar completament en la inferència per a un objecte complex.

nou es2025 opcions de target i lib

TypeScript 6.0 afegeix una es2025 opció per a tots dos target i libTot i que l'ES2025 no introdueix una nova sintaxi bàsica en comparació amb els anys anteriors, sí que incorpora diverses API estandarditzades que anteriorment estaven protegides. esnext.

En orientar-se o incloent-hi es2025, obteniu tipificacions actualitzades per a les noves funcions integrades M'agrada RegExp.escape, i algunes API s'han traslladat fora de esnext en es2025Això inclou coses com Promise.try, ajudants d'iterador i extres Set mètodes que han assolit la plena maduresa d'especificació. Aquest treball ha estat aportat per Kenta Moriuchi.

La història més àmplia és que el valor per defecte target a la versió 6.0 ara fa un seguiment de l'any ECMAScript actual, que de moment et porta a ES2025 quan no especifiques un objectiu. Això s'adapta millor a la realitat dels entorns d'execució evergreen i les eines modernes.

Tipus integrats per a l'API Temporal

La tan esperada proposta Temporal ha arribat a la fase 3 i s'espera que substitueixi la infame Date API per a treballs seriosos de data/horaTypeScript 6.0 ara inclou tipificacions de primera classe per a Temporal, de manera que podeu començar a escriure codi basat en Temporal amb seguretat de tipus completa i compatibilitat amb l'editor.

Per habilitar els tipus temporals, podeu utilitzar --target esnext o configureu les vostres biblioteques explícitament mitjançant alguna cosa com ara:

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

O podeu optar només pel subconjunt temporal amb "esnext.temporal" si voleu una configuració més granular. Un cop habilitat, podeu escriure codi semblant a:

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

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

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

El tempor ja és compatible amb alguns sistemes d'execució i es pot omplir amb polietilè en d'altres., de manera que aquests tipus són realment utilitzables avui dia. Està sorgint documentació a MDN (amb alguns buits encara per omplir). Les tipificacions van ser aportades per l'usuari de GitHub Renegade334.

Suport Upsert: Map.getOrInsert i getOrInsertComputed

Els desenvolupadors de JavaScript han estat escrivint manualment patrons de tipus "check-then-set-then-get" a Map per anyUn patró típic comprova si una clau existeix, estableix un valor per defecte si no existeix i finalment retorna un valor: un patró estàndard que és fàcil d'equivocar-se o repetir-se a tot arreu.

La proposta "upsert" d'ECMAScript (ara fase 4) introdueix getOrInsert i getOrInsertComputed on Map i WeakMapTypeScript 6.0 afegeix compatibilitat de tipus per a aquests mètodes a esnext lib, de manera que podeu començar a escriure més upserts declaratius immediatament.

Amb getOrInsert, un patró prolix com aquest:

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

Es pot reduir a una sola línia:

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

El company getOrInsertComputed és ideal per a impagaments costosos—accepta una funció de retorn que només s'invoca si falta la clau. Aquesta funció de retorn pot fins i tot rebre la clau com a paràmetre, cosa que permet derivar el valor per defecte de la pròpia clau. Les escriptures de TypeScript capturen aquests comportaments amb precisió, gràcies de nou a les contribucions de Renegade334.

RegExp.escape i una construcció d'expressions regulars més segura

Si alguna vegada has concatenat cadenes proporcionades per l'usuari en una expressió regular, saps que primer has d'escapar els caràcters especials.—però la majoria de bases de codi o bé tornen a implementar l'escapament en un ajudant o bé ho obliden completament. La proposta d'escapament RegExp (ara etapa 4) ho estandarditza amb RegExp.escape.

TypeScript 6.0 exposa tipus per a RegExp.escape under the es2025 libAixò vol dir que quan incloeu o dirigiu ES2025, podeu escriure amb seguretat ajudants com ara:

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

Ja no cal una funció d'escapament manual, i TypeScript entendrà completament i comprovarà el tipus de l'API. Aquesta addició, com el treball objectiu ES2025, prové de Kenta Moriuchi.

dom La llibreria ara inclou API d'iteració i iteració asíncrona

Històricament, TypeScript va dividir el suport d'iteradors DOM en dom, dom.iterablei dom.asynciterableSi volguéssiu iterar sobre NodeList or HTMLCollection amb for...of, havies de recordar afegir dom.iterable en el seu "lib" configuració al costat domAixò va ser una font habitual de confusió, sobretot perquè tots els navegadors moderns admeten iterables i iterables asíncrons a les col·leccions DOM.

A TypeScript 6.0, lib.dom.iterable.d.ts i lib.dom.asynciterable.d.ts es fusionen eficaçment en lib.dom.d.tsAixò vol dir utilitzar "dom" alone ara et dóna un comportament iterable i asíncron iterable per defecte.

Encara pots esmentar dom.iterable i dom.asynciterable en el seu tsconfig, però aquests fitxers ara són shells buits. Si la configuració anterior tenia aquest aspecte:

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

Pots simplificar amb seguretat a només "dom", i iteració sobre col·leccions DOM com ara document.querySelectorAll("div") encara farà la comprovació de tipus:

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

Aquesta és una petita però benvinguda neteja que alinea la biblioteca DOM per defecte amb la realitat dels navegadors actuals i elimina un altre problema de la configuració del projecte.

Valors per defecte, obsoletes i canvis importants a TypeScript 6.0

Més enllà de les API brillants, la versió 6.0 fa alguns dels canvis més teòrics als valors predeterminats de TypeScript des de la versió 1.0.Aquests canvis reflecteixen l'ecosistema actual de JavaScript: temps d'execució perennes, ESM com a línia de base, ús generalitzat de paquets i una forta aposta per la tipificació i el rendiment estrictes.

L'equip destaca algunes tendències generals que sustenten aquestes decisionsL'ES5 i els navegadors veritablement antics gairebé han desaparegut; els sistemes de mòduls AMD/UMD són de nicho; gairebé tot es distribueix com a mòduls ara; la tipificació estricta és la norma; i el rendiment ha de mantenir-se al capdavant, sobretot perquè la versió 7.0 porta la comprovació paral·lela.

Com a resultat, TypeScript 6.0 i 7.0 s'estan configurant amb valors predeterminats moderns i menys "vàlvules d'escapament heretades".Per a la versió 6.0 RC, podeu silenciar temporalment les obsoletes configurant "ignoreDeprecations": "6.0" en el seu tsconfig, però aquestes opcions no existiran a la versió 7.0. Alguns ajustaments es poden automatitzar amb eines com l'experimental ts5to6 codemod, que pot ajudar a reescriure coses com ara baseUrl i rootDir configuracions al llarg d'un projecte.

Dos ajustaments que molts projectes necessitaran immediatament

Tot i que hi ha una llarga llista de versions obsoletes, és probable que dos canvis de configuració afectin el nombre més gran de bases de codi.:

• Estableix explícitament el types formació (molt sovint més el vostre marc de proves). Sense això, perdreu els tipus d'ambient inclosos automàticament de @types/*.
• Establit explícitament rootDir (comunament "./src") si us heu basat en l'antiga "inferència d'arrel comuna". Altrament, l'estructura del fitxer emès podria canviar de maneres subtils.

Símptomes de desaparició types inclouen una allau d'errors sobre globals com ara process, fs, path, O describe ser indefinitSímptomes d'un canvi rootDir es tracta més de camins de sortida que guanyen inesperadament un extra src segment (per exemple dist/src/index.js en lloc de dist/index.js).

Valors per defecte actualitzats per a projectes moderns

Diverses opcions del compilador ara tenen nous valors per defecte que coincideixen amb la manera com es compilen realment la majoria de les aplicacions noves.:

• strict ara per defecte és trueEl mode estricte ja no és un luxe opcional; és la base. Si abans depeníeu d'un comportament no estricte, haureu de definir-lo explícitament. "strict": false (encara que et perdràs una gran categoria de comprovacions de seguretat).
• module ara per defecte és esnext, reflectint que ESM és el format de mòdul dominant i que funciona millor amb bundlers i Node modern.
• target per defecte s'utilitza l'any ECMAScript actual (actualment ES2025), reconeixent que la majoria de desplegaments es dirigeixen a entorns perennes o passen per un agrupador que pot reduir encara més el nivell quan realment sigui necessari.
• noUncheckedSideEffectImports és ara true per defecte, ajudant-vos a detectar errors tipogràfics o camins incorrectes en importacions que s'inclouen només per efectes secundaris.
• libReplacement per defecte false, evitant una sèrie de resolucions de mòduls fallides addicionals i una sobrecàrrega de vigilància fins que un projecte opti explícitament per comportaments de biblioteca especialitzats.

Si algun d'aquests nous valors per defecte trenca la compilació, tots es poden anul·lar explícitament a tsconfig.jsonPerò la intenció és que els nous projectes "simplement facin el que és correcte" sense configuració addicional.

rootDir ara per defecte és el directori de configuració

Anteriorment, si no especificaves rootDir, TypeScript va intentar inferir una arrel font comuna basat en tots els fitxers no declarats del programa. Això va dificultar el raonament sobre els límits del projecte i va requerir escanejar moltes rutes de fitxer només per decidir on s'havia d'arrelar emit.

A TypeScript 6.0, el valor per defecte rootDir és simplement el directori que conté tsconfig.jsonEl comportament d'inferència antic només s'aplica quan executeu tsc a la línia d'ordres sense cap tsconfig en absolut.

Aquest canvi significa que els projectes amb fitxers font més profunds que el directori de configuració haurien de definir explícitament rootDirUna configuració habitual seria:

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

Si la vostra configuració fa referència a fitxers superiors a tsconfig ubicació, també haureu d'ampliar rootDir en conseqüència, Per exemple "rootDir": "../src" per a directoris font compartits.

types ara per defecte és una matriu buida

Aquest és probablement el canvi més impactant per a projectes del món real.Històricament, si no ho heu especificat types in compilerOptions, TypeScript inclouria automàticament tot el que hi ha a sota node_modules/@typesAixò era convenient, però també car i fràgil: els repositoris moderns sovint utilitzen centenars de @types paquets de manera transitiva.

A TypeScript 6.0, types per defecte [], és a dir, no es carreguen automàticament paquets de tipus ambientAra opteu explícitament per als entorns globals que realment necessiteu, per exemple:

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

Això pot reduir entre un 20 i un 50% els temps de construcció en alguns projectes., perquè el compilador ja no ha de rastrejar tots els fitxers de declaració de @typesSi realment voleu el comportament antic de "carregar-ho tot", podeu especificar:

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

Si de sobte veieu errors com ara “No es pot trobar el nom 'process'” o “No es pot trobar el mòdul 'fs'”, aquesta és la teva indicació per afegir node (i qualsevol altre tipus de prova/temps d'execució en què confieu) al vostre types matriu.

Obsolet: target: es5 i --downlevelIteration

Ara es desaconsella orientar-se a ES5Amb tots els navegadors rellevants distribuint ES2015+ durant anys i Internet Explorer retirat, la sortida d'ES5 ja no es considera que valgui la pena la complexitat interior de TypeScript. L'objectiu menys compatible a partir d'ara és ES2015. Si realment heu de distribuir ES5, la recomanació és utilitzar un transpilador extern (com Babel o un pipeline bundler) ja sigui a la vostra font TS o a la sortida de TS.

La --downlevelIteration La bandera també està obsoleta, perquè el seu únic cas d'ús significatiu era ajustar el comportament d'emissió per a objectius ES5. A TypeScript 6.0, la configuració downlevelIteration en absolut produirà un error de desaprovació. Si esteu utilitzant ES2015 o una versió més recent, la bandera no ha tingut mai cap efecte de totes maneres.

Obsolet: --moduleResolution node i llegat classic

La node (aka node10) el mode de resolució de mòduls està obsoletHa modelat el comportament del Node 10 però no coincideix amb l'ESM i la semàntica de resolució del Node modern. Els projectes haurien de migrar a qualsevol dels dos. nodenext (per a objectius directes de node) o bundler (per a entorns basats en paquets com ara aplicacions web o Bun).

L'original moduleResolution: classic L'estratègia també s'ha eliminatAquesta va ser la història de TypeScript prèvia a la resolució de Node. Avui dia, tots els escenaris pràctics estan millor servits per nodenext or bundler, de manera que el clàssic ha desaparegut per reduir la complexitat i els casos límit.

Obsolet: AMD, UMD, SystemJS i module: none

El següent module els valors ara estan obsolets i pràcticament no són compatibles:

• amd
• umd
• systemjs
• none

Aquests formats van ser crítics en l'era anterior a l'ESM, quan els navegadors no tenien suport de mòduls nadius i els desenvolupadors es basaven en AMD, UMD o SystemJS per omplir el buit. Avui dia, ESM més agrupadors o mapes d'importació gestionen pràcticament tots els casos d'ús reals, i "cap" mai no va estar particularment ben definit.

Si encara esteu orientant-vos a aquests formats de mòduls antics, la recomanació és migrar cap a un objectiu emissor d'ESM i confiar en un agrupador o compilador alternatiu per a l'empaquetament final, o bé romandre a TypeScript 5.x fins que hi hagi un pla de migració establert. Com a part d'aquesta neteja, l'antic amd-module La directiva també s'ha abandonat.

Obsolet: baseUrl

La baseUrl L'opció ha estat durant molt de temps una font de comportament de resolució de mòduls estrany i difícil de depurar.Molts projectes l'utilitzaven purament com a prefix per a paths entrades, però TypeScript també la tractava com una arrel de cerca general, provocant importacions com ara "someModule" resoldre a src/someModule.js inesperadament quan tot el que el desenvolupador volia era donar suport a àlies personalitzats com ara @app/*.

En 6.0, baseUrl està obsolet i ja no s'utilitzarà com a arrel de cercaNo cal el mapatge de camins baseUrl durant força temps, de manera que la migració recomanada és simplement plegar el prefix a cada paths entrada. Per exemple:

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

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

Només en casos excepcionals en què realment has utilitzat baseUrl com a arrel de cerca genèrica hauríeu de reproduir aquest comportament amb un mapatge de camins general com ara:

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

Per a la majoria d'equips, simplement eliminant baseUrl i prefixos en línia paths serà més clar i més segur.

Interoperabilitat i rigor: esModuleInterop, allowSyntheticDefaultImportsi alwaysStrict

TypeScript 6.0 també bloqueja el que durant molt de temps ha estat el comportament d'interoperabilitat per defecte recomanat.Ja no podeu configurar esModuleInterop or allowSyntheticDefaultImports a falseAquestes opcions eren originalment opcionals per evitar trencar projectes antics, però mantenir-les desactivades avui dia sovint comporta problemes subtils d'execució quan es barregen CommonJS i ESM.

Amb la interoperabilitat sempre habilitada, pot ser necessari actualitzar certs patrons d'importació.. Per exemple:

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

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

La alwaysStrict la bandera tampoc es pot definir com a false ja. TypeScript ara assumeix la semàntica del mode estricte de JavaScript en tots els àmbits, incloent-hi com les paraules reservades i this comporta't. Si tens codi realment antic que utilitzava paraules reservades com ara await or static com a identificadors, haureu de canviar-los el nom.

Obsolet: outFile, espai de noms antic module paraula clau i importació asserts

La --outFile l'opció s'ha eliminat a la versió 6.0La concatenació de diverses entrades en un sol paquet JS és una tasca que es gestiona millor amb Webpack, Rollup, esbuild, Vite, Parcel o eines similars. TypeScript està redoblant la comprovació de tipus i l'emissió de declaracions en lloc d'intentar ser un agrupador.

L'ús heretat de module declarar espais de noms ara és un error greu. Es permetia l'escriptura primerenca de TypeScript:

module Foo {
  export const bar = 10;
}

La sintaxi moderna i compatible utilitza namespace:

namespace Foo {
  export const bar = 10;
}

Aquest canvi és necessari per evitar xocar amb possibles futurs ECMAScript. module blocsDeclaracions de mòduls ambientals com ara declare module "some-module" { ... } segueixen sent totalment recolzats.

Importa assercions utilitzant asserts també estan desaprovats, perquè la proposta subjacent va evolucionar cap a atributs d'importació utilitzant withCodi com ara:

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

S'hauria de migrar al nou formulari:

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

Obsolet: no-default-lib referències i llistes de fitxers de línia d'ordres amb tsconfig

La /// <reference no-default-lib="true" /> la directiva ja no és compatibleSovint s'entenia malament. Si cal excloure la biblioteca per defecte, utilitzeu --noLib or --libReplacement en canvi, que expressen més clarament la intenció a nivell de configuració.

Una altra font de confusió de llarga durada és com tsc tracta arguments de fitxer explícits quan un tsconfig.json està presentAnteriorment, corrent tsc foo.ts en un directori d'aquest tipus ignoraria silenciosament el fitxer de configuració. A la versió 6.0, aquest escenari produeix un error explícit:

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

Si realment voleu ometre la configuració i compilar un sol fitxer amb els valors per defecte, ara podeu utilitzar tsc --ignoreConfig foo.ts per deixar clara aquesta intenció.

Preparant-se per a TypeScript 7.0

TypeScript 6.0 té totes les funcions i està majoritàriament en mode d'estabilització.Des d'aquí fins a la disponibilitat general, l'equip només espera correccions d'errors crítics. Les compilacions nocturnes es publiquen regularment i l'equip també envia versions nocturnes del proper TypeScript 7.0 natiu (basat en Go) juntament amb una extensió VS Code dedicada per experimentar amb el nou motor.

La guia és intencionadament ajustada: s'espera que la versió 7.0 segueixi la versió 6.0 poc després., de manera que el bucle de retroalimentació sobre el dolor d'actualització i els problemes de migració serà curt. Si veieu avisos de desactivació a la versió 6.0, la recomanació més ferma és solucionar-los ara en comptes d'esperar fins que la versió 7.0 forci el problema.

El flux de treball pràctic per a la majoria d'equips és aquest: actualitza a TypeScript 6.0 RC, arregla el teu types i rootDir, abordar les obsoletes (o amagar-les temporalment) "ignoreDeprecations": "6.0" mentre iteres), i executa amb --stableTypeOrdering si necessiteu comparar sortides o preparar canals de CI per a l'ordenació determinista de la versió 7.0. Un cop fet això, el salt al compilador basat en Go hauria de semblar una millora del rendiment en lloc d'una reescriptura inesgotable.

En conjunt, TypeScript 6.0 RC tracta menys de sintaxi brillant i més de preparar l'escenari.: velocitat nativa a la versió 7.0, configuracions més netes, valors per defecte moderns i API estandarditzades com ara les funcions integrades de Temporal i ES2025 que faciliten la codificació diària. Si ho adopteu ara, arregleu els elements sorollosos i us centreu en els nous valors per defecte, estareu en una posició molt millor quan arribi el compilador natiu.