„TypeScript 6.0 RC“: funkcijos, svarbiausi pakeitimai ir kaip jiems pasiruošti

Pagrindinis » Pitonas » „TypeScript 6.0 RC“: funkcijos, svarbiausi pakeitimai ir kaip jiems pasiruošti

„TypeScript 6.0“ oficialiai pasiekė išleidimo kandidato (RC) etapą, ir tai ne šiaip dar vienas papildomas atnaujinimas. Tai paskutinė pagrindinė versija, veikianti su ilgalaike „JavaScript“ kompiliatoriaus ir kalbos paslaugos implementacija, prieš pat projektui pereinant prie visiškai naujo, „Go“ pagrindu sukurto variklio „TypeScript 7.0“. Vien tai daro 6.0 versiją esmine: tai tiltas, kurį turite įveikti, kol viskas pasikeis po gaubtu.

Galite pradėti išbandyti RC jau šiandien, įdiegdami jį iš npm su:

npm install -D typescript@rc

Pagrindinė „TypeScript 6.0“ idėja yra paruošimas ir suderinimas.Ši versija sušvelnina kelią nuo 5.9 iki 7.0, sugriežtindama numatytuosius nustatymus, atsisakydama istorinių trūkumų ir pridėdama keletą tikslinių funkcijų, kurios arba atspindi būsimą elgseną, arba atskleidžia būsimas „JavaScript“ galimybes, pvz., „Temporal“, ES2025 API ir „Map“ „upsert“ metodus. Be to, yra keletas subtilių tipų sistemos pakeitimų, naujų kompiliatoriaus vėliavėlių ir numatytųjų konfigūracijos parametrų, kurie neabejotinai paveiks realius projektus, ypač susijusius su... types, rootDir, ir griežtumas.

„TypeScript 6.0“ kaip tiltas į „Go“ pagrindu sukurtą 7.0

„TypeScript 6.0“ yra aiškiai sukurtas kaip galutinis pagrindinis leidimas esamoje „JavaScript“ kodo bazėje.„TypeScript“ komanda perrašė kompiliatorių ir kalbos paslaugą į... vietinis variklis Go, pasinaudojant vietiniu našumu ir bendros atminties lygiagretumu. Šis naujas variklis debiutuos kaip „TypeScript 7.0“ ir naujesnės versijos, o 6.0 yra tiesiai prieš jas kaip pereinamasis etapas.

Dauguma esminių 6.0 versijos pakeitimų ir nebenaudojamų funkcijų yra skirtos užtikrinti, kad būsimas 7.0 versijos atnaujinimas būtų sėkmingas.Parinktys, kurių negalima efektyviai palaikyti gimtojoje architektūroje, senose modulių sistemose ir ilgalaikėse keistenybėse, yra arba pašalinamos, arba aiškiai pažymimos kaip nebenaudojamos, naudojant avarinį liuką: galite nustatyti "ignoreDeprecations": "6.0" į jūsų tsconfig.json kad 6.0 versijoje nebūtų rodoma nebenaudojama diagnostika. Tačiau ši vėliavėlė nepadės 7.0 versijoje – planuojama, kad šios parinktys bus visiškai išnykusios.

Jei prieš atlikdami konfigūracijos valymą esate linkę „laukti 7.0 versijos“, tai yra spąstai.6.0 RC yra versija, kurioje turėtumėte pataisyti savo tsconfig, normalizuoti tipus ir tvarkyti nebenaudojamas vėliavėles. Dviejų didelių šuolių atlikimas (5.x → 7.0) visada pakenks labiau nei perėjimas nuo 5.x → 6.0 → 7.0 su mažesniais, kontroliuojamais pakeitimais.

Kas pasikeitė nuo 6.0 beta versijos

Tarp beta ir RC versijų „TypeScript“ komanda daugiausia dėmesio skyrė elgsenos suderinimui su būsimu 7.0 varikliu., taip pat keletas tikslinių tipų tikrinimo ir DOM tipų nustatymo pakeitimų.

Vienas svarbus pakeitimas turi įtakos bendriniams iškvietimams perduodamų funkcijų išraiškų tipo tikrinimui, ypač JSX kontekstuose. Kai bendrosios funkcijos iškviečiamos su grįžtamosiomis iškvietomis (pavyzdžiui, „React“ ar kituose JSX komponentuose), RC susiaurina išvadas, kad tiksliau atspindėtų 7.0 versijos veiksmus. Praktiškai galite pastebėti, kad kai kuriems iškvietimams, kurie rėmėsi netiesioginėmis išvadomis, dabar reikalingas aiškus tipo argumentas, kad tipo tikrinimas vyktų sklandžiai, tačiau taip pat pastebėsite daugiau tikrų klaidų esamame kode.

