TypeScript 6.0 RC: ominaisuudet, tärkeimmät muutokset ja valmistautuminen

Etusivu » Python » TypeScript 6.0 RC: ominaisuudet, tärkeimmät muutokset ja valmistautuminen

TypeScript 6.0 on virallisesti saavuttanut julkaisukandidaatin (RC) virstanpylvään, eikä kyseessä ole vain yksi inkrementaalinen päivitys. Tämä on viimeinen merkittävä versio, joka käyttää kääntäjän ja kielipalvelun pitkäaikaista JavaScript-toteutusta, juuri ennen kuin projekti siirtyy upouuteen, Go-pohjaiseen TypeScript 7.0 -moottoriin. Pelkästään se tekee versiosta 6.0 keskeisen julkaisun: se on silta, joka on tarkoitus ylittää ennen kuin kaikki konepellin alla muuttuu.

Voit aloittaa RC:n kokeilun jo tänään asentamalla sen npm:stä kanssa:

npm install -D typescript@rc

TypeScript 6.0:n ydinajatus on valmistelu ja yhdenmukaistaminen.Tämä versio tasoittaa polkua versiosta 5.9 versioon 7.0 tiukentamalla oletusasetuksia, poistamalla historiallista painolastia ja lisäämällä muutamia kohdennettuja ominaisuuksia, jotka joko peilaavat tulevaa toimintaa tai paljastavat tulevia JavaScript-ominaisuuksia, kuten Temporalin, ES2025-rajapintoja ja Map "upsert" -metodeja. Matkan varrella on joitakin hienovaraisia ​​tyyppijärjestelmän muutoksia, uusia kääntäjälippuja ja määritysoletusarvoja, jotka ehdottomasti vaikuttavat todellisiin projekteihin – erityisesti ... types, rootDirja tiukkuutta.

TypeScript 6.0 siltana Go-pohjaiseen 7.0:aan

TypeScript 6.0 on nimenomaisesti suunniteltu viimeiseksi merkittäväksi julkaisuksi olemassa olevalle JavaScript-koodikannalle.TypeScript-tiimi on kirjoittanut kääntäjän ja kielipalvelun uudelleen muotoon moottori natiivi Gohyödyntäen natiivia suorituskykyä ja jaetun muistin rinnakkaisuutta. Uusi moottori julkaistaan ​​TypeScript 7.0:na ja uudempina versioina, ja 6.0 on aivan sen edessä siirtymävaiheena.

Useimmat version 6.0 ongelmalliset muutokset ja vanhennukset on tehty helpottamaan tulevaa 7.0-päivitystäsi.Vaihtoehtoja, joita ei voida tukea tehokkaasti natiivissa arkkitehtuurissa, vanhoissa moduulijärjestelmissä ja pitkäaikaisissa erikoispiirteissä, joko poistetaan tai ne merkitään selvästi vanhentuneiksi pakoluukun avulla: voit asettaa "ignoreDeprecations": "6.0" oman tsconfig.json poistaa vanhentumisdiagnostiikan versiossa 6.0. Mutta tuo merkintä ei auta sinua versiossa 7.0 – näiden asetusten on tarkoitus kadota kokonaan.

Jos tunnet kiusausta "odottaa versiota 7.0" ennen kokoonpanon siivousta, se on ansa.6.0 RC on versio, jossa sinun on tarkoitus korjata tsconfig, normalisoi tyyppejä ja käsittele vanhentuneita lippuja. Kahden jättimäisen hypyn tekeminen (5.x → 7.0) sattuu aina enemmän kuin siirtyminen versioon 5.x → 6.0 → 7.0 pienemmillä, kontrolloiduilla muutoksilla.

Mitä on muuttunut 6.0 beta-version jälkeen

Beetan ja RC:n välillä TypeScript-tiimi keskittyi pääasiassa toiminnan yhdenmukaistamiseen tulevan 7.0-moottorin kanssa., sekä muutamia kohdennettuja muutoksia tyypin tarkistukseen ja DOM-tyypitykseen.

Yksi tärkeä muutos vaikuttaa yleisiin kutsuihin välitettyjen funktiolausekkeiden tyyppitarkistukseen, erityisesti JSX-yhteyksissä. Kun yleisiä funktioita kutsutaan takaisinkutsuilla (esimerkiksi Reactissa tai muissa JSX-komponenteissa), RC tiukentaa päättelyä, jotta se vastaa tarkemmin 7.0:n toimintaa. Käytännössä saatat huomata, että jotkin implisiittiseen päättelyyn perustuvat kutsut vaativat nyt eksplisiittisen tyyppiargumentin tyyppitarkistuksen onnistumiseksi, mutta löydät myös lisää aitoja virheitä olemassa olevasta koodista.

