TypeScript 6.0 RC: funkcije, ključne spremembe in kako se pripraviti

Domov » Python » TypeScript 6.0 RC: funkcije, ključne spremembe in kako se pripraviti

TypeScript 6.0 je uradno dosegel mejnik Release Candidate (RC)., in to ni le še ena inkrementalna posodobitev. To je zadnja večja različica, ki deluje na dolgoletni implementaciji JavaScripta za prevajalnik in jezikovno storitev, tik preden projekt preskoči na povsem nov mehanizem, ki temelji na Gou, v TypeScriptu 7.0. Že samo to naredi 6.0 ključno izdajo: to je most, ki ga morate prečkati, preden se vse pod pokrovom spremeni.

RC lahko začnete preizkušati še danes tako, da ga namestite iz npm-a. z:

npm install -D typescript@rc

Osrednja ideja TypeScripta 6.0 je priprava in poravnavaTa različica olajša pot od različice 5.9 do 7.0, saj zaostruje privzete nastavitve, opušča zgodovinsko navlako in dodaja nekaj ciljno usmerjenih funkcij, ki bodisi odražajo prihodnje vedenje bodisi razkrivajo prihajajoče zmogljivosti JavaScripta, kot so Temporal, API-ji ES2025 in metode »upsert« Map. Med potjo je nekaj subtilnih prilagoditev sistema tipov, novih zastavic prevajalnika in privzetih konfiguracijskih nastavitev, ki bodo zagotovo vplivale na resnične projekte – zlasti tiste, ki so povezani z… types, rootDir, in strogost.

TypeScript 6.0 kot most do različice 7.0, ki temelji na jeziku Go

TypeScript 6.0 je izrecno zasnovan kot zadnja večja izdaja na obstoječi kodni bazi JavaScript.Ekipa TypeScript je prepisala prevajalnik in jezikovno storitev v izvorni motor v Go, pri čemer izkorišča izvorno zmogljivost in paralelizem deljenega pomnilnika. Ta novi mehanizem bo prvič predstavljen kot TypeScript 7.0 in novejši, različica 6.0 pa je tik pred njim kot prehodna faza.

Večina ključnih sprememb in opustitev v različici 6.0 je namenjena temu, da bo vaša prihodnja nadgradnja na različico 7.0 preživela.Možnosti, ki jih izvorna arhitektura, stari modularni sistemi in dolgotrajne posebnosti ne morejo učinkovito podpirati, so bodisi odstranjene bodisi jasno označene kot zastarele z izhodom za izhod: lahko nastavite "ignoreDeprecations": "6.0" v vašem tsconfig.json za zatiranje diagnostike zastarelosti v različici 6.0. Vendar vam ta zastavica v različici 7.0 ne bo pomagala – te možnosti naj bi popolnoma izginile.

Če ste v skušnjavi, da bi »počakali na 7.0«, preden se lotite kakršnega koli čiščenja konfiguracije, je to past.6.0 RC je različica, pri kateri naj bi popravljali svoj tsconfig, normalizirati tipe in obravnavati zastarele zastavice. Dva velikanska skoka (5.x → 7.0) bosta vedno bolj škodila kot prehod s 5.x → 6.0 → 7.0 z manjšimi, nadzorovanimi spremembami.

Kaj se je spremenilo od beta različice 6.0

Med beta in RC različico se je ekipa TypeScript osredotočila predvsem na uskladitev delovanja s prihodnjim mehanizmom 7.0., plus nekaj ciljno usmerjenih prilagoditev pri preverjanju tipov in tipiziranju DOM.

Ena pomembna sprememba vpliva na preverjanje tipov izrazov funkcij, ki se prenašajo v generične klice., zlasti v kontekstih JSX. Ko se generične funkcije klicejo s povratnimi klici (na primer v Reactu ali drugih komponentah JSX), RC zoži sklepanje, tako da natančneje odraža, kaj bo naredila različica 7.0. V praksi boste morda opazili, da nekateri klici, ki so se zanašali na implicitno sklepanje, zdaj zahtevajo eksplicitni argument tipa, da bo preverjanje tipov delovalo, vendar boste v obstoječi kodi odkrili tudi več resničnih napak.

