TypeScript 6.0 RC: functies, ingrijpende wijzigingen en hoe je je kunt voorbereiden

Home » Python » TypeScript 6.0 RC: functies, ingrijpende wijzigingen en hoe je je kunt voorbereiden

TypeScript 6.0 heeft officieel de Release Candidate (RC)-mijlpaal bereikt.En het is niet zomaar een kleine update. Dit is de laatste grote versie die draait op de aloude JavaScript-implementatie van de compiler en taalservice, vlak voordat het project overstapt naar een gloednieuwe, op Go gebaseerde engine in TypeScript 7.0. Alleen al daarom is 6.0 een cruciale release: het is de brug die je moet oversteken voordat alles onder de motorkap verandert.

Je kunt de RC vandaag nog uitproberen door deze via npm te installeren. met:

npm install -D typescript@rc

Het kernidee achter TypeScript 6.0 is voorbereiding en afstemming.Deze versie maakt de overgang van 5.9 naar 7.0 soepeler, met aangescherpte standaardinstellingen, het verwijderen van verouderde code en de toevoeging van enkele gerichte functies die ofwel toekomstig gedrag weerspiegelen, ofwel aankomende JavaScript-mogelijkheden zoals Temporal, ES2025 API's en Map "upsert"-methoden blootleggen. Daarnaast zijn er enkele subtiele aanpassingen aan het typesysteem, nieuwe compilerflags en configuratie-standaarden die absoluut van invloed zullen zijn op echte projecten, met name rondom types, rootDiren strengheid.

TypeScript 6.0 als brug naar de op Go gebaseerde 7.0

TypeScript 6.0 is expliciet ontworpen als de laatste grote release van de bestaande JavaScript-codebasis.Het TypeScript-team is bezig de compiler en de taalservice te herschrijven tot een motor nativo en Gowaarbij gebruik wordt gemaakt van native prestaties en parallelle verwerking met gedeeld geheugen. Deze nieuwe engine zal debuteren als TypeScript 7.0 en latere versies, en 6.0 dient als overgangsfase.

De meeste ingrijpende wijzigingen en afschrijvingen in versie 6.0 zijn bedoeld om uw toekomstige upgrade naar versie 7.0 te ondersteunen.Opties die niet efficiënt ondersteund kunnen worden in de native architectuur, oude modulesystemen en hardnekkige eigenaardigheden worden verwijderd of duidelijk gemarkeerd als verouderd met een nooduitgang: u kunt instellen "ignoreDeprecations": "6.0" in tsconfig.json Om de waarschuwingen voor verouderde functies in versie 6.0 te onderdrukken. Maar die optie zal je in versie 7.0 niet helpen, want die opties zullen naar verwachting volledig verdwijnen.

Als je geneigd bent om te wachten tot versie 7.0 uitkomt voordat je configuratie-instellingen opschoont, loop je het risico in de val te lopen.De 6.0 RC is de versie waarin je je problemen zou moeten oplossen. tsconfigNormaliseer typen en ga om met verouderde vlaggen. Twee gigantische sprongen (5.x → 7.0) zullen altijd meer pijn doen dan een overgang van 5.x → 6.0 → 7.0 met kleinere, gecontroleerde wijzigingen.

Wat is er veranderd sinds de 6.0 bèta?

Tussen de bèta en de release candidate heeft het TypeScript-team zich voornamelijk gericht op het afstemmen van het gedrag op de toekomstige 7.0-engine., plus een paar gerichte aanpassingen in typecontrole en DOM-typen.

Een belangrijke wijziging heeft gevolgen voor de typecontrole van functie-uitdrukkingen die worden doorgegeven aan generieke aanroepen.Vooral in JSX-contexten. Wanneer generieke functies worden aangeroepen met callbacks (bijvoorbeeld in React of andere JSX-componenten), verscherpt de RC de type-inferentie zodat deze nauwkeuriger weergeeft wat versie 7.0 zal doen. In de praktijk zult u wellicht merken dat sommige aanroepen die afhankelijk waren van impliciete type-inferentie nu een expliciet type-argument vereisen om de typecontrole correct te laten verlopen, maar u zult ook meer echte bugs in bestaande code opsporen.