Tuontiväitteiden syntaksin vanhentumista on myös jatkettuTypeScript varoitti jo vanhasta. import ... assert {...} syntaksi staattisissa tuonneissa, koska ECMAScript-ehdotus siirtyy tuomaan attribuutteja withTämä vanhentuminen koskee nyt myös dynaamisia tuonteja, jotka käyttävät import() väittämäobjekteilla, kuten import(..., { assert: {...}})Suunta on selvä: siirrytään tuomaan ominaisuuksia kaikkialle.

DOM-kirjastotyypit on päivitetty vastaamaan nykyisiä verkkoalustojen standardeja, mukaan lukien päivitykset Temporaliin liittyviin API-rajapintoihin verkkoympäristöissä. Jos rakennat selainsovelluksia, hyödyt näiden uudempien API-rajapintojen tarkemmista kirjoitusasuista ja paremmista editorityökaluista.

Vähemmän kontekstiherkkyyttä funktioille, jotka eivät koskaan käytä this

TypeScript 6.0 tuo mukanaan hienovaraisen mutta erittäin käytännöllisen muutoksen siihen, miten se käsittelee funktioita ilman eksplisiittistä this käyttö tyypin päättelyn aikanaHistoriallisesti funktioita, joiden parametreista puuttui eksplisiittinen tyyppi, voitiin pitää "kontekstiherkkinä", mikä tarkoittaa, että niiden parametri ja this tyypit riippuivat siitä, missä niitä käytettiin. Tämä vaikuttaa yleiseen päättelyyn ja voi johtaa epätavalliseen toimintaan funktion syntaksista riippuen.

Tarkastellaan yleistä apuohjelmaa, joka käyttää tuottaja-kuluttaja-paria.:

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

Mutta metodisyntaksin kanssa aiempi toiminta voi olla yllättävääSama logiikka, metodien tapaan kirjoitettuna, saattaa epäonnistua, kun ominaisuuksia järjestellään uudelleen, koska TypeScript ohitti "kontekstiherkät" funktiot päätellessään yleisiä argumentteja. Metodeilla on implisiittisesti this parametri, joka siirsi heidät kyseiseen arkaluontoiseen luokkaan, vaikka this ei koskaan oikeastaan ​​viitattu.

Versiossa 6.0 funktiot, jotka eivät koskaan lue this käsitellään nyt vähemmän kontekstiherkkinäToisin sanoen, jos kääntäjä näkee, että this ei käytetä lainkaan funktion sisällä, se ei rankaise funktiota päättelyn aikana. Tämä tarkoittaa, että metodin ja nuolen syntaksi ovat nyt paljon yhdenmukaisempia yleisissä päättelyskenaarioissa, ja outo "toimii yhdessä ominaisuusjärjestyksessä, epäonnistuu toisessa" -käyttäytyminen poistuu näissä tapauksissa.

Tämä muutos parantaa ehdokkaiden priorisointia tyypin päättelyä varten.: toiminnot ilman käytettyä this tulevat korkeamman prioriteetin tietolähteiksi pääteltäessä tyyppiargumentteja, kuten TVaikutus on vähemmän mystinen unknown tyypit ja vakaampi päättely refaktorien välillä. Tämän työn on tehnyt Mateusz Burzyński.

Tuki Nodelle #/ alipolkujen tuonnit

Solmun ”alipolkujen tuonnit” -ominaisuus antaa pakettien määrittää sisäisiä tuontialiaksia imports kenttä sisään package.jsonNämä aliakset yksinkertaistavat tuontia välttämällä syviä suhteellisia polkuja. Aiemmin jokaisella alipolkuavaimella piti olla vähintään yksi segmentti alkuperäisen jälkeen. #, mikä oli pieni mutta ärsyttävä rajoitus ihmisille, jotka olivat tottuneet niputtamaan käytäntöjä, kuten @/....

TypeScript 6.0 tukee nyt alipolkujen tuontia, jotka alkavat merkeillä #/, yhdenmukaisesti uudemman Node 20 -toiminnan kanssa. Tämä tarkoittaa, että voit käyttää seuraavanlaista kokoonpanoa:

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

Tämän asetelman avulla paketin sisäiset moduulit – ja jopa kuluttajat – voivat tuoda tietoja ytimekkäästi #/... etuliite pitkien suhteellisten polkujen sijaan, kuten ../../utils.js. TypeScript ymmärtää tämän kuvion, kun --moduleResolution asetetaan node20, nodenexttai bundler, peilaa modernin Noden semantiikkaa. Tämän parannuksen toteutti avustaja magic-akari.

Käyttäminen --moduleResolution bundler --module commonjs