Podaljšana je bila tudi zastarelost sintakse uvoznih trditev.TypeScript je že svarilo pred starim import ... assert {...} sintaksa pri statičnih uvozih zaradi predloga ECMAScript, ki se premika k uvozu atributov z withTa opustitev velja tudi za dinamične uvoze z uporabo import() s trditvami, kot so import(..., { assert: {...}})Smer je jasna: uvoz atributov povsod.

Tipi knjižnic DOM so bili osveženi, da ustrezajo trenutnim standardom spletnih platform., vključno s posodobitvami API-jev, povezanih s funkcijo Temporal, v spletnih kontekstih. Če gradite aplikacije za brskalnik, imate koristi od natančnejšega tipkanja in boljših orodij za urejanje, ki temeljijo na teh novejših API-jih.

Manjša kontekstna občutljivost za funkcije, ki nikoli ne uporabljajo this

TypeScript 6.0 uvaja subtilno, a zelo praktično spremembo v načinu obravnave funkcij brez eksplicitnega this uporaba med sklepanjem tipovZgodovinsko gledano so funkcije s parametri brez eksplicitnih tipov lahko veljale za "kontekstualno občutljive", kar pomeni, da so njihovi parametri in this Tipi so bili odvisni od tega, kje so bili uporabljeni. To vpliva na generično sklepanje in lahko privede do nenavadnega vedenja, odvisno od sintakse funkcije.

Razmislite o generičnem pomočniku, ki uporablja par proizvajalca in potrošnika.:

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

Toda s sintakso metode bi lahko bilo prejšnje vedenje presenetljivoIsta logika, zapisana kot metode, lahko odpove pri prerazporeditvi lastnosti, ker TypeScript pri sklepanju na generične argumente preskoči »kontekstualno občutljive« funkcije. Metode imajo implicitno this parameter, ki jih je uvrstil v to občutljivo kategorijo, tudi če this ni bil nikoli dejansko omenjen.

V različici 6.0 funkcije, ki nikoli ne berejo this se zdaj obravnavajo kot manj kontekstualno občutljiviPovedano drugače, če prevajalnik to vidi this se znotraj funkcije sploh ne uporablja, te funkcije med sklepanjem ne bo kaznoval. To pomeni, da sta sintaksa metode in sintaksa puščice zdaj veliko bolj dosledni v scenarijih generičnega sklepanja, nenavadno vedenje »deluje v enem vrstnem redu lastnosti, ne uspe v drugem« pa v teh primerih izgine.

Ta sprememba izboljša določanje prioritet kandidatov za sklepanje tipov.: funkcije brez uporabljenega this postanejo viri informacij z višjo prioriteto pri sklepanju o argumentih tipov, kot so TUčinek je manj skrivnosten. unknown tipi in stabilnejše sklepanje med refaktorji. To delo je prispeval Mateusz Burzyński.

Podpora za vozlišče #/ uvozi podpoti

Funkcija »uvoza podpoti« v vozlišču omogoča paketom, da definirajo notranje vzdevke uvoza prek imports polje v package.jsonTi vzdevki poenostavljajo uvoz, saj se izognejo globokim relativnim potem. Prej je moral imeti vsak ključ podpoti vsaj en segment za začetnim #, kar je bila majhna, a nadležna omejitev za ljudi, ki so bili vajeni združevanja konvencij, kot je @/....

TypeScript 6.0 zdaj podpira uvoz podpoti, ki se začnejo z #/, kar je usklajeno z novejšim delovanjem Node 20. To pomeni, da lahko uporabite konfiguracijo, kot je:

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

S to nastavitvijo lahko moduli znotraj paketa – in celo potrošniki – uvozijo prek jedrnatega #/... predpono namesto dolgih relativnih poti, kot je ../../utils.jsTypeScript razume ta vzorec, ko --moduleResolution nastavljena na node20, nodenextali bundler, ki zrcali semantiko sodobnega Node. To izboljšavo je uvedel sodelavec magic-akari.

Uporaba --moduleResolution bundler z --module commonjs