De afschaffing van de importassertiesyntaxis is eveneens uitgebreid.TypeScript waarschuwde al voor de oude methode. import ... assert {...} syntaxis in statische imports vanwege het ECMAScript-voorstel dat overstapt op importattributen met withDie afschaffing geldt nu ook voor dynamische imports die gebruikmaken van import() met beweringobjecten zoals import(..., { assert: {...}})De richting is duidelijk: overal importattributen gebruiken.

De DOM-bibliotheektypen zijn bijgewerkt om te voldoen aan de huidige standaarden van het webplatform.Dit omvat updates voor de Temporal-gerelateerde API's in webcontexten. Als u browser-apps ontwikkelt, profiteert u van nauwkeurigere type-definities en betere editor-tools rondom deze nieuwere API's.

Minder contextgevoeligheid voor functies die nooit gebruikt worden this

TypeScript 6.0 introduceert een subtiele maar zeer praktische wijziging in de manier waarop het omgaat met functies zonder expliciete declaratie. this gebruik tijdens type-inferentieHistorisch gezien konden functies met parameters zonder expliciete typen als "contextgevoelig" worden beschouwd, wat betekent dat hun parameter en this Het type was afhankelijk van waar het werd gebruikt. Dat heeft invloed op generieke inferentie en kan leiden tot vreemd gedrag, afhankelijk van de syntaxis van de functie.

Overweeg een generieke helper die gebruikmaakt van een producent- en een consumentpaar.:

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

Maar met de methodesyntaxis zou het voorgaande gedrag verrassend kunnen zijn.Dezelfde logica, geschreven als methoden, kan falen wanneer eigenschappen opnieuw worden geordend, omdat TypeScript "contextgevoelige" functies overslaat bij het afleiden van generieke argumenten. Methoden hebben impliciet een this parameter, waardoor ze in die gevoelige categorie terechtkwamen, zelfs als this werd nooit daadwerkelijk genoemd.

In versie 6.0 worden functies die nooit gelezen worden, verwijderd. this worden nu als minder contextgevoelig beschouwdAnders gezegd, als de compiler ziet dat this Als het helemaal niet binnen een functie wordt gebruikt, zal het die functie niet benadelen tijdens de inferentie. Dat betekent dat de methodesyntaxis en de pijlsyntaxis nu veel consistenter zijn in generieke inferentiescenario's, en dat het vreemde gedrag waarbij iets wel werkt in de ene eigenschappenvolgorde, maar niet in de andere, in deze gevallen verdwijnt.

Deze wijziging verbetert de prioritering van kandidaten voor type-inferentie.: functies zonder een gebruikt this worden informatiebronnen met een hogere prioriteit bij het afleiden van typeargumenten zoals THet effect is minder mysterieus. unknown typen en stabielere inferentie bij refactoring. Dit werk is bijgedragen door Mateusz Burzyński.

Ondersteuning voor Node #/ subpad importen

Met de functie "subpadimports" van Node kunnen pakketten interne importaliassen definiëren via de imports veld in package.jsonDeze aliassen vereenvoudigen importen door diepe relatieve paden te vermijden. Voorheen moest elke subpadsleutel minstens één segment na de initiële sleutel bevatten. #, wat een kleine maar vervelende beperking was voor mensen die gewend waren aan de conventies van bundlers zoals @/....

TypeScript 6.0 ondersteunt nu subpad-imports die beginnen met #/, in lijn met het nieuwere gedrag van Node 20. Dit betekent dat je een configuratie kunt gebruiken zoals:

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

Met deze opzet kunnen modules binnen het pakket – en zelfs gebruikers – importeren via een beknopte methode. #/... voorvoegsel in plaats van lange relatieve paden zoals ../../utils.jsTypeScript begrijpt dit patroon wanneer --moduleResolution is ingesteld op node20, nodenextof bundler, waarmee de semantiek van moderne Node wordt weerspiegeld. Deze verbetering is geïmplementeerd door bijdrager magic-akari.

gebruik --moduleResolution bundler with --module commonjs

Eerder, --moduleResolution bundler kon alleen gebruikt worden met --module esnext or preserveMet de afschaffing van de oudere node/node10 In de module-resolutiemodus hadden veel projecten een migratiepad nodig dat aansloot op hun huidige CommonJS-output.