Taip pat pratęstas importo teiginių sintaksės nebenaudojimas„TypeScript“ jau perspėjo apie senąjį import ... assert {...} sintaksė statiniuose importavimuose dėl ECMAScript pasiūlymo perėjimo prie importo atributų su withDabar šis nebenaudojimas taikomas ir dinaminiam importavimui naudojant import() su teiginių objektais, tokiais kaip import(..., { assert: {...}})Kryptis aiški: pereiti prie atributų importavimo visur.

DOM bibliotekų tipai buvo atnaujinti, kad atitiktų dabartinius žiniatinklio platformos standartus, įskaitant su laiku susijusių API atnaujinimus žiniatinklio kontekstuose. Jei kuriate naršyklės programas, jums naudingi tikslesni teksto įvedimai ir geresni redagavimo įrankiai, susiję su šiomis naujesnėmis API.

Mažiau jautrus kontekstui funkcijoms, kurios niekada nenaudoja this

„TypeScript 6.0“ pristato subtilų, bet labai praktišką pakeitimą, kaip ji traktuoja funkcijas be aiškaus this naudojimas tipo nustatymo metuIstoriškai funkcijos su parametrais, neturinčiais aiškių tipų, galėjo būti laikomos „kontekstualiai jautriomis“, tai reiškia, kad jų parametras ir this Tipai priklausė nuo to, kur jie buvo naudojami. Tai paveikė bendrąsias išvadas ir gali sukelti keistą elgesį, priklausomai nuo funkcijos sintaksės.

Apsvarstykite bendrą pagalbininką, kuris naudoja gamintojo ir vartotojo porą.:

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

Tačiau su metodo sintakse ankstesnis elgesys gali būti netikėtasTa pati logika, parašyta kaip metodai, gali nepavykti, kai keičiama ypatybių tvarka, nes „TypeScript“ praleidžia „kontekstui jautrias“ funkcijas, nustatydama bendrinius argumentus. Metodai netiesiogiai turi this parametras, kuris juos priskyrė prie tos jautrios kategorijos, net jei this niekada nebuvo iš tikrųjų cituojamas.

6.0 versijoje funkcijos, kurios niekada neskaito this dabar traktuojami kaip mažiau kontekstiniaiKitaip tariant, jei kompiliatorius mato, kad this visai nenaudojamas funkcijos viduje, tai nenubaus tos funkcijos išvados darymo metu. Tai reiškia, kad metodo ir rodyklės sintaksė dabar yra daug nuoseklesnės bendruose išvados darymo scenarijuose, o keistas elgesys „veikia vienoje savybių eilėje, neveikia kitoje“ šiais atvejais išnyksta.

Šis pakeitimas pagerina kandidatų prioritetizavimą tipo nustatymui: funkcijos be naudojamo this tampa aukštesnio prioriteto informacijos šaltiniais, kai daroma išvada dėl tipo argumentų, tokių kaip TPoveikis yra mažiau paslaptingas. unknown tipai ir stabilesnės išvados tarp refaktorių. Šį darbą prisidėjo Mateusz Burzyński.

Palaikymas „Node“ #/ subkelio importavimas

„Mazdo“ „subpath imports“ funkcija leidžia paketams apibrėžti vidinius importo slapyvardžius per imports lauke package.jsonŠie slapyvardžiai supaprastina importavimą, nes vengiama gilių santykinių kelių. Anksčiau kiekvienas antrinio kelio raktas turėjo turėti bent vieną segmentą po pradinio #, o tai buvo nedidelis, bet erzinantis apribojimas žmonėms, įpratusiems sujungti tokias konvencijas kaip @/....

„TypeScript 6.0“ dabar palaiko subkelių importavimą, kuris prasideda #/, suderinant su naujesniu „Node 20“ veikimu. Tai reiškia, kad galite naudoti tokią konfigūraciją:

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

Naudojant šią konfigūraciją, paketo moduliai – ir net vartotojai – gali importuoti per glaustą #/... priešdėlis vietoj ilgų santykinių kelių, pvz. ../../utils.js„TypeScript“ supranta šį šabloną, kai --moduleResolution yra nustatytas į node20, nodenextarba bundler, atspindintis šiuolaikinio „Node“ semantiką. Šį patobulinimą įgyvendino bendradarbis magic-akari.

Naudojant --moduleResolution bundler su --module commonjs