Prej, --moduleResolution bundler se je lahko uporabljalo le z --module esnext or preserveZ omalovaževanjem starejših node/node10 V načinu ločljivosti modulov je veliko projektov potrebovalo pot selitve, ki bi ustrezala njihovemu trenutnemu izhodu CommonJS.

TypeScript 6.0 zdaj omogoča kombiniranje --moduleResolution bundler z --module commonjsTa kombinacija je pogosto praktična odskočna deska za kodne baze, ki še vedno uporabljajo CommonJS, vendar se premikajo proti delovnim procesom, osredotočenim na paketne programe, ali novejši logiki razreševanja. Od tam naprej lahko projekti načrtujejo dolgoročnejšo migracijo na:

• module: "preserve" z moduleResolution: "bundler" za spletne aplikacije v paketu in podobne nastavitve ali
• module: "nodenext" za okolja, ki neposredno ciljajo na sodobni Node.js.

Ta sprememba je še posebej pomembna za ekipe, ki odhajajo moduleResolution: node zadaj vendar še ni pripravljen v celoti sprejeti rezultatov ESM. Ponuja vam fazno pot namesto prepada.

Naš --stableTypeOrdering zastavica za posnemanje vrstnega reda 7.0

Ena glavnih arhitekturnih nadgradenj, ki prihajajo v TypeScript 7.0, je vzporedno preverjanje tipov.Vzporedno izvajanje več preverjevalnikov pomeni, da je mogoče različne dele programa obiskati v različnem vrstnem redu. Če so ID-ji tipov in vrstni red simbolov odvisni od vrstnega reda obiskov, lahko pride do nedeterminističnega urejanja združevanja, urejanja lastnosti in celo redkih razlik v diagnostiki.

Starejše različice TypeScripta dodeljujejo notranje ID-je tipov glede na vrstni red srečanjTi ID-ji se nato uporabljajo za razvrščanje stvari, kot so tipi zvez in lastnosti. Zato so na videz neškodljive spremembe – kot je uvedba novega const pred obstoječo funkcijo – lahko obrne vrstni red literalnih združitev v oddanih .d.ts datoteke ali spremenite način tiskanja nekaterih vrst v urejevalniku.

TypeScript 7.0 preklopi na deterministično, na vsebini temelječe urejanje notranjih objektovVsak tip ali simbol je razvrščen glede na svojo strukturo in ne glede na naključni vrstni red obiskov, zato bo isti program dosledno ustvaril enak vrstni red ne glede na vzporednost ali vrstni red prevajanja. To odpravlja uganko »zakaj se je moja unija nenadoma obrnila?«.

Za lažjo primerjavo vedenja med različicama 6.0 in 7.0 RC predstavlja --stableTypeOrderingKo je ta zastavica omogočena, TypeScript 6.0 uporablja isti deterministični algoritem za urejanje tipov kot 7.0. Rezultat je veliko manj razlik v izdanih deklaracijskih datotekah in bolj predvidljive primerjave med izhodi 6.x in 7.x.

Vendar determinizem ni zastonj. Omogočanje --stableTypeOrdering lahko upočasni preverjanje tipov do približno 25 %, odvisno od vaše kodne baze. Namenjeno je kot diagnostična in migracijska pomoč, ne pa kot trajno vklopljena nastavitev delovanja.

Če se napake pri tipkanju pojavijo le, ko --stableTypeOrdering je vklopljen, to običajno pomeni, da se je vaša prejšnja koda zanašala na staro kvazi-naključno urejanje tipov, da bi sklepanje »preprosto delovalo«. Popravki običajno vključujejo eksplicitno opredelitev tipov – dodajanje argumenta tipa problematičnemu generičnemu klicu ali označevanje spremenljivke s specifičnim vmesnikom, namesto da bi se za kompleksen objekt v celoti zanašali na sklepanje.

Novo es2025 možnosti target in lib

TypeScript 6.0 dodaja es2025 možnost za oba target in libČeprav ES2025 v primerjavi s prejšnjimi leti ne uvaja nove osnovne sintakse, vključuje več standardiziranih API-jev, ki so bili prej omejeni. esnext.

