TypeScript 6.0 RC: funksjoner, viktige endringer og hvordan du forbereder deg

Home » Python » TypeScript 6.0 RC: funksjoner, viktige endringer og hvordan du forbereder deg

TypeScript 6.0 har offisielt nådd milepælen Release Candidate (RC), og det er ikke bare nok en trinnvis oppdatering. Dette er den siste store versjonen som kjører på den langvarige JavaScript-implementeringen av kompilatoren og språktjenesten, rett før prosjektet hopper til en helt ny, Go-basert motor i TypeScript 7.0. Det alene gjør 6.0 til en sentral utgivelse: det er broen du er ment å krysse før alt under panseret endres.

Du kan begynne å prøve RC-en i dag ved å installere den fra npm med:

npm install -D typescript@rc

Kjerneideen bak TypeScript 6.0 er forberedelse og justeringDenne versjonen jevner ut veien fra 5.9 til 7.0, strammer inn standardverdier, avskriver historisk bagasje og legger til noen målrettede funksjoner som enten speiler fremtidig atferd eller eksponerer kommende JavaScript-funksjoner som Temporal, ES2025 API-er og Map "upsert"-metoder. Underveis er det noen subtile justeringer av typesystemer, nye kompilatorflagg og konfigurasjonsstandarder som absolutt vil påvirke virkelige prosjekter – spesielt rundt types, rootDir, og strenghet.

TypeScript 6.0 som broen til den Go-baserte 7.0

TypeScript 6.0 er eksplisitt utformet som den siste hovedutgivelsen på den eksisterende JavaScript-kodebasen.TypeScript-teamet har omskrevet kompilatoren og språktjenesten til en motor nativ en Go, og utnytter innebygd ytelse og parallellisme mellom delt minne. Den nye motoren vil debutere som TypeScript 7.0 og nyere, og 6.0 ligger rett foran den som en overgangsfase.

De fleste av de siste endringene og avskrivningene i 6.0 er der for å gjøre din fremtidige 7.0-oppgradering overlevelig.Alternativer som ikke kan støttes effektivt i den innebygde arkitekturen, gamle modulsystemer og langvarige særegenheter blir enten fjernet eller tydelig merket som utdatert med en rømningsluke: du kan angi "ignoreDeprecations": "6.0" i tsconfig.json for å undertrykke diagnostikk for avskrivninger i 6.0. Men det flagget vil ikke hjelpe deg i 7.0 – disse alternativene er planlagt å forsvinne helt.

Hvis du er fristet til å «vente på 7.0» før du rydder opp i konfigurasjonen, er det en felle.6.0 RC er versjonen der du skal fikse tsconfig, normalisere typer og håndtere utdaterte flagg. Å gjøre to gigantiske hopp (5.x → 7.0) vil alltid skade mer enn å gå 5.x → 6.0 → 7.0 med mindre, kontrollerte endringer.

Hva har endret seg siden betaversjonen 6.0

Mellom betaversjonen og RC fokuserte TypeScript-teamet hovedsakelig på å tilpasse atferden til den fremtidige 7.0-motoren., pluss noen målrettede justeringer i typekontroll og DOM-typinger.

En viktig endring påvirker typekontroll av funksjonsuttrykk som sendes til generiske kall, spesielt i JSX-kontekster. Når generiske funksjoner kalles med tilbakekallinger (for eksempel i React eller andre JSX-komponenter), strammer RC inn inferensen slik at den mer nøyaktig gjenspeiler hva 7.0 vil gjøre. I praksis kan du legge merke til at noen kall som var avhengige av implisitt inferens nå krever et eksplisitt typeargument for å holde typesjekken i gang, men du vil også oppdage flere ekte feil i eksisterende kode.

Avskrivning av importdeklarasjonssyntaks er også utvidetTypeScript advarte allerede mot den gamle import ... assert {...} syntaks i statiske importer på grunn av at ECMAScript-forslaget skifter til importattributter med withNå gjelder denne avskrivningen også for dynamisk import ved bruk av import() med påstandsobjekter som import(..., { assert: {...}})Retningen er klar: gå over til å importere attributter overalt.

DOM-bibliotektyper er oppdatert for å samsvare med gjeldende standarder for nettplattformer., inkludert oppdateringer til de temporal-relaterte API-ene i nettkontekster. Hvis du bygger nettleserapper, drar du nytte av mer nøyaktige skrivemåter og bedre redigeringsverktøy rundt disse nyere API-ene.