Anksčiau --moduleResolution bundler galėjo būti naudojamas tik su --module esnext or preserveSu vyresniųjų nuvertėjimu node/node10 modulio skiriamosios gebos režimu daugeliui projektų reikėjo migracijos kelio, kuris atitiktų jų dabartinę „CommonJS“ išvestį.

„TypeScript 6.0“ dabar leidžia derinti --moduleResolution bundler su --module commonjsŠis derinys dažnai yra praktiškas žingsnis kodų bazėms, kurios vis dar naudoja „CommonJS“, bet pereina prie paketų pagrindu veikiančių darbo eigų arba naujesnės skiriamosios gebos logikos. Nuo to laiko projektai gali planuoti ilgalaikę migraciją į vieną iš šių būdų:

• module: "preserve" su moduleResolution: "bundler" susietoms žiniatinklio programėlėms ir panašioms sąrankoms arba
• module: "nodenext" aplinkoms, tiesiogiai orientuotoms į šiuolaikinį „Node.js“.

Šis pakeitimas ypač aktualus komandoms, kurios išeina. moduleResolution: node už bet dar nepasiruošęs pilnai pritaikyti ESM išvesties. Vietoj skardžio jis suteikia etapinį maršrutą.

Geriausios --stableTypeOrdering vėliava, skirta 7.0 eiliškumo imitavimui

Vienas iš pagrindinių „TypeScript 7.0“ architektūrinių atnaujinimų yra lygiagretus tipų tikrinimas.Lygiagrečiai vykdant kelis tikrintuvus, skirtingos programos dalys gali būti aplankytos skirtinga tvarka. Jei tipų ID ir simbolių tvarka priklauso nuo apsilankymų tvarkos, galite gauti nedeterministinę sąjungos tvarką, savybių tvarką ir netgi retus diagnostikos skirtumus.

Senesnėse „TypeScript“ versijose vidiniai tipų ID priskiriami pagal susidūrimų tvarkąŠie ID tada naudojami rūšiuoti tokius dalykus kaip sąjungų tipai ir savybės. Štai kodėl, atrodytų, nekenksmingi redagavimai, pavyzdžiui, naujo įvedimas const prieš esamą funkciją – gali apversti literalinių sąjungų tvarką emituojamoje sistemoje .d.ts failus arba pakeiskite kai kurių tipų spausdinimo būdą redaktoriuje.

„TypeScript 7.0“ pereina prie deterministinės, turiniu pagrįstos vidinių objektų tvarkos.Kiekvienas tipas arba simbolis rūšiuojamas pagal savo struktūrą, o ne atsitiktinę lankymo tvarką, todėl ta pati programa nuosekliai pateiks tą pačią tvarką, nepaisant paralelizmo ar kompiliavimo tvarkos. Tai pašalina paslaptį „kodėl mano sąjunga staiga apsivertė?“.

Kad būtų lengviau palyginti 6.0 ir 7.0 elgseną, RC pristato --stableTypeOrderingKai ši vėliavėlė įjungta, „TypeScript 6.0“ taiko tą patį deterministinį tipų tvarkymo algoritmą, kurį naudoja ir 7.0. Dėl to išsiskiriančiuose deklaracijos failuose yra daug mažiau skirtumų, o 6.x ir 7.x išvesčių palyginimai yra labiau nuspėjami.

Tačiau determinizmas nėra laisvas. Įgalinimas --stableTypeOrdering gali sulėtinti tipo tikrinimą iki maždaug 25 %, priklausomai nuo jūsų kodo bazės. Tai skirta kaip diagnostikos ir perkėlimo priemonė, o ne kaip nuolatinis našumo nustatymas.

Jei matote tik spausdinimo klaidas, kai --stableTypeOrdering yra įjungtas, tai paprastai reiškia, kad ankstesnis jūsų kodas rėmėsi senu beveik atsitiktiniu tipų išdėstymu, kad išvados „tiesiog veiktų“. Pataisymai paprastai apima tipų aiškumą – tipo argumento pridėjimą prie probleminio bendro iškvietimo arba kintamojo anotavimą konkrečia sąsaja, užuot visiškai pasikliaujant išvada sudėtingam objektui.

Naujienos es2025 tikslinės ir lib parinktys

„TypeScript 6.0“ prideda es2025 variantas abiems target bei libNors ES2025 neįveda naujos pagrindinės sintaksės, palyginti su ankstesniais metais, jame yra keletas standartizuotų API, kurios anksčiau buvo ribojamos. esnext.

Taikant arba įtraukiant es2025, gausite atnaujintus naujų integruotų elementų tipus kaip RegExp.escape, o kai kurios API yra perkeltos iš esnext į es2025Tai apima tokius dalykus kaip Promise.try, iteratoriaus pagalbininkai ir dar daugiau Set metodai, kurie pasiekė visišką specifikacijos brandą. Šį darbą prisidėjo Kenta Moriuchi.