Aiemmin, --moduleResolution bundler voisi käyttää vain --module esnext or preserveVanhempien hylkäämisen myötä node/node10 moduulin resoluutiotilassa monet projektit tarvitsivat siirtopolun, joka sopisi niiden nykyiseen CommonJS-tulosteeseen.

TypeScript 6.0 sallii nyt yhdistämisen --moduleResolution bundler --module commonjsTämä yhdistelmä on usein käytännöllinen askel koodikannoissa, jotka edelleen käyttävät CommonJS:ää, mutta ovat siirtymässä kohti pakettikeskeisiä työnkulkuja tai uudempaa ratkaisulogiikkaa. Siitä eteenpäin projektit voivat suunnitella pidemmän aikavälin siirtymistä jompaankumpaan seuraavista:

• module: "preserve" moduleResolution: "bundler" verkkosovellusten ja vastaavien kokoonpanojen paketoinnissa tai
• module: "nodenext" ympäristöihin, jotka on suunnattu suoraan nykyaikaiselle Node.js:lle.

Tämä muutos on erityisen merkityksellinen lähteville joukkueille. moduleResolution: node takana mutta ei vielä valmis täysin hyödyntämään ESM:n tuottoa. Se tarjoaa vaiheittaisen reitin jyrkänteen sijaan.

--stableTypeOrdering lippu 7.0-järjestyksen jäljittelemiseksi

Yksi TypeScript 7.0:n merkittävimmistä arkkitehtuuripäivityksistä on rinnakkainen tyyppitarkistus.Useiden tarkistusohjelmien suorittaminen rinnakkain tarkoittaa, että ohjelman eri osia voidaan käydä läpi eri järjestyksissä. Jos tyyppi-ID:t ja symbolien järjestys riippuvat vierailujärjestyksestä, voit päätyä epädeterministiseen unionijärjestykseen, ominaisuusjärjestykseen ja jopa harvinaisiin eroihin diagnostiikassa.

Vanhemmat TypeScript-versiot määrittävät sisäiset tyyppi-ID:t kohtaamisjärjestyksen perusteellaNäitä tunnisteita käytetään sitten lajittelemaan asioita, kuten yhdistetyyppejä ja ominaisuuksia. Siksi näennäisesti harmittomat muokkaukset – kuten uuden lisääminen const ennen olemassa olevaa funktiota – voi kääntää literaaliyhdisteiden järjestyksen emittoidussa .d.ts tiedostoja tai muuta joidenkin tyyppien tulostustapaa editorissasi.

TypeScript 7.0 siirtyy deterministiseen, sisältöön perustuvaan järjestykseen sisäisille objekteilleJokainen tyyppi tai symboli lajitellaan rakenteensa mukaan, ei satunnaisen vierailujärjestyksen mukaan, joten sama ohjelma tuottaa johdonmukaisesti saman järjestyksen riippumatta rinnakkaisuudesta tai käännösjärjestyksestä. Tämä poistaa "miksi yhdisteeni yhtäkkiä kääntyi ympäri?" -mysteerin.

Jotta voit vertailla käyttäytymistä versioiden 6.0 ja 7.0 välillä, RC esittelee seuraavat asiat: --stableTypeOrderingKun tämä lippu on käytössä, TypeScript 6.0 käyttää samaa determinististä tyyppien järjestelyalgoritmia kuin 7.0. Tuloksena on paljon vähemmän eroja lähetetyissä määrittelytiedostoissa ja ennustettavammat vertailut 6.x- ja 7.x-tulosteiden välillä.

Determinismi ei kuitenkaan ole ilmaista. Otetaan käyttöön --stableTypeOrdering voi hidastaa tyyppitarkistusta jopa noin 25 % koodikannasta riippuen. Se on tarkoitettu diagnostiikka- ja migraatioavuksi, ei pysyvästi päällä olevaksi suorituskykyasetukseksi.

Jos näet kirjoitusvirheitä vain silloin, kun --stableTypeOrdering on päällä, se yleensä tarkoittaa, että aiempi koodisi luotti vanhaan lähes sattumanvaraiseen tyyppien järjestykseen päättelyn osalta "vain" toimiakseen. Korjaukset sisältävät tyypillisesti tyyppien tekemisen eksplisiittiseksi – tyyppiargumentin lisäämisen ongelmalliseen yleiseen kutsuun tai muuttujan annotoinnin tietyllä rajapinnalla sen sijaan, että monimutkaisen objektin tapauksessa luotettaisiin kokonaan päättelyyn.

Uusi es2025 kohde- ja lib-asetukset