TypeScript 6.0 maakt het nu mogelijk om combinaties te maken. --moduleResolution bundler with --module commonjsDeze combinatie is vaak een praktische tussenstap voor codebases die nog steeds CommonJS gebruiken, maar overstappen op workflows die meer gericht zijn op bundlers of op nieuwere resolutielogica. Van daaruit kunnen projecten een migratie op de lange termijn plannen naar een van beide:

• module: "preserve" with moduleResolution: "bundler" voor gebundelde webapps en vergelijkbare configuraties, of
• module: "nodenext" voor omgevingen die zich direct richten op moderne Node.js.

Deze wijziging is met name relevant voor teams die vertrekken. moduleResolution: node achter maar ik ben nog niet klaar om de output van ESM volledig te omarmen. Het biedt een stapsgewijze aanpak in plaats van een abrupte overgang.

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. --stableTypeOrdering vlag om de volgorde van 7.0 te emuleren

Een van de belangrijkste architectonische verbeteringen in TypeScript 7.0 is parallelle typecontrole.Het parallel uitvoeren van meerdere checkers betekent dat verschillende delen van het programma in verschillende volgordes kunnen worden bezocht. Als type-ID's en symboolvolgorde afhankelijk zijn van de bezoekvolgorde, kan dit leiden tot niet-deterministische verenigingsvolgorde, eigenschapsvolgorde en zelfs zeldzame verschillen in diagnostiek.

Oudere TypeScript-versies kennen interne type-ID's toe op basis van de volgorde waarin ze worden aangetroffen.Die ID's worden vervolgens gebruikt om zaken zoals union-typen en eigenschappen te sorteren. Daarom zijn ogenschijnlijk onschuldige bewerkingen, zoals het introduceren van een nieuwe ID, vaak problematisch. const vóór een bestaande functie – kan de volgorde van letterlijke verenigingen in de uitgezonden waarden omkeren .d.ts bestanden, of wijzig hoe bepaalde typen in uw editor worden afgedrukt.

TypeScript 7.0 schakelt over op een deterministische, op inhoud gebaseerde ordening voor interne objecten.Elk type of symbool wordt gesorteerd op basis van zijn structuur, niet op basis van de toevallige volgorde waarin het voorkomt. Daardoor produceert hetzelfde programma consistent dezelfde sortering, ongeacht parallellisatie of compilatievolgorde. Dat maakt een einde aan het raadsel "waarom is mijn union ineens omgedraaid?".

Om u te helpen het gedrag tussen versie 6.0 en 7.0 te vergelijken, introduceert de RC het volgende: --stableTypeOrderingWanneer deze vlag is ingeschakeld, gebruikt TypeScript 6.0 hetzelfde deterministische typevolgorde-algoritme als 7.0. Het resultaat is veel minder verschillen in de gegenereerde declaratiebestanden en voorspelbaardere vergelijkingen tussen de uitvoer van 6.x en 7.x.

Determinisme is echter niet gratis.. Inschakelen --stableTypeOrdering Dit kan de typecontrole tot wel 25% vertragen, afhankelijk van uw codebase. Het is bedoeld als hulpmiddel voor diagnose en migratie, niet als een permanent ingeschakelde prestatie-instelling.

Als je alleen typefouten ziet wanneer --stableTypeOrdering is ingeschakeldDit betekent meestal dat je eerdere code vertrouwde op de oude, min of meer toevallige volgorde van typen, waardoor type-inferentie "gewoon werkte". Oplossingen bestaan ​​doorgaans uit het expliciet maken van typen: het toevoegen van een type-argument aan een problematische generieke aanroep, of het annoteren van een variabele met een specifieke interface in plaats van volledig te vertrouwen op type-inferentie voor een complex object.

Nieuwe es2025 doel- en bibliotheekopties

TypeScript 6.0 voegt een es2025 optie voor beide target en libHoewel ES2025 geen nieuwe kernsyntaxis introduceert in vergelijking met voorgaande jaren, integreert het wel verschillende gestandaardiseerde API's die voorheen achter een bepaalde drempelwaarde verborgen zaten. esnext.

Door te richten op of op te nemen es2025, je krijgt bijgewerkte typen voor nieuwe ingebouwde functies als RegExp.escapeen sommige API's worden verplaatst naar een andere locatie. esnext om in es2025Dat omvat zaken zoals Promise.try, iterator-helpers en extra Set Methoden die de volledige specificatierijpheid hebben bereikt. Aan dit werk is bijgedragen door Kenta Moriuchi.