Platesnė istorija yra ta, kad numatytasis target 6.0 versijoje dabar seka einamuosius ECMAScript metus, kuris šiuo metu, nenurodžius tikslo, faktiškai nukreipia jus į ES2025. Tai geriau atitinka visžalių vykdymo aplinkų ir šiuolaikinių įrankių realybę.

Integruoti „Temporal API“ tipai

Ilgai lauktas pasiūlymas dėl laikinojo įstatymo pasiekė 3 etapą ir tikimasi, kad jis pakeis liūdnai pagarsėjusįjį Date API rimtam datos ir laiko darbui„TypeScript 6.0“ dabar teikia aukščiausios klasės tipizavimo funkcijas, skirtas „Temporal“, todėl galite pradėti rašyti „Temporal“ pagrindu su visišku tipų saugumu ir redaktoriaus palaikymu.

Norėdami įjungti laikinius tipus, galite naudoti --target esnext arba aiškiai sukonfigūruokite savo bibliotekas per kažką panašaus:

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

Arba galite pasirinkti tik laikinį poaibį su "esnext.temporal" jei norite detalesnės konfigūracijos. Įjungę galite rašyti kodą, panašų į:

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

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

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

Kai kuriuose vykdymo aplinkose jau palaikomas laikinas, o kituose gali būti užpildytas polipildžiai., todėl šie tipai yra tikrai tinkami naudoti šiandien. MDN dokumentacija kuriama (kai kurios spragos vis dar pildomos). Tipus pateikė „GitHub“ vartotojas Renegade334.

„Upsert“ palaikymas: Map.getOrInsert bei getOrInsertComputed

„JavaScript“ kūrėjai rankiniu būdu rašė „check-then-set-then-get“ šablonus Map metųĮprastas šablonas patikrina, ar raktas egzistuoja, nustato numatytąją reikšmę, jei ne, ir galiausiai grąžina reikšmę – standartinę reikšmę, kurią lengva suklysti arba kartoti visur.

ECMAScript „upsert“ pasiūlymas (dabar 4 etapas) pristato getOrInsert bei getOrInsertComputed on Map bei WeakMap„TypeScript 6.0“ prideda tipų palaikymą šiems metodams. esnext lib, kad galėtumėte iš karto pradėti rašyti daugiau deklaratyvių „upsert“.

Su getOrInsert, išsamus šablonas, kaip šis:

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

Galima sutraukti į vieną eilutę:

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

Kompanionas getOrInsertComputed idealiai tinka brangiems numatytiesiems dydžiams– jam reikalingas grįžtamasis iškvietimas, kuris iškviečiamas tik tuo atveju, jei trūksta rakto. Šis grįžtamasis iškvietimas netgi gali gauti raktą kaip parametrą, leisdamas jums išgauti numatytąją reikšmę iš paties rakto. „TypeScript“ tipizavimas tiksliai atspindi šį elgesį, vėlgi dėka „Renegade334“ indėlio.

RegExp.escape ir saugesnis reguliariųjų išraiškų kūrimas

Jei kada nors sujungėte vartotojo pateiktas eilutes į reguliariąją išraišką, žinote, kad pirmiausia turite pakeisti specialiuosius simbolius.—tačiau daugumoje kodų bazių escaping kodas arba iš naujo įdiegiamas pagalbinėje sistemoje, arba visiškai pamirštamas. „RegExp Escaping“ pasiūlymas (dabar 4 etapas) tai standartizuoja su RegExp.escape.

„TypeScript 6.0“ atskleidžia tipus, skirtus RegExp.escape pagal es2025 libTai reiškia, kad kai taikote arba įtraukiate ES2025, galite saugiai rašyti pagalbininkus, tokius kaip:

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

Nebereikia rankomis susuktos pabėgimo funkcijos, o „TypeScript“ visiškai supras ir patikrins API tipą. Šį papildymą, kaip ir ES2025 tikslinį darbą, sukūrė Kenta Moriuchi.

dom lib dabar apima iteracijos ir asinchroninės iteracijos API

Istoriškai „TypeScript“ DOM iteratorių palaikymą padalijo į dom, dom.iterableir dom.asynciterableJei norėtumėte pakartoti NodeList or HTMLCollection su for...of, reikėjo nepamiršti pridėti dom.iterable į jūsų "lib" konfigūracija šalia domTai buvo dažnas painiavos šaltinis, ypač turint omenyje, kad visos šiuolaikinės naršyklės palaiko iteruojamus ir asinchroninius iteruojamus elementus DOM rinkiniuose.