S ciljanjem ali vključevanjem es2025, pridobite posodobljene tipe za nove vgrajene funkcije kot RegExp.escapein nekateri API-ji so premaknjeni iz esnext v es2025To vključuje stvari, kot so Promise.try, pomočniki iteratorjev in dodatno Set metode, ki so dosegle polno specifikacijsko zrelost. To delo je prispeval Kenta Moriuchi.

Širša zgodba je, da je privzeto target v različici 6.0 zdaj sledi trenutnemu letu ECMAScript, kar vas trenutno dejansko pripelje do ES2025, če ne določite cilja. To se bolje ujema z realnostjo vedno novih izvajalnih okolij in sodobnih orodij.

Vgrajeni tipi za Temporal API

Dolgo pričakovani predlog Temporal je dosegel 3. fazo in naj bi nadomestil zloglasnega Date API za resno delo z datumom/časomTypeScript 6.0 zdaj ponuja prvovrstne tipkarske rešitve za Temporal, tako da lahko začnete pisati kodo, ki temelji na Temporalu, s popolno varnostjo tipov in podporo za urejevalnike.

Če želite omogočiti časovne tipe, lahko uporabite --target esnext ali pa izrecno konfigurirajte svoje knjižnice prek nečesa takega:

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

Ali pa se lahko odločite samo za časovno podmnožico z "esnext.temporal" če želite bolj podrobno konfiguracijo. Ko je omogočena, lahko napišete kodo v skladu z naslednjim:

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

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

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

Časovno je že podprto v nekaterih izvajalnih okoljih, v drugih pa ga je mogoče polifilirati., zato so te vrste danes resnično uporabne. Dokumentacija se pojavlja na MDN (nekatere vrzeli se še zapolnjujejo). Tipografije je prispeval uporabnik GitHuba Renegade334.

Podpora za upsert: Map.getOrInsert in getOrInsertComputed

Razvijalci JavaScripta so ročno pisali vzorce »preveri-nastavi-nato-pridobi« Map letaTipičen vzorec preveri, ali ključ obstaja, če ne, nastavi privzeto vrednost in na koncu vrne vrednost – šablonski vzorec, ki ga je enostavno narediti napačno ali ponoviti povsod.

Predlog »upsert« ECMAScript (zdaj 4. faza) uvaja getOrInsert in getOrInsertComputed on Map in WeakMapTypeScript 6.0 dodaja podporo za tipe za te metode v esnext lib, tako da lahko takoj začnete pisati več deklarativnih upsertov.

z getOrInsert, podroben vzorec, kot je ta:

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

Lahko se strne v eno vrstico:

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

Spremljevalec getOrInsertComputed je idealen za drage privzete stroške—sprejme povratni klic, ki se pokliče le, če ključ manjka. Ta povratni klic lahko celo prejme ključ kot parameter, kar vam omogoča, da izpeljete privzeto vrednost iz samega ključa. Tipkanje v TypeScriptu natančno zajame ta vedenja, še enkrat zahvaljujoč prispevkom Renegade334.

RegExp.escape in varnejše gradnje regularnih izrazov

Če ste kdaj združili uporabniško podana niza v regularni izraz, veste, da morate najprej ubežati posebne znake.—vendar večina kodnih baz bodisi ponovno implementira ubežne znake v pomočniku bodisi jih popolnoma pozabi. Predlog za ubežne znake RegExp (zdaj 4. faza) to standardizira z RegExp.escape.

TypeScript 6.0 razkriva tipe za RegExp.escape pod es2025 libTo pomeni, da lahko pri ciljanju ali vključitvi ES2025 varno napišete pomočnike, kot so:

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

Ni več potrebe po ročno vklopljeni funkciji pobega, TypeScript pa bo v celoti razumel in preveril tipe API-ja. Ta dodatek, tako kot ciljno delo ES2025, je delo Kente Moriuchija.

dom knjižnica zdaj vključuje API-je za iteracijo in asinhrono iteracijo