TypeScript 6.0 lisää es2025 vaihtoehto molemmille target ja libVaikka ES2025 ei tuo mukanaan uutta ydinsyntaksia aiempiin vuosiin verrattuna, se sisältää useita standardoituja API-rajapintoja, jotka aiemmin oli suljettu pois. esnext.

Kohdistamalla tai sisällyttämällä es2025saat päivitetyt tyypit uusille sisäänrakennetuille osille pitää RegExp.escape, ja jotkin API:t siirretään pois esnext tulee es2025Se sisältää esimerkiksi Promise.try, iteraattorin apuohjelmat ja muut Set menetelmät, jotka ovat saavuttaneet täyden spesifikaation mukaisen kypsyyden. Tämän työn on tehnyt Kenta Moriuchi.

Laajempi tarina on, että oletusarvoisesti target versiossa 6.0 seuraa nyt kuluvaa ECMAScript-vuotta, joka tällä hetkellä käytännössä vie sinut ES2025:een, jos et määritä tavoitetta. Se vastaa paremmin ikivihreiden suoritusympäristöjen ja nykyaikaisten työkalujen todellisuutta.

Sisäänrakennetut tyypit ajalliseen API:in

Kauan odotettu ajallinen ehdotus on edennyt vaiheeseen 3, ja sen odotetaan korvaavan pahamaineisen Date API vakavaan päivämäärä-/aikatyöhönTypeScript 6.0 tarjoaa nyt ensiluokkaiset tyypitykset Temporaliin, joten voit aloittaa Temporaliin perustuvan koodin kirjoittamisen täydellä tyyppiturvallisuudella ja editorituella.

Voit ottaa käyttöön ajalliset tyypit käyttämällä --target esnext tai määritä kirjastosi erikseen jonkin seuraavan kautta:

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

Tai voit valita vain ajallisen osajoukon käyttämällä "esnext.temporal" jos haluat tarkemman kokoonpanon. Kun se on otettu käyttöön, voit kirjoittaa koodia seuraavanlaisesti:

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

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

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

Temporaalia tuetaan jo joissakin suoritusympäristöissä ja sitä voidaan täyttää moninkertaisesti toisissa, joten nämä tyypit ovat aidosti käyttökelpoisia tänä päivänä. MDN:ään on tulossa dokumentaatiota (ja joitakin aukkoja täytetään edelleen). Tyypittelyt on tehnyt GitHub-käyttäjä Renegade334.

Upsert-tuki: Map.getOrInsert ja getOrInsertComputed

JavaScript-kehittäjät ovat kirjoittaneet manuaalisesti ”check-then-set-then-get” -kuvioita Map vuosiaTyypillinen malli tarkistaa, onko avain olemassa, asettaa oletusarvon, jos ei, ja palauttaa lopulta arvon – vakioarvon, joka on helppo erehtyä tai toistaa kaikkialla.

ECMAScriptin ”upsert”-ehdotus (nyt vaihe 4) esittelee getOrInsert ja getOrInsertComputed on Map ja WeakMapTypeScript 6.0 lisää tyyppituen näille metodeille. esnext lib, joten voit alkaa kirjoittaa deklaratiivisempia upserttejä heti.

Kanssa getOrInsert, tällainen monisanainen kuvio:

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

Voidaan kutistaa yhdelle riville:

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

Seuralainen getOrInsertComputed sopii erinomaisesti kalliisiin maksuhäiriöihin—se ottaa vastaan ​​takaisinkutsutoiminnon, jota kutsutaan vain, jos avain puuttuu. Tämä takaisinkutsutoiminto voi jopa vastaanottaa avaimen parametrina, jolloin voit johtaa oletusarvon itse avaimesta. TypeScriptin tyypitykset kuvaavat näitä toimintoja tarkasti, jälleen Renegade334:n panosten ansiosta.

RegExp.escape ja turvallisempi regex-rakentaminen

Jos olet joskus yhdistänyt käyttäjän syöttämiä merkkijonoja säännölliseksi lausekkeeksi, tiedät, että sinun on ensin poistettava erikoismerkit.—mutta useimmat koodikannat joko toteuttavat escape-merkinnän uudelleen apukoodissa tai unohtavat sen kokonaan. RegExp Escaping -ehdotus (nyt vaihe 4) standardoi tämän RegExp.escape.

TypeScript 6.0 paljastaa tyypit seuraaville: RegExp.escape alla es2025 libTämä tarkoittaa, että kun kohdistat tai sisällytät ES2025:n, voit turvallisesti kirjoittaa apuohjelmia, kuten:

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

Ei enää tarvetta käsin rullatulle pakotoiminnolle, ja TypeScript ymmärtää ja tyyppitarkistaa API:n täysin. Tämä lisäys, kuten ES2025-kohdetyökin, on Kenta Moriuchilta.