Het bredere verhaal is dat de standaardwaarde target In versie 6.0 wordt nu het huidige ECMAScript-jaar bijgehouden., wat er momenteel voor zorgt dat je in feite op ES2025 terechtkomt als je geen doelomgeving specificeert. Dat sluit beter aan bij de realiteit van evergreen runtimes en moderne tools.

Ingebouwde typen voor de Temporal API

Het langverwachte Temporal-voorstel heeft fase 3 bereikt en zal naar verwachting het beruchte Temporal-voorstel vervangen. Date API voor serieuze datum-/tijdwerkzaamhedenTypeScript 6.0 biedt nu volwaardige typen voor Temporal, zodat je direct aan de slag kunt met het schrijven van Temporal-gebaseerde code met volledige typeveiligheid en editorondersteuning.

Om tijdelijke gegevenstypen in te schakelen, kunt u het volgende gebruiken: --target esnext of configureer uw bibliotheken expliciet via zoiets als:

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

Of u kunt ervoor kiezen om alleen de tijdelijke subset te selecteren met "esnext.temporal" Als u een meer gedetailleerde configuratie wilt. Zodra dit is ingeschakeld, kunt u code schrijven in de trant van:

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 wordt al ondersteund in sommige runtimes en kan in andere runtimes worden geïmplementeerd met behulp van polyfills.Deze typen zijn dus daadwerkelijk bruikbaar. Er verschijnt documentatie op MDN (hoewel er nog steeds enkele hiaten worden opgevuld). De typen zijn bijgedragen door GitHub-gebruiker Renegade334.

Upsert-ondersteuning: Map.getOrInsert en getOrInsertComputed

JavaScript-ontwikkelaars schrijven al geruime tijd handmatig "check-then-set-then-get"-patronen. Map voor jarenEen typisch patroon controleert of een sleutel bestaat, stelt een standaardwaarde in als deze niet bestaat, en retourneert ten slotte een waarde – standaardcode die gemakkelijk fout kan gaan of overal herhaald kan worden.

Het ECMAScript-voorstel "upsert" (nu fase 4) introduceert getOrInsert en getOrInsertComputed on Map en WeakMapTypeScript 6.0 voegt typeondersteuning toe voor deze methoden in de esnext lib, zodat je meteen aan de slag kunt met het schrijven van meer declaratieve upserts.

Met getOrInserteen uitgebreid patroon zoals dit:

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 worden samengevouwen tot één regel.:

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

De metgezel getOrInsertComputed is ideaal voor dure standaardinstellingen—Het accepteert een callback die alleen wordt aangeroepen als de sleutel ontbreekt. Die callback kan zelfs de sleutel als parameter ontvangen, waardoor je de standaardwaarde kunt afleiden van de sleutel zelf. De type-definities van TypeScript leggen dit gedrag nauwkeurig vast, wederom dankzij de bijdragen van Renegade334.

RegExp.escape en veiliger regex-bouw

Als je ooit door de gebruiker aangeleverde tekenreeksen hebt samengevoegd tot een reguliere expressie, weet je dat je speciale tekens eerst moet escapen.—maar de meeste codebases implementeren het escapen opnieuw in een helperfunctie of laten het volledig achterwege. Het voorstel voor RegExp Escaping (nu fase 4) standaardiseert dit met RegExp.escape.

TypeScript 6.0 maakt typen beschikbaar voor RegExp.escape onder de es2025 libDat betekent dat wanneer je ES2025 als doel hebt of opneemt, je veilig helperfuncties kunt schrijven zoals:

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

Een handmatig gerolde ontsnappingsfunctie is niet meer nodig.En TypeScript zal de API volledig begrijpen en op typefouten controleren. Deze toevoeging, net als het werk aan de ES2025-doelstelling, is afkomstig van Kenta Moriuchi.

dom De bibliotheek bevat nu API's voor iteratie en asynchrone iteratie.