Mindre kontekstfølsomhet for funksjoner som aldri brukes this

TypeScript 6.0 introduserer en subtil, men svært praktisk endring i hvordan den behandler funksjoner uten en eksplisitt this bruk under typeinferensHistorisk sett kunne funksjoner med parametere som mangler eksplisitte typer bli ansett som «kontekstuelt sensitive», som betyr at parameterne deres og this Typer var avhengige av hvor de ble brukt. Dette påvirker generisk inferens og kan føre til merkelig oppførsel avhengig av funksjonssyntaks.

Tenk deg en generisk hjelper som bruker et produsent- og forbrukerpar:

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,
});

Men med metodesyntaks kan den forrige oppførselen være overraskendeDen samme logikken, skrevet som metoder, kan feile når egenskaper omordnes, fordi TypeScript hoppet over "kontekstsensitive" funksjoner når de utleder generiske argumenter. Metoder har implisitt en this parameter, som plasserte dem i den sensitive kategorien selv om this ble faktisk aldri referert til.

I 6.0, funksjoner som aldri leser this behandles nå som mindre kontekstsensitive. Sagt på en annen måte, hvis kompilatoren ser at this ikke brukes i det hele tatt inne i en funksjon, vil den ikke straffe den funksjonen under inferens. Det betyr at metodesyntaks og pilsyntaks nå er mye mer konsistente i generiske inferensscenarier, og den rare «fungerer i én egenskapsrekkefølge, feiler i en annen»-oppførselen forsvinner i disse tilfellene.

Denne endringen forbedrer prioriteringen av kandidater for typeinferens: funksjoner uten en brukt this bli informasjonskilder med høyere prioritet når man utleder typeargumenter som TEffekten er mindre mystisk unknown typer og mer stabil inferens på tvers av refaktorer. Dette arbeidet ble bidratt av Mateusz Burzyński.

Støtte for Node #/ import av underbaner

Nodens funksjon for «import av underbaner» lar pakker definere interne importaliaser via imports felt i package.jsonDisse aliasene forenkler import ved å unngå dype relative stier. Tidligere måtte hver understi-nøkkel ha minst ett segment etter den første #, som var en liten, men irriterende begrensning for folk som pleide å samle konvensjoner som @/....

TypeScript 6.0 støtter nå import av underbaner som begynner med #/, i samsvar med den nyere Node 20-oppførselen. Dette betyr at du kan bruke en konfigurasjon som:

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

Med dette oppsettet kan moduler i pakken – og til og med forbrukere – importere via en kortfattet #/... prefiks i stedet for lange relative stier som ../../utils.jsTypeScript forstår dette mønsteret når --moduleResolution er satt til node20, nodenexteller bundler, som speiler semantikken til moderne Node. Denne forbedringen ble implementert av bidragsyteren magic-akari.

Ved hjelp av --moduleResolution bundler med --module commonjs

Tidligere --moduleResolution bundler kunne bare brukes med --module esnext or preserveMed nedverdigelsen av den eldre node/node10 moduloppløsningsmodus, trengte mange prosjekter en migreringssti som passet deres nåværende CommonJS-utdata.

TypeScript 6.0 tillater nå kombinasjon --moduleResolution bundler med --module commonjsDenne kombinasjonen er ofte et praktisk springbrett for kodebaser som fortsatt bruker CommonJS, men som beveger seg mot bundler-sentriske arbeidsflyter eller nyere løsningslogikk. Derfra kan prosjekter planlegge en langsiktig migrering til enten:

• module: "preserve" med moduleResolution: "bundler" for medfølgende nettapper og lignende oppsett, eller
• module: "nodenext" for miljøer som er direkte rettet mot moderne Node.js.

Denne endringen er spesielt relevant for lag som forlater moduleResolution: node bak men ikke klar til å fullt ut omfavne ESM-utdata ennå. Det gir deg en faset rute i stedet for en stup.

Ocuco --stableTypeOrdering flagg for å emulere 7.0-rekkefølge

En av de største arkitektoniske oppgraderingene som kommer i TypeScript 7.0 er parallell typekontroll.Å kjøre flere kontrollører parallelt betyr at forskjellige deler av programmet kan besøkes i ulik rekkefølge. Hvis type-ID-er og symbolrekkefølge avhenger av besøksrekkefølgen, kan du ende opp med ikke-deterministisk unionsrekkefølge, egenskapsrekkefølge og til og med sjeldne forskjeller i diagnostikk.