Zgodovinsko gledano je TypeScript podporo za iteratorje DOM razdelil na dom, dom.iterablein dom.asynciterableČe bi želeli ponoviti NodeList or HTMLCollection z for...of, si moral zapomniti, da dodaš dom.iterable v vašem "lib" konfiguracija poleg domTo je bil pogost vir zmede, še posebej ker vsi sodobni brskalniki podpirajo iterabilne objekte in asinhrone iterabilne objekte v zbirkah DOM.

V TypeScriptu 6.0, lib.dom.iterable.d.ts in lib.dom.asynciterable.d.ts so dejansko združeni v lib.dom.d.tsTo pomeni uporabo "dom" sam zdaj privzeto omogoča iterabilno in asinhrono iterabilno vedenje.

Še vedno lahko omeniš dom.iterable in dom.asynciterable v vašem tsconfig, vendar so te datoteke zdaj prazne lupine. Če je vaša prejšnja konfiguracija izgledala takole:

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

Lahko varno poenostavite na preprosto "dom"in iteracije po zbirkah DOM, kot je document.querySelectorAll("div") bo še vedno preverjal tip:

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

To je majhno, a dobrodošlo čiščenje ki uskladi privzeto knjižnico DOM z realnostjo trenutnih brskalnikov in odstrani še eno težavo pri nastavitvi projekta.

Privzete nastavitve, zastarele in ključne spremembe v TypeScriptu 6.0

Poleg bleščečih API-jev različica 6.0 uvaja nekatere najbolj premišljene spremembe privzetih nastavitev TypeScripta od različice 1.0.Te spremembe odražajo trenutni ekosistem JavaScripta: zimzelena izvajalna okolja, ESM kot osnova, široka uporaba združevalcev in močna želja po strogem tipkanju in zmogljivosti.

Ekipa izpostavlja nekaj splošnih trendov, na katerih temeljijo te odločitveES5 in resnično starejši brskalniki so skoraj izginili; modularni sistemi AMD/UMD so nišni; skoraj vse se zdaj dobavlja kot moduli; strogo tipkanje je norma; in zmogljivost mora ostati v ospredju, še posebej, ker 7.0 prinaša vzporedno preverjanje.

Posledično se TypeScript 6.0 in 7.0 oblikujeta s sodobnimi privzetimi nastavitvami in manj "zastarelimi izhodnimi ventili".Za različico 6.0 RC lahko začasno utišate zastarele različice z nastavitvijo "ignoreDeprecations": "6.0" v vašem tsconfig, vendar te možnosti v različici 7.0 ne bodo več na voljo. Nekatere prilagoditve je mogoče avtomatizirati z orodji, kot je eksperimentalno ts5to6 codemod, ki lahko pomaga pri prepisovanju stvari, kot so baseUrl in rootDir konfiguracije v celotnem projektu.

Dve prilagoditvi, ki ju bo veliko projektov potrebovalo takoj

Čeprav je seznam zastarelih programov dolg, bosta dve spremembi konfiguracije verjetno vplivali na največje število kodnih baz.:

• Izrecno nastavite types matrika (zelo pogosto plus vaš testni okvir). Brez tega boste izgubili samodejno vključene ambientalne tipe iz @types/*.
• Izrecno nastavljeno rootDir (običajno "./src") če bi se zanašali na staro "sklepanje skupnega korena". Sicer bi se lahko struktura vaše izdane datoteke subtilno spremenila.

Simptomi pogrešanja types vključujejo poplavo napak o globalnih vrednostih, kot so process, fs, pathali describe biti nedefiniranSimptomi spremenjenega rootDir gre bolj za izhodne poti, ki nepričakovano pridobijo dodatno src segment (na primer dist/src/index.js Namesto dist/index.js).

Posodobljene privzete nastavitve za sodobne projekte

Več možnosti prevajalnika ima zdaj nove privzete vrednosti, ki se ujemajo s tem, kako je večina novih aplikacij dejansko zgrajenih.:

• strict zdaj privzeto trueStrogi način ni več luksuz, ki ga je treba izbrati, temveč je osnova. Če ste se prej zanašali na nestrogo vedenje, ga boste morali izrecno nastaviti. "strict": false (čeprav boste zamudili veliko kategorijo varnostnih pregledov).
• module zdaj privzeto esnext, kar odraža dejstvo, da je ESM prevladujoča oblika modulov in se najbolje obnese s programi za povezovanje in sodobnimi platformami Node.
• target privzeto je nastavljeno na trenutno leto ECMAScript (trenutno dejansko ES2025), pri čemer se priznava, da je večina uvedb namenjena vedno obstoječim okoljem ali pa se uporablja paketni program, ki lahko po potrebi še bolj zniža raven.
• noUncheckedSideEffectImports Zdaj je true privzeto, kar vam pomaga odkriti tipkarske napake ali slabe poti pri uvozih, ki so vključeni le zaradi stranskih učinkov.
• libReplacement privzeto nastavljeno na false, s čimer se izognemo številnim dodatnim neuspelim reševanjem modulov in nadzoru nad delovanjem, dokler se projekt izrecno ne odloči za specializirano vedenje knjižnic.

Če katera od teh novih privzetih nastavitev pokvari vašo gradnjo, jih je mogoče vse izrecno preglasiti v tsconfig.jsonVendar je namen, da bi novi projekti "preprosto delali pravilno stvar" brez dodatne konfiguracije.

rootDir zdaj privzeto nastavljen na imenik config

Prej, če niste navedli rootDirTypeScript je poskušal sklepati na skupni izvorni koren na podlagi vseh datotek v programu, ki niso deklaracije. Zaradi tega je bilo težje sklepati o mejah projekta in je bilo potrebno pregledati številne poti datotek samo zato, da bi se odločili, kam naj bo emit ukoreninjen.

V TypeScriptu 6.0 je privzeta rootDir je preprosto imenik, ki vsebuje tsconfig.jsonStaro vedenje sklepanja velja le, če zaženete tsc v ukazni vrstici brez kakršnih koli tsconfig nasploh.

Ta sprememba pomeni, da morajo projekti z izvornimi datotekami, ki so globlje od imenika config, izrecno nastaviti rootDirObičajna postavitev bi bila:

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

Če vaša konfiguracija navaja datoteke nad tsconfig lokacijo, boste morali tudi podaljšati rootDir ustrezno, Na primer "rootDir": "../src" za imenike z deljeno izvorno kodo.

types zdaj privzeto na prazno polje

To je verjetno najbolj vplivna sprememba za projekte v resničnem svetu.Zgodovinsko gledano, če niste navedli types in compilerOptions, bi TypeScript samodejno vključil vse pod node_modules/@typesTo je bilo priročno, a tudi drago in krhko: sodobni repozitoriji pogosto pritegnejo na stotine @types paketi tranzitivno.

V TypeScriptu 6.0, types privzeto nastavljeno na [], kar pomeni, da se noben ambientalni paket ne naloži samodejnoZdaj se izrecno odločite za globalna okolja, ki jih dejansko potrebujete, na primer:

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

To lahko pri nekaterih projektih skrajša čas gradnje za 20–50 %, ker prevajalniku ni več treba pregledovati vsake deklaracijske datoteke pod @typesČe resnično želite staro vedenje »naloži vse«, lahko določite:

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

Če se nenadoma pojavijo napake, kot sta »Imena 'proces' ni mogoče najti« ali »Modula 'fs' ni mogoče najti«, to je tvoj znak za dodajanje node (in vse druge vrste testov/izvajalnega okolja, na katere se zanašate) na vaš types matrika.

Zastarelo: target: es5 in --downlevelIteration

Ciljanje na ES5 je zdaj zastarelo.Ker vsi ustrezni brskalniki že leta ponujajo ES2015+ in Internet Explorer upokojen, se izhod ES5 ne šteje več za vreden kompleksnosti znotraj samega TypeScripta. Najnižja podprta ciljna različica v prihodnje je ES5. Če morate resnično ponujati ES2015, je priporočljivo, da uporabite zunanji transpiler (kot je Babel ali bundler pipeline) bodisi na izvorni kodi TS bodisi na izhodu TS.

Naš --downlevelIteration Zastava je tudi zastarela, ker je bil njegov edini smiseln primer uporabe prilagajanje vedenja oddajanja za cilje ES5. V TypeScriptu 6.0 je nastavitev downlevelIteration sploh bo povzročil napako zaradi zastaranja. Če uporabljate ES2015 ali novejšo različico, zastavica tako ali tako ni nikoli imela nobenega učinka.

Zastarelo: --moduleResolution node in zapuščina classic

Naš node (alias node10) način ločljivosti modulov je zastarelModeliral je vedenje Node 10, vendar se ne ujema s sodobnim Node ESM in semantiko ločljivosti. Projekti bi se morali preseliti na enega od njih. nodenext (za neposredne cilje vozlišč) ali bundler (za okolja, ki jih poganjajo paketi, kot so spletne aplikacije ali Bun).

Izvirnik moduleResolution: classic Strategija je bila tudi odstranjenaTo je bila zgodba TypeScripta pred ločljivostjo vozlišč. Danes so vsi praktični scenariji bolje izpolnjeni z nodenext or bundler, zato klasika ni več v uporabi, da bi zmanjšali kompleksnost in zmanjšali število primerov na robu.

Zastarelo: AMD, UMD, SystemJS in module: none

Naslednja module vrednosti so zdaj zastarele in dejansko nepodprte:

• amd
• umd
• systemjs
• none

Te oblike so bile ključne v obdobju pred ESM., ko brskalnikom ni bilo vgrajene podpore za module in so se razvijalci zanašali na AMD, UMD ali SystemJS, da bi zapolnili vrzel. Danes ESM plus združevalci ali uvozne mape obravnavajo praktično vse resnične primere uporabe, »noben« pa ni bil nikoli posebej dobro definiran.

Če še vedno ciljate na te starejše formate modulov, priporočamo selitev proti cilju, ki oddaja ESM, in se za končno pakiranje zanesete na program za povezovanje ali alternativni prevajalnik – ali pa ostanete pri TypeScriptu 5.x, dokler ni vzpostavljen načrt selitve. Kot del tega čiščenja je stari amd-module Tudi direktiva je opuščena.

Zastarelo: baseUrl

Naš baseUrl možnost je že dolgo vir nenavadnega, težko odpravljajočega vedenja pri ločevanju modulovMnogi projekti so ga uporabljali zgolj kot predpono za paths vnosov, vendar ga je TypeScript obravnaval tudi kot splošni iskalni koren, kar je povzročilo uvoze, kot je "someModule" rešiti src/someModule.js nepričakovano, ko je razvijalec želel le podpreti vzdevke po meri, kot je @app/*.

V 6.0, baseUrl je zastarelo in se ne bo več uporabljalo kot iskalni korenPreslikava poti ni potrebna. baseUrl že kar nekaj časa, zato je priporočena migracija preprosto zlaganje predpone v vsako paths vnos. Na primer:

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

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

Le v redkih primerih, ko ste resnično uporabili baseUrl kot generični iskalni koren Bi morali to vedenje reproducirati s preslikavo poti, ki zajema vse, kot je ta:

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

Za večino ekip preprosto odstranite baseUrl in vstavljanje predpon v paths bo tako jasnejše kot varnejše.

Interoperabilnost in strogost: esModuleInterop, allowSyntheticDefaultImportsin alwaysStrict

TypeScript 6.0 prav tako ohranja dolgo priporočeno privzeto vedenje interoperabilnosti.Ne morete več nastaviti esModuleInterop or allowSyntheticDefaultImports do falseTe možnosti so bile prvotno opcijske, da se prepreči prekinitev starejših projektov, vendar njihova izklopljenost danes pogosto vodi do subtilnih težav med izvajanjem pri mešanju CommonJS in ESM.

Če je medsebojno delovanje vedno omogočeno, bo morda treba posodobiti nekatere vzorce uvoza.. Na primer:

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

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

Naš alwaysStrict zastavice tudi ni mogoče nastaviti na false večTypeScript zdaj povsod predvideva semantiko strogega načina JavaScripta, vključno z načinom rezerviranih besed in this vedeti. Če imate res staro kodo, ki je uporabljala rezervirane besede, kot je await or static kot identifikatorje, jih boste morali preimenovati.

Zastarelo: outFile, podedovani imenski prostor module ključna beseda in uvoz asserts

Naš --outFile možnost je odstranjena v različici 6.0Združevanje več vhodnih podatkov v en sam JS sveženj je delo, ki ga bolje opravijo Webpack, Rollup, esbuild, Vite, Parcel ali podobna orodja. TypeScript podvoji preverjanje tipov in deklaracijo, namesto da bi poskušal biti povezovalec.

Zastarela uporaba module deklariranje imenskih prostorov je zdaj težka napakaZgodnji TypeScript je dovoljeval:

module Foo {
  export const bar = 10;
}

Sodobna, podprta sintaksa uporablja namespace:

namespace Foo {
  export const bar = 10;
}

Ta sprememba je potrebna, da se prepreči konflikt z morebitnimi prihodnjimi različicami ECMAScripta. module blokiDeklaracije modulov okolja, kot so declare module "some-module" { ... } ostajajo v celoti podprti.

Uvozi trditve z uporabo asserts so tudi zastareli, ker se je osnovni predlog razvil v atribute uvoza z uporabo withKoda, kot je ta:

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

Prenesti je treba na novo obliko:

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

Zastarelo: no-default-lib reference in seznami datotek ukazne vrstice s tsconfig

Naš /// <reference no-default-lib="true" /> direktiva ni več podprtaPogosto je bilo napačno razumljeno. Če morate izključiti privzeto knjižnico, uporabite --noLib or --libReplacement namesto tega jasneje izražajo namen na ravni konfiguracije.

Drug dolgoletni vir zmede je, kako tsc obravnava eksplicitne argumente datoteke, ko tsconfig.json je prisotenPrej je tekel tsc foo.ts v takem imeniku bi tiho prezrl konfiguracijsko datoteko. V različici 6.0 ta scenarij povzroči eksplicitno napako:

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

Če resnično želite zaobiti konfiguracijo in samo prevesti eno datoteko s privzetimi nastavitvami, zdaj lahko uporabite tsc --ignoreConfig foo.ts da bi ta namen postal jasen.

Priprave na TypeScript 7.0

TypeScript 6.0 je opremljen s številnimi funkcijami in večinoma v načinu stabilizacije.Od zdaj do splošne dostopnosti ekipa pričakuje le kritične popravke napak. Redno se objavljajo nočne različice, ekipa pa pošilja tudi nočne različice prihajajočega izvornega (na osnovi Go) TypeScripta 7.0 skupaj z namensko razširitvijo VS Code za eksperimentiranje z novim mehanizmom.

Načrt je namerno tesen: kmalu zatem naj bi sledila različica 7.0, ki bo sledila različici 6.0., zato bo zanka povratnih informacij o težavah z nadgradnjo in migracijo kratka. Če v različici 6.0 vidite opozorila o zastaranju, je toplo priporočljivo, da jih odpravite zdaj, namesto da čakate, da se težava pojavi v različici 7.0.

Praktični potek dela za večino ekip izgleda takoleNadgradite na TypeScript 6.0 RC, popravite svoj types in rootDir, obravnavajte zastarele (ali jih začasno zaprite "ignoreDeprecations": "6.0" medtem ko ponavljate) in zaženite z --stableTypeOrdering če morate primerjati izhode ali pripraviti cevovode CI za deterministično urejanje različice 7.0. Ko bo to narejeno, bi moral biti prehod na prevajalnik, ki temelji na Go, bolj kot nadgradnja zmogljivosti kot pa prelomna prepis.

Skupno gledano, TypeScript 6.0 RC ni toliko namenjen bleščeči sintaksi in bolj postavljanju temeljev.: izvorna hitrost v različici 7.0, čistejše konfiguracije, sodobne privzete nastavitve in standardizirani API-ji, kot sta vgrajena modula Temporal in ES2025, ki olajšajo vsakodnevno kodiranje. Če ga boste sprejeli zdaj, popravili moteče dele in se osredotočili na nove privzete nastavitve, boste v veliko boljšem položaju, ko bo na voljo izvorni prevajalnik.