Historisch gezien heeft TypeScript de ondersteuning voor DOM-iterators opgesplitst in dom, dom.iterableen dom.asynciterableAls je eroverheen wilde itereren NodeList or HTMLCollection with for...ofje moest eraan denken om toe te voegen dom.iterable in "lib" configuratie naast domDit zorgde vaak voor verwarring, vooral omdat alle moderne browsers iterables en asynchrone iterables op DOM-collecties ondersteunen.

In TypeScript 6.0, lib.dom.iterable.d.ts en lib.dom.asynciterable.d.ts worden in feite samengevoegd tot lib.dom.d.tsDat betekent dat je gebruik moet maken van "dom" Alone biedt nu standaard iterable en async iterable gedrag.

Je kunt het nog steeds vermelden. dom.iterable en dom.asynciterable in tsconfigMaar die bestanden zijn nu lege hulzen. Als je vorige configuratie er zo uitzag:

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

Je kunt het gerust vereenvoudigen tot gewoon "dom"en iteratie over DOM-verzamelingen zoals document.querySelectorAll("div") zal nog steeds een typecontrole uitvoeren:

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

Dit is een kleine maar welkome opruimactie. Dat zorgt ervoor dat de standaard DOM-bibliotheek aansluit bij de realiteit van huidige browsers en elimineert een ander valkuil bij de projectconfiguratie.

Standaardwaarden, afschrijvingen en ingrijpende wijzigingen in TypeScript 6.0

Naast de fraaie API's brengt 6.0 enkele van de meest uitgesproken wijzigingen aan in de standaardinstellingen van TypeScript sinds 1.0.Deze veranderingen weerspiegelen het huidige JavaScript-ecosysteem: evergreen runtimes, ESM als basis, wijdverbreid gebruik van bundlers en een sterke behoefte aan strikte typering en prestaties.

Het team belicht een aantal algemene trends die aan deze beslissingen ten grondslag liggen.ES5 en echt verouderde browsers zijn bijna verdwenen; AMD/UMD-modulesystemen zijn een niche; bijna alles wordt nu als module geleverd; strikte typering is de norm; en prestaties moeten centraal blijven staan, vooral nu 7.0 parallelle controle introduceert.

Het resultaat is dat TypeScript 6.0 en 7.0 worden vormgegeven met moderne standaardinstellingen en minder "nooduitgangen" naar verouderde versies.Voor 6.0 RC kunt u waarschuwingen voor verouderde functies tijdelijk uitschakelen door dit in te stellen. "ignoreDeprecations": "6.0" in tsconfigMaar die opties zullen niet beschikbaar zijn in versie 7.0. Sommige aanpassingen kunnen worden geautomatiseerd met tools zoals de experimentele versie. ts5to6 codemod, waarmee je dingen kunt herschrijven zoals baseUrl en rootDir configuraties binnen een project.

Twee aanpassingen die veel projecten direct nodig zullen hebben.

Hoewel er een lange lijst met afgeschreven functies is, zullen twee configuratiewijzigingen waarschijnlijk de meeste codebases treffen.:

• Stel de expliciet in types reeks (heel vaak) plus je testframework). Zonder dit verlies je automatisch opgenomen omgevingstypen van @types/*.
• Expliciet ingesteld rootDir (algemeen "./src") Als je vertrouwde op de oude methode van "afleiding van de gemeenschappelijke root". Anders zou de structuur van je gegenereerde bestand op subtiele manieren kunnen veranderen.

Symptomen van ontbrekende types inclusief een stortvloed aan fouten over globale variabelen zoals process, fs, pathof describe ongedefinieerdSymptomen van een veranderde rootDir Het gaat er meer om dat uitvoerpaden onverwacht een extra signaal krijgen. src segment (bijvoorbeeld dist/src/index.js in plaats van dist/index.js).

Bijgewerkte standaardinstellingen voor moderne projecten

Verschillende compileropties hebben nu nieuwe standaardwaarden die overeenkomen met de manier waarop de meeste nieuwe apps daadwerkelijk worden gebouwd.:

• strict nu standaard ingesteld op trueDe strikte modus is niet langer een optionele luxe; het is de standaardinstelling. Als u voorheen vertrouwde op niet-strikt gedrag, moet u dit expliciet instellen. "strict": false (hoewel je dan wel een groot aantal veiligheidscontroles mist).
• module nu standaard ingesteld op esnextDit geeft aan dat ESM het dominante moduleformaat is en het beste samenwerkt met bundlers en moderne Node.
• target Standaard wordt het huidige ECMAScript-jaar gebruikt (momenteel feitelijk ES2025).waarbij erkend wordt dat de meeste implementaties gericht zijn op omgevingen die permanent operationeel zijn of via een bundler verlopen die, indien nodig, de implementatie verder kan downgraden.
• noUncheckedSideEffectImports nu true bij verstekDit helpt je bij het opsporen van typefouten of onjuiste paden in imports die alleen voor neveneffecten zijn opgenomen.
• libReplacement standaard falsewaardoor een heleboel extra mislukte module-resoluties en overhead door monitoring worden vermeden, totdat een project expliciet kiest voor gespecialiseerd bibliotheekgedrag.

Als een van deze nieuwe standaardinstellingen je build verstoort, kunnen ze allemaal expliciet worden overschreven in tsconfig.jsonMaar het is de bedoeling dat nieuwe projecten "gewoon het juiste doen" zonder extra configuratie.

rootDir Nu wordt standaard de configuratiemap gebruikt.

Voorheen gold dat als je niets had opgegeven rootDirTypeScript probeerde een gemeenschappelijke bronroot af te leiden. gebaseerd op alle niet-declaratiebestanden in het programma. Dat maakte het lastiger om projectgrenzen te bepalen en vereiste het scannen van veel bestandspaden om te beslissen waar emit moest worden geplaatst.

In TypeScript 6.0 is de standaardwaarde rootDir is simpelweg de map die bevat tsconfig.jsonHet oude inferentiegedrag is alleen van toepassing wanneer u het uitvoert. tsc op de commandoregel zonder enige tsconfig at all.

Deze wijziging betekent dat projecten met bronbestanden dieper dan de configuratiemap dit expliciet moeten instellen. rootDirEen veelvoorkomende configuratie zou zijn:

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

Als uw configuratie verwijst naar bestanden boven de tsconfig locatie, u zult ook moeten uitbreiden rootDir dienovereenkomstigBijvoorbeeld "rootDir": "../src" voor gedeelde bronmappen.

types Nu is de standaardwaarde een lege array.

Dit is wellicht de meest ingrijpende verandering voor projecten in de praktijk.Historisch gezien, als je niets had gespecificeerd types in compilerOptionsTypeScript zou automatisch alles onder <default> includen. node_modules/@typesDat was handig, maar ook duur en kwetsbaar: moderne incassobureaus trekken vaak honderden voertuigen aan. @types pakketten transitief.

In TypeScript 6.0, types standaard []Dit betekent dat er geen omgevingspakketten automatisch worden geladen.Je kunt nu expliciet de globale omgevingen selecteren die je daadwerkelijk nodig hebt, bijvoorbeeld:

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

Dit kan de bouwtijd in sommige projecten met 20-50% verkorten., omdat de compiler niet langer elk declaratiebestand hoeft te doorzoeken onder @typesAls u echt de oude functionaliteit wilt behouden waarbij alles wordt geladen, kunt u het volgende specificeren:

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

Als je plotseling foutmeldingen ziet zoals "Kan de naam 'process' niet vinden" of "Kan de module 'fs' niet vinden"Dat is jouw signaal om toe te voegen. node (en alle andere test-/runtime-typen waarop u vertrouwt) naar uw types matrix.

Verouderd: target: es5 en --downlevelIteration

Het gebruik van ES5 als doelplatform is nu verouderd.Aangezien alle relevante browsers al jaren ES2015+ ondersteunen en Internet Explorer niet langer wordt ondersteund, wordt ES5-output niet langer als de complexiteit binnen TypeScript zelf beschouwd. Het laagst ondersteunde doel is ES2015. Als u per se ES5 wilt gebruiken, is het aan te raden een externe transpiler (zoals Babel of een bundler-pipeline) te gebruiken, hetzij voor uw TypeScript-broncode, hetzij voor de output van TypeScript.

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. --downlevelIteration De vlag is ook verouderd., omdat het enige zinvolle gebruik ervan was om het emit-gedrag aan te passen voor ES5-doelen. In TypeScript 6.0, instellen downlevelIteration Als je dit doet, krijg je een waarschuwing dat de functie verouderd is. Als je ES2015 of nieuwer gebruikt, heeft de vlag sowieso nooit enig effect gehad.

Verouderd: --moduleResolution node en erfenis classic

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. node (aka node10De module-resolutiemodus is verouderd.Het model simuleerde het gedrag van Node 10, maar komt niet overeen met de ESM- en resolutiesemantiek van moderne Node. Projecten zouden moeten migreren naar een van beide. nodenext (voor directe Node-doelen) of bundler (voor door bundlers aangestuurde omgevingen zoals webapps of Bun).

De oorspronkelijke moduleResolution: classic De strategie is ook verwijderd.Dit was het resolutieverhaal van TypeScript vóór Node. Tegenwoordig zijn alle praktische scenario's beter gediend door nodenext or bundlerDaarom is de klassieke aanpak verdwenen om de complexiteit en uitzonderlijke gevallen te verminderen.

Verouderd: AMD, UMD, SystemJS en module: none

De volgende module Deze waarden zijn nu verouderd en worden feitelijk niet meer ondersteund.:

• amd
• umd
• systemjs
• none

Deze formats waren cruciaal in het tijdperk vóór ESM.Toen browsers nog geen native moduleondersteuning hadden, vertrouwden ontwikkelaars op AMD, UMD of SystemJS om dat gat op te vullen. Tegenwoordig dekken ESM in combinatie met bundlers of import maps vrijwel alle gangbare gebruikssituaties af, en "geen" was nooit echt een goed gedefinieerd begrip.

Als u zich nog steeds richt op deze verouderde moduleformatenHet advies is om over te stappen naar een ESM-genererend doelplatform en te vertrouwen op een bundler of alternatieve compiler voor de uiteindelijke verpakking, of om bij TypeScript 5.x te blijven totdat er een migratieplan is. Als onderdeel van deze opruiming wordt het oude amd-module De richtlijn wordt ook ingetrokken.

Verouderd: baseUrl

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. baseUrl De optie is al lange tijd een bron van vreemd, moeilijk te debuggen gedrag bij het oplossen van modules.Veel projecten gebruikten het puur als voorvoegsel voor paths vermeldingen, maar TypeScript behandelde het ook als een algemene opzoekbasis, wat leidde tot imports zoals "someModule" om te besluiten src/someModule.js onverwacht, terwijl de ontwikkelaar alleen maar ondersteuning wilde bieden voor aangepaste aliassen zoals @app/*.

In 6.0, baseUrl is verouderd en zal niet langer als opzoekbasis worden gebruikt.Padtoewijzing was niet vereist baseUrl Dit is al geruime tijd zo, dus de aanbevolen migratie is simpelweg om het voorvoegsel in elk onderdeel op te nemen. paths invoer. Bijvoorbeeld:

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

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

Alleen in zeldzame gevallen waarin je daadwerkelijk gebruik hebt gemaakt van baseUrl als een generieke opzoekbasis Zou u dat gedrag moeten reproduceren met een algemene padtoewijzing zoals:

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

Voor de meeste teams volstaat het om simpelweg te verwijderen. baseUrl en het inline plaatsen van voorvoegsels in paths zal zowel duidelijker als veiliger zijn.

Interoperabiliteit en strikte regels: esModuleInterop, allowSyntheticDefaultImportsen alwaysStrict

TypeScript 6.0 legt ook vast wat al lange tijd het aanbevolen standaardgedrag voor interoperabiliteit is.Je kunt het niet langer instellen. esModuleInterop or allowSyntheticDefaultImports naar falseDeze opties waren oorspronkelijk optioneel om te voorkomen dat oudere projecten niet meer zouden werken, maar als ze tegenwoordig uitgeschakeld blijven, leidt dat vaak tot subtiele runtimeproblemen bij het combineren van CommonJS en ESM.

Omdat interoperabiliteit altijd is ingeschakeld, moeten bepaalde importpatronen mogelijk worden bijgewerkt.. Bijvoorbeeld:

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

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

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. alwaysStrict De vlag kan ook niet worden ingesteld op false meerTypeScript gaat er nu van uit dat de strikte modus van JavaScript overal wordt toegepast, inclusief hoe gereserveerde woorden en this gedrag. Als je echt oude code hebt die gereserveerde woorden gebruikt zoals await or static Omdat het identificatoren zijn, moet je ze hernoemen.

Verouderd: outFile, verouderde naamruimte module trefwoord en import asserts

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. --outFile Deze optie is verwijderd in versie 6.0.Het samenvoegen van meerdere inputs tot één JavaScript-bundel is een taak die beter kan worden uitgevoerd door Webpack, Rollup, esbuild, Vite, Parcel of vergelijkbare tools. TypeScript zet steeds meer in op typecontrole en het genereren van declaraties in plaats van te proberen een bundler te zijn.

Het traditionele gebruik van module Het declareren van namespaces is tegenwoordig een ernstige fout.. Vroege versies van TypeScript maakten het volgende mogelijk:

module Foo {
  export const bar = 10;
}

De moderne, ondersteunde syntaxis maakt gebruik van namespace:

namespace Foo {
  export const bar = 10;
}

Deze wijziging is noodzakelijk om conflicten met toekomstige ECMAScript-versies te voorkomen. module blokkenOmgevingsmoduledeclaraties zoals declare module "some-module" { ... } blijven volledig ondersteund worden.

Importeer beweringen met behulp van asserts zijn ook verouderd., omdat het onderliggende voorstel zich ontwikkelde tot het importeren van attributen met behulp van withCode zoals:

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

Moet worden overgezet naar de nieuwe vorm:

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

Verouderd: no-default-lib verwijzingen en bestandslijsten via de commandoregel met tsconfig

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. /// <reference no-default-lib="true" /> De richtlijn wordt niet langer ondersteund.Het werd vaak verkeerd begrepen. Als je de standaardbibliotheek wilt uitsluiten, gebruik dan... --noLib or --libReplacement in plaats daarvan, wat de intentie op configuratieniveau duidelijker weergeeft.

Een andere langdurige bron van verwarring is hoe tsc behandelt expliciete bestandsargumenten wanneer een tsconfig.json is aanwezigVoorheen liep het programma. tsc foo.ts In een dergelijke map zou het configuratiebestand stilzwijgend worden genegeerd. In versie 6.0 levert dat scenario een expliciete foutmelding op:

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

Als je de configuratie echt wilt omzeilen en gewoon één bestand met standaardwaarden wilt compileren...Je kunt nu gebruikmaken van tsc --ignoreConfig foo.ts om die intentie duidelijk te maken.

Voorbereidingen treffen voor TypeScript 7.0

TypeScript 6.0 is volledig functioneel en bevindt zich grotendeels in de stabilisatiefase.Vanaf nu tot de algemene beschikbaarheid verwacht het team alleen nog kritieke bugfixes. Er worden regelmatig nightly builds uitgebracht en het team levert ook nightly versies van de aankomende native (op Go gebaseerde) TypeScript 7.0, samen met een speciale VS Code-extensie om met de nieuwe engine te experimenteren.

De roadmap is opzettelijk strak: versie 7.0 zal naar verwachting kort na versie 6.0 verschijnen.De feedbackloop over problemen bij upgrades en migraties zal dus kort zijn. Als je waarschuwingen ziet over verouderde functies in versie 6.0, is het sterk aan te raden deze nu aan te pakken in plaats van te wachten tot versie 7.0 dit afdwingt.

De praktische workflow voor de meeste teams ziet er als volgt uit:: upgrade naar TypeScript 6.0 RC, los je probleem op types en rootDir, pak verouderde functies aan (of plaats ze tijdelijk achter een scherm). "ignoreDeprecations": "6.0" terwijl je itereert), en uitvoeren met --stableTypeOrdering Als je outputs moet vergelijken of CI-pipelines moet voorbereiden voor de deterministische sortering van versie 7.0, dan zal de overstap naar de op Go gebaseerde compiler aanvoelen als een prestatieverbetering in plaats van een ingrijpende herziening.

Samengevat draait TypeScript 6.0 RC minder om flitsende syntax en meer om het leggen van de basis.De native snelheid in versie 7.0, schonere configuraties, moderne standaardinstellingen en gestandaardiseerde API's zoals Temporal en ES2025 built-ins maken het dagelijkse programmeren eenvoudiger. Als je het nu implementeert, de kleine problemen oplost en de nieuwe standaardinstellingen omarmt, ben je in een veel betere positie wanneer de native compiler beschikbaar komt.