„TypeScript 6.0“ versijoje lib.dom.iterable.d.ts bei lib.dom.asynciterable.d.ts yra efektyviai sujungti į lib.dom.d.tsTai reiškia, kad reikia naudoti "dom" dabar pagal numatytuosius nustatymus suteikia iteruojamą ir asinchroninį iteruojamą elgesį.

Vis dar galite paminėti dom.iterable bei dom.asynciterable į jūsų tsconfig, bet tie failai dabar yra tušti apvalkalai. Jei ankstesnė jūsų konfigūracija atrodė taip:

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

Galite drąsiai supaprastinti iki "dom"ir iteracija per DOM rinkinius, pvz., document.querySelectorAll("div") vis tiek atliks tipo patikrinimą:

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

Tai nedidelis, bet laukiamas valymas kuris suderina numatytąją DOM biblioteką su dabartinių naršyklių realybe ir pašalina dar vieną spąstus iš projekto sąrankos.

Numatytieji nustatymai, nebenaudojami nustatymai ir esminiai pakeitimai „TypeScript 6.0“ versijoje

Be blizgančių API, 6.0 versija atlieka kai kuriuos labiausiai vertinamus „TypeScript“ numatytųjų nustatymų pakeitimus nuo 1.0 versijos.Šie pakeitimai atspindi dabartinę „JavaScript“ ekosistemą: visžalius vykdymo aplinkus, ESM kaip bazinę liniją, plačiai paplitusį paketų naudojimą ir didelį poreikį griežtam tipizavimui ir našumui.

Komanda pabrėžia keletą pagrindinių tendencijų, kuriomis grindžiami šie sprendimaiES5 ir iš tiesų pasenusios naršyklės beveik išnyko; AMD/UMD modulių sistemos yra nišinės; beveik viskas dabar pateikiama kaip moduliai; griežtas spausdinimas yra norma; o našumas turi išlikti svarbiausias, ypač turint omenyje, kad 7.0 versijoje atsiranda lygiagretus tikrinimas.

Todėl „TypeScript 6.0“ ir „7.0“ versijos kuriamos su moderniais numatytaisiais nustatymais ir mažiau „senųjų išėjimo vožtuvų“.6.0 RC versijoje galite laikinai nutildyti nebenaudojamus pranešimus nustatydami "ignoreDeprecations": "6.0" į jūsų tsconfig, tačiau šių parinkčių 7.0 versijoje nebus. Kai kuriuos koregavimus galima automatizuoti naudojant tokius įrankius kaip eksperimentinis ts5to6 kodo modifikacija, kuri gali padėti perrašyti tokius dalykus kaip baseUrl bei rootDir konfigūracijos visame projekte.

Daugeliui projektų reikės dviejų korekcijų nedelsiant

Nors nebenaudojamų programų sąrašas yra ilgas, du konfigūracijos pakeitimai greičiausiai paveiks daugiausiai kodų bazių:

• Aiškiai nustatykite types masyvas (labai dažnai plius jūsų testavimo sistema). Be to, prarasite automatiškai įtrauktus aplinkos tipus iš @types/*.
• Aiškiai nustatytas rootDir (dažniausiai "./src") jei rėmėtės senuoju „bendrosios šaknies išvada“. Priešingu atveju jūsų emituoto failo struktūra gali nežymiai pasikeisti.

Dingimo simptomai types įtraukti daugybę klaidų apie globalius dalykus, pvz., process, fs, patharba describe neapibrėžtasPasikeitusių simptomų rootDir labiau susiję su netikėtai įgyjančiais papildomus išvesties kelius src segmentas (pvz. dist/src/index.js VIETOJ dist/index.js).

Atnaujinti numatytieji šiuolaikinių projektų nustatymai

Kelios kompiliatoriaus parinktys dabar turi naujas numatytąsias vertes, kurios atitinka tai, kaip iš tikrųjų kuriamos dauguma naujų programų:

• strict dabar pagal numatytuosius nustatymus trueGriežtas režimas nebėra pasirenkamas prabangos elementas; tai yra bazinis režimas. Jei anksčiau rėmėtės ne griežtu elgesiu, turėsite jį aiškiai nustatyti. "strict": false (nors praleisite didelę saugos patikrinimų kategoriją).
• module dabar pagal numatytuosius nustatymus esnext, atspindintis, kad ESM yra dominuojantis modulio formatas ir geriausiai veikia su paketų kūrėjais ir moderniu „Node“.
• target numatytoji reikšmė yra dabartiniai ECMAScript metai (šiuo metu iš esmės ES2025), pripažįstant, kad dauguma diegimų yra skirti nuolat atnaujinamoms aplinkoms arba vyksta per paketų tvarkyklę, kuri gali sumažinti lygį, kai to tikrai reikia.
• noUncheckedSideEffectImports dabar true pagal nutylėjimą, padėdamas pastebėti rašybos klaidas ar netinkamus kelius importuojant duomenis, kurie įtraukti tik dėl šalutinio poveikio.
• libReplacement pagal nutylėjimą false, išvengiant daugybės papildomų nepavykusių modulių sprendimų ir stebėjimo pridėtinių išlaidų, kol projektas aiškiai nepasirenka specializuotų bibliotekų elgsenos.

Jei kuris nors iš šių naujų numatytųjų nustatymų sugadina jūsų kompiliaciją, juos visus galima aiškiai pakeisti tsconfig.jsonTačiau tikslas yra tas, kad nauji projektai „tiesiog atliktų teisingus veiksmus“ be papildomos konfigūracijos.

rootDir dabar pagal numatytuosius nustatymus yra konfigūracijos katalogas

Anksčiau, jei nenurodėte rootDir„TypeScript“ bandė nustatyti bendrą šaltinio šaknį remiantis visais programoje esančiais nedeklaruojamais failais. Dėl to buvo sunkiau samprotauti apie projekto ribas ir reikėjo nuskaityti daugybę failų kelių vien tam, kad būtų nuspręsta, kur turėtų būti įdiegta „emit“ root teisė.

„TypeScript 6.0“ versijoje numatytasis nustatymas rootDir yra tiesiog katalogas, kuriame yra tsconfig.jsonSenasis išvados darymo elgesys taikomas tik tada, kai paleidžiate tsc komandinėje eilutėje be jokių tsconfig iš viso.

Šis pakeitimas reiškia, kad projektai, kurių šaltinio failai yra giliau nei konfigūracijos katalogas, turėtų būti aiškiai nustatyti rootDirĮprasta konfigūracija būtų tokia:

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

Jei jūsų konfigūracija nurodo failus, esančius aukščiau tsconfig vietą, taip pat turėsite pratęsti rootDir atitinkamai, Pavyzdžiui, "rootDir": "../src" bendrinamiems šaltinio katalogams.

types dabar pagal numatytuosius nustatymus yra tuščias masyvas

Tai bene didžiausias pokytis, turintis įtakos realaus pasaulio projektams.Istoriškai, jei nenurodėte types in compilerOptions„TypeScript“ automatiškai įtrauktų viską po node_modules/@typesTai buvo patogu, bet kartu ir brangu, ir trapu: šiuolaikinės saugyklos dažnai pritraukia šimtus @types paketai tranzityviai.

„TypeScript 6.0“ versijoje types pagal nutylėjimą [], tai reiškia, kad aplinkos tipo paketai nėra įkeliami automatiškaiDabar jūs aiškiai pasirenkate tas globalias aplinkas, kurių jums iš tikrųjų reikia, pavyzdžiui:

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

Kai kuriuose projektuose tai gali sutrumpinti statybos laiką 20–50 %., nes kompiliatoriui nebereikia peržiūrėti kiekvieno deklaracijos failo pagal @typesJei tikrai norite senojo „įkelti viską“ veikimo, galite nurodyti:

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

Jei staiga matote klaidas, pvz., „Nepavyksta rasti pavadinimo „procesas““ arba „Nepavyksta rasti modulio „fs““, tai jūsų ženklas pridėti node (ir bet kokius kitus jūsų naudojamus testavimo / vykdymo aplinkos tipus) types masyvas.

Nebenaudojama: target: es5 bei --downlevelIteration

Orientacija į ES5 dabar nebenaudojamaKadangi visos atitinkamos naršyklės jau daugelį metų teikia ES2015+ ir „Internet Explorer“ nebenaudojamos, ES5 išvestis nebėra laikoma verta sudėtingumo paties „TypeScript“ viduje. Žemiausias palaikomas tikslas nuo šiol yra ES2015. Jei tikrai turite teikti ES5, rekomenduojama naudoti išorinį transpiliatorių (pvz., „Babel“ arba paketavimo konvejerį) arba jūsų TS šaltinyje, arba TS išvestyje.

Geriausios --downlevelIteration vėliava taip pat nebenaudojama, nes vienintelis prasmingas jo naudojimo atvejis buvo koreguoti ES5 taikinių emisijos elgseną. „TypeScript 6.0“ nustatymas downlevelIteration jei iš viso bus pakeista, bus rodoma nebenaudojimo klaida. Jei naudojate ES2015 ar naujesnę versiją, vėliavėlė niekada neturėjo jokio poveikio.

Nebenaudojama: --moduleResolution node ir palikimas classic

Geriausios node (dar žinomas kaip node10) modulio skiriamosios gebos režimas nebenaudojamasJis modeliavo „Node 10“ elgseną, bet neatitinka šiuolaikinio „Node“ ESM ir skiriamosios gebos semantikos. Projektai turėtų būti perkelti į bet kurią iš šių sričių: nodenext (tiesioginiams mazgų taikiniams) arba bundler (skirtoms paketų pagrindu veikiančioms aplinkoms, tokioms kaip žiniatinklio programos arba „Bun“).

Originalas moduleResolution: classic Strategija taip pat buvo pašalintaTai buvo „TypeScript“ istorija prieš „Node“ sprendimą. Šiandien visus praktinius scenarijus geriau tenkina nodenext or bundler, taigi klasikinio stiliaus nebeliko, siekiant sumažinti sudėtingumą ir kraštutinius atvejus.

Nebepalaikoma: AMD, UMD, SystemJS ir module: none

Taip module vertybės dabar yra nebenaudojamos ir faktiškai nepalaikomos:

• amd
• umd
• systemjs
• none

Šie formatai buvo labai svarbūs iki ESM eros., kai naršyklėse trūko vietinio modulių palaikymo ir kūrėjai rėmėsi AMD, UMD arba „SystemJS“, kad užpildytų spragą. Šiandien ESM kartu su paketais arba importavimo žemėlapiais tvarko praktiškai visus realius naudojimo atvejus, o „nė vienas“ niekada nebuvo ypač aiškiai apibrėžtas.

Jei vis dar orientuojatės į šiuos pasenusius modulių formatus, rekomenduojama pereiti prie ESM skleidžiančio tikslo ir galutiniam pakavimui pasikliauti paketavimo įrankiu arba alternatyviu kompiliatoriumi arba likti prie „TypeScript 5.x“, kol bus parengtas perkėlimo planas. Kaip šio valymo dalis, senasis amd-module Direktyva taip pat panaikinama.

Nebenaudojama: baseUrl

Geriausios baseUrl parinktis jau seniai yra keisto, sunkiai derinamo modulio sprendimo elgesio šaltinisDaugelyje projektų jis buvo naudojamas tik kaip priešdėlis. paths įrašai, bet „TypeScript“ taip pat jį laikė bendruoju paieškos šaknies kodu, todėl importavimas, pvz., "someModule" nuspręsti src/someModule.js netikėtai, kai kūrėjas norėjo tik palaikyti pasirinktinius slapyvardžius, pvz. @app/*.

6.0 metais baseUrl yra nebenaudojamas ir nebebus naudojamas kaip paieškos šaknisKelio žemėlapių sudarymas nereikalaujamas. baseUrl gana ilgą laiką, todėl rekomenduojama migracija yra tiesiog sulankstyti prefiksą į kiekvieną paths įrašas. Pavyzdžiui:

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

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

Tik retais atvejais, kai tikrai naudojote baseUrl kaip bendrinė paieškos šaknis Ar reikėtų atkurti tą elgesį naudojant visa apimantį kelio žemėlapį, pvz.:

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

Daugumai komandų tereikia pašalinti baseUrl ir įterptuosius prefiksus paths bus ir aiškiau, ir saugiau.

Sąveika ir griežtumas: esModuleInterop, allowSyntheticDefaultImportsir alwaysStrict

„TypeScript 6.0“ taip pat užfiksuoja tai, kas jau seniai rekomenduojama numatytoji sąveikos elgsenaNebegalite nustatyti. esModuleInterop or allowSyntheticDefaultImports į falseŠios parinktys iš pradžių buvo pasirenkamos siekiant nesugadinti senesnių projektų, tačiau jų išjungimas šiandien dažnai sukelia subtilių vykdymo problemų, kai derinamas „CommonJS“ ir ESM.

Kai sąveika visada įjungta, gali tekti atnaujinti tam tikrus importavimo šablonus.. Pavyzdžiui:

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

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

Geriausios alwaysStrict vėliavos taip pat negalima nustatyti false daugiau ne„TypeScript“ dabar visuose laukuose taiko griežto „JavaScript“ režimo semantiką, įskaitant rezervuotų žodžių ir this elgtis gerai. Jei turite tikrai seną kodą, kuriame buvo naudojami rezervuoti žodžiai, pvz. await or static kaip identifikatorius, turėsite juos pervadinti.

Nebenaudojama: outFile, senoji vardų erdvė module raktinį žodį ir importą asserts

Geriausios --outFile 6.0 versijoje ši parinktis pašalintaKelių įvesčių sujungimas į vieną JS paketą yra užduotis, kurią geriau atlieka „Webpack“, „Rollup“, „esbuild“, „Vite“, „Parcel“ ar panašūs įrankiai. „TypeScript“ dvigubai labiau tikrina tipus ir deklaruoja emit, užuot bandęs būti paketų kūrėju.

Paveldėtas naudojimas module vardų erdvių deklaravimas dabar yra sunki klaidaAnkstyvasis „TypeScript“ leidžiamas:

module Foo {
  export const bar = 10;
}

Šiuolaikinė, palaikoma sintaksė naudoja namespace:

namespace Foo {
  export const bar = 10;
}

Šis pakeitimas yra būtinas siekiant išvengti konfliktų su potencialiais būsimais ECMAScript module blokaiAplinkos modulio deklaracijos, tokios kaip declare module "some-module" { ... } likti visapusiškai remiami.

Importuoti teiginius naudojant asserts taip pat yra nebenaudojami, nes pagrindinis pasiūlymas išsivystė į importo atributus naudojant withKodas, panašus į:

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

Reikėtų perkelti į naują formą:

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

Nebenaudojama: no-default-lib nuorodos ir komandinės eilutės failų sąrašai naudojant „tsconfig“

Geriausios /// <reference no-default-lib="true" /> direktyva nebepalaikomaTai dažnai buvo neteisingai suprantama. Jei reikia neįtraukti numatytosios bibliotekos, naudokite --noLib or --libReplacement vietoj to, kurie aiškiau išreiškia ketinimą konfigūracijos lygmeniu.

Kitas ilgalaikis painiavos šaltinis yra tai, kaip tsc traktuoja aiškius failo argumentus, kai tsconfig.json yraAnksčiau bėgo tsc foo.ts tokiame kataloge tyliai ignoruotų konfigūracijos failą. 6.0 versijoje toks scenarijus sukuria aiškią klaidą:

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

Jei tikrai norite apeiti konfigūraciją ir tiesiog sukompiliuoti vieną failą su numatytosiomis reikšmėmis, dabar galite naudoti tsc --ignoreConfig foo.ts kad tas ketinimas būtų aiškus.

Pasiruošimas „TypeScript 7.0“

„TypeScript 6.0“ turi visas funkcijas ir daugiausia veikia stabilizavimo režimu.Nuo šiol iki bendro prieinamumo komanda tikisi tik kritinių klaidų ištaisymų. Reguliariai skelbiamos naktinės versijos, be to, komanda kasnakt siunčia būsimo gimtosios (Go pagrindu sukurtos) „TypeScript 7.0“ versijas kartu su specialiu „VS Code“ plėtiniu, skirtu eksperimentuoti su naujuoju varikliu.

Veiksmų planas yra sąmoningai griežtas: tikimasi, kad netrukus po 6.0 pasirodys 7.0 versija, todėl grįžtamojo ryšio ciklas apie atnaujinimo problemas ir perkėlimo problemas bus trumpas. Jei 6.0 versijoje matote įspėjimus apie nebenaudojimą, primygtinai rekomenduojama juos spręsti dabar, o ne laukti, kol 7.0 versijoje iškils problema.

Praktinis daugumos komandų darbo eiga atrodo taip: atnaujinkite į „TypeScript 6.0 RC“, pataisykite savo types bei rootDir, spręsti nebenaudojamus dalykus (arba laikinai juos uždrausti) "ignoreDeprecations": "6.0" kol kartojate), ir paleiskite su --stableTypeOrdering jei reikia palyginti išvestis arba paruošti CI srautus 7.0 versijos deterministiniam tvarkymui. Kai tai bus padaryta, perėjimas prie „Go“ pagrindu sukurto kompiliatoriaus turėtų atrodyti kaip našumo pagerinimas, o ne trikdantis perrašymas.

Apibendrinant, „TypeScript 6.0 RC“ yra mažiau apie blizgančią sintaksę ir daugiau apie scenarijaus nustatymą.: vietinis greitis 7.0 versijoje, švaresnės konfigūracijos, modernūs numatytieji nustatymai ir standartizuotos API, tokios kaip integruotos „Temporal“ ir „ES2025“, kurios palengvina kasdienį kodavimą. Jei pritaikysite tai dabar, ištaisysite triukšmingus elementus ir remsitės naujais numatytaisiais nustatymais, būsite daug geresnėje padėtyje, kai pasirodys vietinis kompiliatorius.