dom lib sisältää nyt iteraatio- ja asynkronisen iteraatio-API:t

Historiallisesti TypeScript jakoi DOM-iteraattorituen kahteen osaan dom, dom.iterableja dom.asynciterableJos haluat iteroida uudelleen NodeList or HTMLCollection for...ofpiti muistaa lisätä dom.iterable oman "lib" kokoonpano rinnalla domTämä oli yleinen hämmennyksen lähde, varsinkin kun kaikki nykyaikaiset selaimet tukevat iteroitavia ja asynkronisia iteroitavia objekteja DOM-kokoelmissa.

TypeScript 6.0:ssa lib.dom.iterable.d.ts ja lib.dom.asynciterable.d.ts ovat tehokkaasti yhdistettyjä lib.dom.d.tsSe tarkoittaa käyttöä "dom" yksin antaa nyt oletuksena iteroitavan ja asynkronisen iteroitavan toiminnan.

Voit silti mainita dom.iterable ja dom.asynciterable oman tsconfig, mutta nuo tiedostot ovat nyt tyhjiä komentotulkkeja. Jos edellinen kokoonpanosi näytti tältä:

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

Voit turvallisesti yksinkertaistaa muotoon "dom"ja iterointia DOM-kokoelmien, kuten document.querySelectorAll("div") tyyppitarkastus tehdään edelleen:

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

Tämä on pieni mutta tervetullut siivous joka yhdenmukaistaa oletus-DOM-kirjaston nykyisten selainten todellisuuden kanssa ja poistaa projektin asetuksista jälleen yhden ongelman.

Oletusarvot, vanhennukset ja rikkinäiset muutokset TypeScript 6.0:ssa

Hienojen API-rajapintojen lisäksi 6.0 tekee joitakin mielipiteellisimmistä muutoksista TypeScriptin oletusasetuksiin sitten 1.0:n.Nämä muutokset heijastavat nykyistä JavaScript-ekosysteemiä: ikivihreitä ajonaikaisia ​​ympäristöjä, ESM:ää lähtökohtana, pakettien laajamittaista käyttöä ja vahvaa kysyntää tarkkaan tyypitykseen ja suorituskykyyn.

Tiimi korostaa muutamia näiden päätösten taustalla olevia yleisiä trendejäES5 ja aidosti vanhat selaimet ovat lähes poissa; AMD/UMD-moduulijärjestelmät ovat niche-tyyppisiä; lähes kaikki toimitetaan nyt moduuleina; tarkka näppäily on normi; ja suorituskyvyn on pysyttävä etusijalla, varsinkin kun 7.0 tuo mukanaan rinnakkaistarkistuksen.

Tämän seurauksena TypeScript 6.0 ja 7.0 muotoillaan moderneilla oletusarvoilla ja vähemmillä "vanhoilla pakoventtiileillä".Versiossa 6.0 RC voit tilapäisesti hiljentää vanhentumiset asettamalla "ignoreDeprecations": "6.0" oman tsconfig, mutta näitä vaihtoehtoja ei ole versiossa 7.0. Jotkin säädöt voidaan automatisoida työkaluilla, kuten kokeellisella ts5to6 codemod, joka voi auttaa kirjoittamaan uudelleen asioita, kuten baseUrl ja rootDir konfiguraatioita koko projektin ajan.

Kaksi muutosta, joita monet projektit tarvitsevat välittömästi

Vaikka vanhentumislista on pitkä, kaksi kokoonpanomuutosta todennäköisesti pureutuvat suurimmalle määrälle koodikantoja:

• Aseta eksplisiittisesti types ryhmä (hyvin usein sekä testikehyksesi). Ilman tätä menetät automaattisesti sisällytetyt ympäristötyypit @types/*.
• Eksplisiittisesti asetettu rootDir (yleisesti "./src") jos luotit vanhaan "yhteisen juuren päättelyyn". Muuten lähetetyn tiedoston rakenne saattaa muuttua hienovaraisesti.

Kadonneen oireet types sisältää tulvan virheitä globaaleista arvoista, kuten process, fs, pathtai describe olematta määrittelemätönMuuttuneen rootDir koskevat enemmän lähtöreittejä, jotka saavat odottamatta ylimääräisen src segmentti (esim. dist/src/index.js sijasta dist/index.js).

Päivitetyt oletusarvot nykyaikaisille projekteille

Useilla kääntäjäasetuksilla on nyt uudet oletusarvot, jotka vastaavat sitä, miten useimmat uudet sovellukset todellisuudessa rakennetaan.:

• strict nyt oletusarvoisesti trueTiukka tila ei ole enää valinnainen ylellisyys, vaan se on perustason toiminto. Jos aiemmin luotit ei-tiukkaan toimintaan, sinun on asetettava se erikseen. "strict": false (vaikka jääkin tekemättä useita tärkeitä turvatarkastuksia).
• module nyt oletusarvoisesti esnext, mikä heijastaa sitä, että ESM on hallitseva moduulimuoto ja toimii parhaiten niputtavien moduulien ja modernin Node:n kanssa.
• target oletusarvoisesti nykyinen ECMAScript-vuosi (käytännössä ES2025 juuri nyt), ottaen huomioon, että useimmat käyttöönotot kohdistuvat ainaviin ympäristöihin tai menevät läpi pakettityökalun, joka voi tarvittaessa alentaa tasoa.
• noUncheckedSideEffectImports on nyt true oletuksena, auttaen sinua havaitsemaan kirjoitusvirheitä tai huonoja polkuja tuonneissa, jotka on sisällytetty vain sivuvaikutusten vuoksi.
• libReplacement oletuksena false, välttäen joukon ylimääräisiä epäonnistuneiden moduulien ratkaisuja ja valvontakuormitusta, kunnes projekti nimenomaisesti valitsee erikoistuneet kirjastotoiminnot.

Jos jokin näistä uusista oletusasetuksista rikkoo kokoonpanosi, ne voidaan kaikki korvata erikseen kohdassa tsconfig.jsonMutta tarkoituksena on, että uusien projektien tulisi "vain tehdä oikein" ilman ylimääräistä konfigurointia.

rootDir oletusarvoisesti asetushakemisto

Jos et aiemmin määrittänyt rootDir, TypeScript yritti päätellä yhteisen lähdejuurilähteen perustuu kaikkiin ohjelman ei-deklarointitiedostoihin. Tämä vaikeutti projektirajojen päättelyä ja vaati useiden tiedostopolkujen skannaamista vain sen päättämiseksi, mihin emit tulisi roottata.

TypeScript 6.0:ssa oletusarvo rootDir on yksinkertaisesti hakemisto, joka sisältää tsconfig.jsonVanha päättelykäytäntö pätee vain, kun suoritat tsc komentorivillä ilman mitään tsconfig ollenkaan.

Tämä muutos tarkoittaa, että projektien, joiden lähdetiedostot sijaitsevat myöhemmällä hakemistolla kuin config-hakemisto, tulisi asettaa erikseen rootDirYleinen järjestely olisi:

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

Jos konfiguraatiosi viittaa tiedostoihin, jotka ovat edellä tsconfig sijainti, sinun on myös laajennettava rootDir sen mukaisesti, esimerkiksi "rootDir": "../src" jaettuja lähdekoodihakemistoja varten.

types oletusarvoisesti tyhjä taulukko

Tämä on luultavasti vaikuttavin muutos tosielämän projekteissaHistoriallisesti, jos et määrittänyt types in compilerOptions, TypeScript sisällyttäisi automaattisesti kaiken alle node_modules/@typesSe oli kätevää, mutta myös kallista ja haurasta: nykyaikaiset repot vetävät usein sisään satoja @types paketit transitiivisesti.

TypeScript 6.0:ssa types oletuksena [], eli ambient-tyyppisiä paketteja ei ladata automaattisestiNyt voit erikseen valita tarvitsemasi globaalit ympäristöt, esimerkiksi:

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

Tämä voi lyhentää rakennusaikaa joissakin projekteissa 20–50 %., koska kääntäjän ei enää tarvitse käydä läpi kaikkia määrittelytiedostoja @typesJos todella haluat vanhan "lataa kaikki" -toiminnon, voit määrittää:

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

Jos näet yhtäkkiä virheitä, kuten ”Prosessin nimeä 'prosessi' ei löydy” tai ”Moduulia 'fs' ei löydy”, siinäpä sinun merkkisi lisätä node (ja kaikki muut käyttämäsi testi-/suoritusympäristötyypit) types ryhmä.

Vanhentunut: target: es5 ja --downlevelIteration

ES5-kohdentaminen on nyt vanhentunutKoska kaikki asiaankuuluvat selaimet ovat toimittaneet ES2015+:ta jo vuosia ja Internet Explorer on poistettu käytöstä, ES5:n tulostetta ei enää pidetä TypeScriptin sisäisen monimutkaisuuden arvoisena. Jatkossa alhaisin tuettu kohde on ES2015. Jos sinun todella on toimitettava ES5, suositellaan ulkoisen siirtäjän (kuten Babelin tai bundler-putken) käyttöä joko TS-lähteessäsi tai TS:n tulosteessa.

--downlevelIteration lippu on myös vanhentunut, koska sen ainoa mielekäs käyttötapaus oli ES5-kohteiden emit-käyttäytymisen säätäminen. TypeScript 6.0:ssa asettaminen downlevelIteration ollenkaan aiheuttaa vanhentumisvirheen. Jos käytät ES2015:tä tai uudempaa, lipulla ei ole koskaan ollut mitään vaikutusta.

Vanhentunut: --moduleResolution node ja perintö classic

node (Aka node10) moduulin resoluutiotila on vanhentunutSe mallinsi Node 10:n toimintaa, mutta ei vastaa nykyisen Node ESM:n ja resoluution semantiikkaa. Projektien tulisi siirtyä jompaankumpaan nodenext (suorille solmukohteille) tai bundler (pakettipohjaisille ympäristöille, kuten verkkosovelluksille tai Bunille).

Alkuperäinen moduleResolution: classic strategia on myös poistettuTämä oli TypeScriptin tarina ennen Node-ratkaisua. Nykyään kaikki käytännön skenaariot palvelevat paremmin nodenext or bundler, joten klassinen on poissa monimutkaisuuden ja reunatapausten vähentämiseksi.

Vanhentuneet: AMD, UMD, SystemJS ja module: none

Seuraavat module arvot ovat nyt vanhentuneita ja käytännössä tuettomia:

• amd
• umd
• systemjs
• none

Nämä formaatit olivat ratkaisevan tärkeitä ennen EVM:n aikakautta, kun selaimista puuttui natiivi moduulituki ja kehittäjät turvautuivat AMD:hen, UMD:hen tai SystemJS:ään täyttääkseen aukon. Nykyään ESM ja niputtajat tai tuontikartat käsittelevät käytännössä kaikki todelliset käyttötapaukset, eikä "ei mitään" ole koskaan ollut erityisen hyvin määritelty.

Jos kohdistat edelleen näihin vanhoihin moduulimuotoihin, suositus on siirtyä kohti ESM:ää lähettävää kohdetta ja luottaa lopulliseen pakkaamiseen niputtajaan tai vaihtoehtoiseen kääntäjään – tai pysyä TypeScript 5.x:ssä, kunnes siirtosuunnitelma on käytössä. Osana tätä siivousta vanha amd-module Myös direktiivi hylätään.

Vanhentunut: baseUrl

baseUrl vaihtoehto on pitkään ollut oudon ja vaikeasti virheenkorjattavan moduulien resoluutiokäyttäytymisen lähdeMonissa projekteissa sitä käytettiin pelkästään etuliitteenä paths merkintöjä, mutta TypeScript käsitteli sitä myös yleisenä hakusanan juurena, mikä aiheutti tuonnit, kuten "someModule" päättää src/someModule.js odottamatta, kun kehittäjän ainoa tarkoitus oli tukea mukautettuja aliaksia, kuten @app/*.

Vuonna 6.0, baseUrl on vanhentunut eikä sitä enää käytetä hakupääkohteenaPolkujen kartoitusta ei ole vaadittu. baseUrl jo jonkin aikaa, joten suositeltu siirto on yksinkertaisesti taittaa etuliite jokaiseen paths merkintä. Esimerkiksi:

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

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

Vain harvoissa tapauksissa, joissa todella käytit baseUrl yleisenä hakujuuritasona pitäisikö sinun toistaa kyseinen toiminta käyttämällä yleispätevää polkukartoitusta, kuten:

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

Useimmille joukkueille riittää yksinkertaisesti poistamalla baseUrl ja rivinväliset etuliitteet paths on sekä selkeämpi että turvallisempi.

Yhteentoimivuus ja tiukkuus: esModuleInterop, allowSyntheticDefaultImportsja alwaysStrict

TypeScript 6.0 lukitsee myös pitkään suositellun oletusarvoisen yhteensopivuuskäyttäytymisen.Et voi enää asettaa esModuleInterop or allowSyntheticDefaultImports että falseNämä asetukset olivat alun perin valinnaisia ​​vanhempien projektien rikkoutumisen välttämiseksi, mutta niiden pitäminen pois päältä johtaa nykyään usein hienovaraisiin ajonaikaisiin ongelmiin CommonJS:ää ja ESM:ää yhdistettäessä.

Kun yhteentoimivuus on aina käytössä, tiettyjä tuontimalleja on ehkä päivitettävä.. Esimerkiksi:

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

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

alwaysStrict lippua ei myöskään voi asettaa arvoon false enää. TypeScript olettaa nyt JavaScriptin tiukan tilan semantiikan kaikkialla, mukaan lukien varattujen sanojen ja this käyttäytyä. Jos sinulla on todella vanhaa koodia, jossa on käytetty varattuja sanoja, kuten await or static tunnisteina sinun on nimettävä ne uudelleen.

Vanhentunut: outFile, vanha nimiavaruus module avainsana ja tuonti asserts

--outFile vaihtoehto poistetaan versiosta 6.0Useiden syötteiden yhdistäminen yhdeksi JS-paketiksi on tehtävä, joka onnistuu paremmin Webpackilla, Rollupilla, esbuildilla, Vitellä, Parcelilla tai vastaavilla työkaluilla. TypeScript tehostaa tyypin tarkistusta ja emit-deklarointia sen sijaan, että se yrittäisi olla niputtaja.

Perinteinen käyttö module nimiavaruuksien määrittäminen on nyt vaikea virheVarhainen TypeScript sallittu:

module Foo {
  export const bar = 10;
}

Moderni, tuettu syntaksi käyttää namespace:

namespace Foo {
  export const bar = 10;
}

Tämä muutos on välttämätön, jotta vältetään törmäykset mahdollisten tulevien ECMAScript-koodien kanssa. module lohkotAmbient-moduulien määrittelyt, kuten declare module "some-module" { ... } pysyvät täysin tuettuina.

Tuo väitteitä käyttämällä asserts ovat myös vanhentuneita, koska pohjana oleva ehdotus kehittyi tuontiattribuuteiksi käyttämällä withKoodi kuten:

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

Pitäisi siirtää uuteen lomakkeeseen:

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

Vanhentunut: no-default-lib viitteet ja komentorivitiedostoluettelot tsconfig-komennolla

/// <reference no-default-lib="true" /> direktiiviä ei enää tuetaSe ymmärrettiin usein väärin. Jos sinun on poistettava oletuskirjasto, käytä --noLib or --libReplacement sen sijaan, jotka ilmaisevat selkeämmin tarkoituksen kokoonpanotasolla.

Toinen pitkään jatkunut hämmennyksen lähde on se, miten tsc käsittelee eksplisiittisiä tiedostoargumentteja, kun tsconfig.json on läsnäAiemmin juokseminen tsc foo.ts tällaisessa hakemistossa ohittaisi hiljaisesti asetustiedoston. Versiossa 6.0 tämä skenaario tuottaa eksplisiittisen virheen:

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

Jos todella haluat ohittaa konfiguroinnin ja kääntää vain yhden tiedoston oletusarvoilla, voit nyt käyttää tsc --ignoreConfig foo.ts tehdäkseen tuon aikomuksen selväksi.

Valmistautuminen TypeScript 7.0:aan

TypeScript 6.0 on ominaisuuksiltaan täydellinen ja enimmäkseen vakautustilassaTästä lähtien yleiseen saatavuuteen asti tiimi odottaa vain kriittisten virheenkorjauksia. Yöllisiä koontiversioita julkaistaan ​​säännöllisesti, ja tiimi toimittaa myös tulevan natiivin (Go-pohjaisen) TypeScript 7.0:n yöversioita sekä erillisen VS Code -laajennuksen uuden moottorin kokeilua varten.

Etenemissuunnitelma on tarkoituksella tiukka: version 7.0 odotetaan seuraavan pian versiota 6.0., joten päivityskipua ja siirto-ongelmia koskeva palautesilmukka on lyhyt. Jos näet vanhenemisvaroituksia versiossa 6.0, vahva suositus on puuttua niihin nyt sen sijaan, että odotettaisiin, kunnes versio 7.0 pakottaa ongelman ilmenemään.

Useimpien tiimien käytännön työnkulku näyttää tältäPäivitä TypeScript 6.0 RC:hen ja korjaa ongelmasi. types ja rootDir, käsittele vanhentuneita ominaisuuksia (tai sulje ne väliaikaisesti "ignoreDeprecations": "6.0" samalla kun iteroit), ja suorita --stableTypeOrdering jos sinun täytyy vertailla tulosteita tai valmistella CI-putkia 7.0:n determinististä järjestystä varten. Kun tämä on tehty, siirtymisen Go-pohjaiseen kääntäjään pitäisi tuntua suorituskyvyn parannukselta eikä rikkovalta uudelleenkirjoitukselta.

Yhteenvetona voidaan todeta, että TypeScript 6.0 RC keskittyy vähemmän kiiltävään syntaksiin ja enemmän lavasteiden luomiseen.natiivi nopeus versiossa 7.0, siistimmät kokoonpanot, modernit oletusasetukset ja standardoidut API-rajapinnat, kuten Temporal ja ES2025, jotka helpottavat päivittäistä koodausta. Jos otat sen käyttöön nyt, korjaat kohinaiset kohdat ja nojaat uusiin oletusasetuksiin, olet paljon paremmassa asemassa, kun natiivi kääntäjä saapuu.