Eldre TypeScript-versjoner tilordner interne type-ID-er basert på møterekkefølgeDisse ID-ene brukes deretter til å sortere ting som unionstyper og egenskaper. Det er derfor tilsynelatende harmløse redigeringer – som å introdusere en ny const før en eksisterende funksjon – kan snu rekkefølgen på litterale foreninger i utsendte .d.ts filer, eller endre hvordan noen typer skrives ut i editoren din.

TypeScript 7.0 bytter til en deterministisk, innholdsbasert rekkefølge for interne objekterHver type eller hvert symbol sorteres etter struktur, ikke den tilfeldige rekkefølgen av besøk, slik at det samme programmet konsekvent vil produsere samme rekkefølge uavhengig av parallellisme eller kompileringsrekkefølge. Det eliminerer mysteriet med «hvorfor snudde foreningen min plutselig?».

For å hjelpe deg med å sammenligne atferd mellom 6.0 og 7.0, introduserer RC --stableTypeOrderingNår dette flagget er aktivert, bruker TypeScript 6.0 den samme deterministiske typeordringsalgoritmen som 7.0 bruker. Resultatet er langt færre forskjeller i sendte deklarasjonsfiler og mer forutsigbare sammenligninger mellom 6.x- og 7.x-utdata.

Determinisme er imidlertid ikke gratis. Aktiverer --stableTypeOrdering kan redusere hastigheten på typesjekking med opptil omtrent 25 %, avhengig av kodebasen din. Det er ment som et diagnostisk og migreringshjelpemiddel, ikke en permanent ytelsesinnstilling.

Hvis du bare ser skrivefeil når --stableTypeOrdering er slått på, betyr det vanligvis at den forrige koden din var avhengig av den gamle kvasi-tilfeldige rekkefølgen av typer for at inferensen «bare skulle fungere». Rettelser innebærer vanligvis å gjøre typer eksplisitte – legge til et typeargument i et problematisk generisk kall, eller annotere en variabel med et spesifikt grensesnitt i stedet for å stole utelukkende på inferens for et komplekst objekt.

Ny es2025 target- og lib-alternativer

TypeScript 6.0 legger til en es2025 alternativ for begge target og libSelv om ES2025 ikke introduserer ny kjernesyntaks sammenlignet med tidligere år, inkluderer den flere standardiserte API-er som tidligere var begrenset til esnext.

Ved å målrette eller inkludere es2025, får du oppdaterte skrivinger for nye innebygde funksjoner i likhet med RegExp.escape, og noen API-er er flyttet ut av esnext inn es2025Det inkluderer ting som Promise.try, iteratorhjelpere og ekstra Set metoder som har nådd full spesifikasjonsmodenhet. Dette arbeidet ble bidratt av Kenta Moriuchi.

Den større historien er at standardinnstillingen target i 6.0 sporer nå gjeldende ECMAScript-år, som for øyeblikket effektivt sett lander deg på ES2025 når du ikke spesifiserer et mål. Det samsvarer bedre med virkeligheten med eviggrønne kjøretider og moderne verktøy.

Innebygde typer for Temporal API

Det lenge etterlengtede Temporal-forslaget har nådd fase 3 og forventes å erstatte det beryktede Date API for seriøst dato-/tidsarbeidTypeScript 6.0 leverer nå førsteklasses typing for Temporal, slik at du kan begynne å skrive Temporal-basert kode med full typesikkerhet og redigeringsstøtte.

For å aktivere Temporal-typer kan du bruke --target esnext eller konfigurer bibliotekene dine eksplisitt via noe sånt som:

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

Eller du kan velge bare det tidsmessige delsettet med "esnext.temporal" hvis du ønsker en mer detaljert konfigurasjon. Når den er aktivert, kan du skrive kode som følger:

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 støttes allerede i noen kjøretider og kan polyfylles i andre, så disse typene er virkelig brukbare i dag. Dokumentasjon på MDN er i ferd med å utvikles (med noen hull som fortsatt blir fylt). Typingene ble bidratt av GitHub-brukeren Renegade334.

Upsert-støtte: Map.getOrInsert og getOrInsertComputed

JavaScript-utviklere har manuelt skrevet «sjekk-sett-sett-hent»-mønstre på Map I mange årEt typisk mønster sjekker om en nøkkel finnes, setter en standardverdi hvis ikke, og returnerer til slutt en verdi – en standardverdi som er lett å ta feil av eller gjenta overalt.

ECMAScript-forslaget om «upsert» (nå trinn 4) introduserer getOrInsert og getOrInsertComputed on Map og WeakMapTypeScript 6.0 legger til typestøtte for disse metodene i esnext lib, slik at du kan begynne å skrive flere deklarative upserts med en gang.

Med getOrInsert, et ordrikt mønster som dette:

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

Kan skjules til én linje:

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

Kameraten getOrInsertComputed er ideell for dyre mislighold– den krever et tilbakekallingssystem som bare kalles hvis nøkkelen mangler. Dette tilbakekallingsystemet kan til og med motta nøkkelen som en parameter, slik at du kan utlede standardverdien fra selve nøkkelen. TypeScripts typinger fanger opp disse atferdene presist, igjen takket være bidrag fra Renegade334.

RegExp.escape og tryggere regex-bygging

Hvis du noen gang har sammenkoblet brukerangitte strenger til et regulært uttrykk, vet du at du først skal bruke escape-tegn for spesialtegn.– men de fleste kodebaser implementerer enten escape på nytt i en hjelper eller glemmer det helt. RegExp Escaping-forslaget (nå trinn 4) standardiserer dette med RegExp.escape.

TypeScript 6.0 eksponerer typer for RegExp.escape under es2025 libDet betyr at når du retter deg mot eller inkluderer ES2025, kan du trygt skrive hjelpere som:

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

Ikke lenger behov for en håndrullet rømningsfunksjon, og TypeScript vil forstå og typesjekke API-et fullt ut. Dette tillegget, i likhet med ES2025-målarbeidet, kommer fra Kenta Moriuchi.

dom lib inkluderer nå iterasjons- og asynkrone iterasjons-API-er

Historisk sett delte TypeScript DOM-iteratorstøtte inn i dom, dom.iterableog dom.asynciterableHvis du ville iterere over NodeList or HTMLCollection med for...of, du måtte huske å legge til dom.iterable i "lib" konfigurasjon ved siden av domDette var en vanlig kilde til forvirring, spesielt siden alle moderne nettlesere støtter iterabler og asynkrone iterabler på DOM-samlinger.

I TypeScript 6.0, lib.dom.iterable.d.ts og lib.dom.asynciterable.d.ts er effektivt slått sammen til lib.dom.d.tsDet betyr å bruke "dom" alone gir deg nå itererbar og asynkron itererbar oppførsel som standard.

Du kan fortsatt nevne dom.iterable og dom.asynciterable i tsconfig, men disse filene er nå tomme skall. Hvis den forrige konfigurasjonen din så slik ut:

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

Du kan trygt forenkle til bare "dom", og iterasjon over DOM-samlinger som document.querySelectorAll("div") vil fortsatt typesjekke:

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

Dette er en liten, men velkommen opprydding som justerer standard DOM-lib'en med virkeligheten i nåværende nettlesere og fjerner enda en feil fra prosjektoppsettet.

Standardverdier, avskrivninger og endringer som ikke fungerer i TypeScript 6.0

Utover skinnende API-er, gjør 6.0 noen av de mest meningsfulle endringene i TypeScripts standardinnstillinger siden 1.0.Disse endringene gjenspeiler det nåværende JavaScript-økosystemet: eviggrønne kjøretider, ESM som grunnlinje, utbredt bruk av bundlere og en sterk appetitt for streng skriving og ytelse.

Teamet fremhever noen brede trender som ligger til grunn for disse beslutningeneES5 og virkelig eldre nettlesere er nesten borte; AMD/UMD-modulsystemer er nisjemodeller; nesten alt sendes som moduler nå; streng skriving er normen; og ytelsen må forbli i sentrum, spesielt siden 7.0 bringer parallell sjekking.

Som et resultat blir TypeScript 6.0 og 7.0 formet med moderne standardinnstillinger og færre «gamle rømningsventiler».For 6.0 RC kan du midlertidig deaktivere avskrivninger ved å angi "ignoreDeprecations": "6.0" i tsconfig, men disse alternativene vil ikke finnes i 7.0. Noen justeringer kan automatiseres med verktøy som den eksperimentelle ts5to6 codemod, som kan hjelpe med å omskrive ting som baseUrl og rootDir konfigurasjoner på tvers av et prosjekt.

To justeringer mange prosjekter vil trenge umiddelbart

Selv om det er en lang avskrivningsliste, er det sannsynlig at to konfigurasjonsendringer vil påvirke flest kodebaser.:

• Angi eksplisitt types matrise (svært ofte pluss testrammeverket ditt). Uten dette vil du miste automatisk inkluderte omgivelsestyper fra @types/*.
• Eksplisitt satt rootDir (vanligvis "./src") Hvis du stolte på den gamle «fellesrot-inferensen», kan den utsendte filstrukturen endre seg på subtile måter.

Symptomer på savnet types inkluderer en flom av feil om globaler som process, fs, patheller describe å være udefinertSymptomer på en endret rootDir handler mer om utgangsstier som uventet får en ekstra src segment (for eksempel dist/src/index.js istedenfor dist/index.js).

Oppdaterte standardinnstillinger for moderne prosjekter

Flere kompilatoralternativer har nå nye standardverdier som samsvarer med hvordan de fleste nye apper faktisk bygges:

• strict nå standardinnstillingen er trueStreng modus er ikke lenger en luksus å velge mellom; det er grunnlinjen. Hvis du tidligere var avhengig av ikke-streng oppførsel, må du eksplisitt angi "strict": false (selv om du vil gå glipp av en stor kategori med sikkerhetskontroller).
• module nå standardinnstillingen er esnext, noe som gjenspeiler at ESM er det dominerende modulformatet og fungerer best med bundlere og moderne Node.
• target bruker standardinnstillingen for gjeldende ECMAScript-år (effektivt ES2025 akkurat nå), og erkjenner at de fleste implementeringer er rettet mot eviggrønne miljøer eller går gjennom en pakkeløsning som kan nedgradere ytterligere når det virkelig er nødvendig.
• noUncheckedSideEffectImports er nå true som standard, som hjelper deg med å fange opp skrivefeil eller dårlige stier i importer som kun er inkludert for bivirkninger.
• libReplacement standardinnstilling false, noe som unngår en rekke ekstra mislykkede modulløsninger og overvåkingskostnader inntil et prosjekt eksplisitt velger spesialisert lib-atferd.

Hvis noen av disse nye standardverdiene ødelegger bygget ditt, kan de alle overstyres eksplisitt i tsconfig.jsonMen hensikten er at nye prosjekter skal «bare gjøre det rette» uten ekstra konfigurasjon.

rootDir nå standardinnstillingen er konfigurasjonskatalogen

Tidligere, hvis du ikke spesifiserte rootDir, TypeScript prøvde å utlede en felles kilderot basert på alle ikke-deklarasjonsfiler i programmet. Det gjorde det vanskeligere å resonnere rundt prosjektgrenser og krevde skanning av mange filstier bare for å bestemme hvor emit skulle rotfestes.

I TypeScript 6.0 er standardinnstillingen rootDir er rett og slett katalogen som inneholder tsconfig.jsonDen gamle slutningsoppførselen gjelder bare når du kjører tsc på kommandolinjen uten noen tsconfig det hele tatt.

Denne endringen betyr at prosjekter med kildefiler dypere enn konfigurasjonskatalogen eksplisitt skal angi rootDirEt vanlig oppsett ville være:

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

Hvis konfigurasjonen din refererer til filer over tsconfig plassering, må du også utvide rootDir tilsvar, Eksempelvis "rootDir": "../src" for delte kildekataloger.

types nå er standardinnstillingen en tom matrise

Dette er uten tvil den mest betydningsfulle endringen for prosjekter i den virkelige verden.Historisk sett, hvis du ikke spesifiserte types in compilerOptions, TypeScript ville automatisk inkludere alt under node_modules/@typesDet var praktisk, men også dyrt og skjørt: moderne repositorier trekker ofte inn hundrevis av @types pakker transitivt.

I TypeScript 6.0, types standardinnstilling [], som betyr at ingen pakker av typen «ambient» lastes inn automatiskDu velger nå eksplisitt de globale miljøene du faktisk trenger, for eksempel:

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

Dette kan redusere byggetid med 20–50 % i noen prosjekter, fordi kompilatoren ikke lenger trenger å gjennomgå hver deklarasjonsfil under @typesHvis du virkelig ønsker den gamle «last inn alt»-oppførselen, kan du spesifisere:

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

Hvis du plutselig ser feilmeldinger som «Finner ikke navnet 'prosess'» eller «Finner ikke modulen 'fs'», det er ditt tegn til å legge til node (og alle andre test-/kjøretidstyper du er avhengig av) til din types matrise.

Utdatert: target: es5 og --downlevelIteration

Målretting mot ES5 er nå avskrevetSiden alle relevante nettlesere har levert ES2015+ i årevis og Internet Explorer er pensjonert, anses ikke lenger ES5-utdata som verdt kompleksiteten i selve TypeScript. Det lavest støttede målet fremover er ES2015. Hvis du virkelig må levere ES5, anbefales det å bruke en ekstern transpiler (som Babel eller en bundler-pipeline) enten på TS-kilden din eller på TS-utdata.

Ocuco --downlevelIteration flagget er også avskrevet, fordi det eneste meningsfulle brukstilfellet var å justere emitteringsatferd for ES5-mål. I TypeScript 6.0, innstilling downlevelIteration i det hele tatt vil produsere en avskrivningsfeil. Hvis du bruker ES2015 eller nyere, har flagget uansett aldri hatt noen effekt.

Utdatert: --moduleResolution node og arv classic

Ocuco node (aka node10) moduloppløsningsmodus er utdatertDen modellerte Node 10s oppførsel, men samsvarer ikke med moderne Nodes ESM og oppløsningssemantikk. Prosjekter bør migrere til en av dem. nodenext (for direkte nodemål) eller bundler (for bundlerdrevne miljøer som nettapper eller Bun).

Den opprinnelige moduleResolution: classic strategien er også fjernetDette var TypeScripts historie før Node-løsningen. I dag er alle praktiske scenarier bedre tjent med nodenext or bundler, så klassisk er borte for å redusere kompleksitet og få fordeler.

Utdatert: AMD, UMD, SystemJS og module: none

Følgende module verdier er nå utdatert og støttes i praksis ikke lenger:

• amd
• umd
• systemjs
• none

Disse formatene var avgjørende i tiden før ESM, da nettlesere manglet innebygd modulstøtte og utviklere lente seg på AMD, UMD eller SystemJS for å fylle gapet. I dag håndterer ESM pluss bundlere eller importkart så å si alle reelle brukstilfeller, og «ingen» var aldri spesielt veldefinert.

Hvis du fortsatt sikter deg inn på disse eldre modulformatene, er anbefalingen å migrere mot et ESM-emitterende mål og stole på en bundler eller alternativ kompilator for endelig pakking – eller forbli på TypeScript 5.x inntil en migreringsplan er på plass. Som en del av denne oppryddingen, den gamle amd-module Direktivet er også droppet.

Utdatert: baseUrl

Ocuco baseUrl alternativet har lenge vært en kilde til merkelig, vanskelig feilsøkbar moduloppløsningsadferdMange prosjekter brukte det utelukkende som et prefiks for paths oppføringer, men TypeScript behandlet den også som en generell oppslagsrot, noe som forårsaket importer som "someModule" å løse seg til src/someModule.js uventet når alt utvikleren mente var å støtte tilpassede aliaser som @app/*.

I 6.0, baseUrl er utdatert og vil ikke lenger brukes som en oppslagsrotStikartlegging har ikke vært nødvendig baseUrl i ganske lang tid, så den anbefalte migreringen er ganske enkelt å brette prefikset inn i hver paths oppføring. For eksempel:

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

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

Bare i sjeldne tilfeller der du virkelig brukte baseUrl som en generisk oppslagsrot ville du trenge å gjenskape den oppførselen med en catch-all-sti-kartlegging som:

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

For de fleste lag er det bare å fjerne baseUrl og inlining av prefikser i paths vil bli både tydeligere og tryggere.

Interoperabilitet og strenghet: esModuleInterop, allowSyntheticDefaultImportsog alwaysStrict

TypeScript 6.0 låser også inne det som lenge har vært anbefalt standard interoperabilitetsoppførselDu kan ikke lenger angi esModuleInterop or allowSyntheticDefaultImports til falseDisse alternativene var opprinnelig påloggingsalternativer for å unngå å ødelegge eldre prosjekter, men å holde dem deaktivert i dag fører ofte til subtile kjøretidsproblemer når man blander CommonJS og ESM.

Med interoperabilitet alltid aktivert, kan det hende at visse importmønstre må oppdateres. For eksempel:

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

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

Ocuco alwaysStrict flagget kan heller ikke settes til false lengerTypeScript antar nå JavaScripts strenge modussemantikk på alle områder, inkludert hvordan reserverte ord og this oppføre deg. Hvis du har virkelig gammel kode som bruker reserverte ord som await or static Som identifikatorer må du gi dem nytt navn.

Utdatert: outFile, eldre navnerom module søkeord og import asserts

Ocuco --outFile alternativet er fjernet i 6.0Å sammenkoble flere inndata til én JS-pakke håndteres bedre av Webpack, Rollup, esbuild, Vite, Parcel eller lignende verktøy. TypeScript dobler innsatsen på typesjekk og deklarasjonsutsendelse i stedet for å prøve å være en pakker.

Den arvelige bruken av module å deklarere navnerom er nå en vanskelig feilTidlig TypeScript tillatt:

module Foo {
  export const bar = 10;
}

Den moderne, støttede syntaksen bruker namespace:

namespace Foo {
  export const bar = 10;
}

Denne endringen er nødvendig for å unngå konflikt med potensielle fremtidige ECMAScript-filer. module blokkerDeklarasjoner for Ambient-moduler som declare module "some-module" { ... } forbli fullt støttet.

Importer påstander ved hjelp av asserts er også utdatert, fordi det underliggende forslaget utviklet seg til importattributter ved hjelp av withKode som:

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

Bør migreres til det nye skjemaet:

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

Utdatert: no-default-lib referanser og kommandolinjefillister med tsconfig

Ocuco /// <reference no-default-lib="true" /> Direktivet støttes ikke lengerDet ble ofte misforstått. Hvis du trenger å ekskludere standardbiblioteket, bruk --noLib or --libReplacement i stedet, som tydeligere uttrykker intensjonen på konfigurasjonsnivå.

En annen langvarig kilde til forvirring er hvordan tsc behandler eksplisitte filargumenter når en tsconfig.json er tilstedeTidligere kjørte tsc foo.ts i en slik katalog ville ignorere konfigurasjonsfilen i stillhet. I 6.0 produserer dette scenariet en eksplisitt feil:

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

Hvis du virkelig vil omgå konfigurasjonen og bare kompilere en enkelt fil med standardverdier, kan du nå bruke tsc --ignoreConfig foo.ts å gjøre den intensjonen tydelig.

Klargjøring for TypeScript 7.0

TypeScript 6.0 er komplett med funksjoner og stort sett i stabiliseringsmodusFra nå av og til generell tilgjengelighet forventer teamet kun kritiske feilrettinger. Nattlige versjoner publiseres regelmessig, og teamet sender også ut nattlige versjoner av den kommende native (Go-baserte) TypeScript 7.0 sammen med en dedikert VS Code-utvidelse for eksperimentering med den nye motoren.

Veikartet er bevisst stramt: 7.0 forventes å følge 6.0 kort tid etter., så tilbakemeldingssløyfen for oppgraderingssmerte og migreringsproblemer vil være kort. Hvis du ser avskrivningsvarsler i 6.0, er den sterke anbefalingen å håndtere dem nå i stedet for å vente til 7.0 fremtvinger problemet.

Den praktiske arbeidsflyten for de fleste team ser slik utoppgrader til TypeScript 6.0 RC, fiks problemet ditt types og rootDir, adressere avskrivninger (eller midlertidig stenge dem bak seg "ignoreDeprecations": "6.0" mens du itererer), og kjører med --stableTypeOrdering hvis du trenger å sammenligne utdata eller forberede CI-pipelines for 7.0s deterministiske rekkefølge. Når det er på plass, bør overgangen til den Go-baserte kompilatoren føles som en ytelsesforbedring snarere enn en omskriving som ødelegger.

Samlet sett handler TypeScript 6.0 RC mindre om skinnende syntaks og mer om å sette scenen.: innebygd hastighet i 7.0, renere konfigurasjoner, moderne standarder og standardiserte API-er som innebygde Temporal- og ES2025-programmer som gjør den daglige kodingen enklere. Hvis du tar det i bruk nå, fikser de støyende delene og lener deg til de nye standardene, vil du være i en mye bedre posisjon når den innebygde kompilatoren kommer.