TypeScript 6.0 RC: caracteristici, modificări importante și cum să vă pregătiți

Acasă » Piton » TypeScript 6.0 RC: caracteristici, modificări importante și cum să vă pregătiți

TypeScript 6.0 a atins oficial pragul de lansare candidată (RC)...și nu este doar o altă actualizare incrementală. Aceasta este ultima versiune majoră care rulează pe implementarea JavaScript de lungă durată a compilatorului și a serviciului lingvistic, chiar înainte ca proiectul să treacă la un motor complet nou, bazat pe Go, în TypeScript 7.0. Numai acest lucru face din versiunea 6.0 o versiune esențială: este podul pe care trebuie să-l traversați înainte ca tot ce se află sub capotă să se schimbe.

Poți începe să încerci RC chiar azi instalându-l din npm cu:

npm install -D typescript@rc

Ideea centrală din spatele TypeScript 6.0 este pregătirea și aliniereaAceastă versiune facilitează trecerea de la versiunea 5.9 la 7.0, restrângând setările implicite, depreciind bagajul istoric și adăugând câteva funcții specifice care fie reflectă comportamentul viitor, fie expun capabilități JavaScript viitoare, cum ar fi Temporal, API-urile ES2025 și metodele Map „upsert”. Pe parcurs, există câteva modificări subtile ale sistemului de tip, noi semnalizatoare de compilare și setări implicite de configurare care vor afecta absolut proiectele reale - în special în jurul... types, rootDirși strictețe.

TypeScript 6.0 ca punte către versiunea 7.0 bazată pe Go

TypeScript 6.0 este conceput în mod explicit ca ultima versiune majoră a bazei de cod JavaScript existente.Echipa TypeScript a rescris compilatorul și serviciul lingvistic într-un motor nativ în Go, profitând de performanța nativă și de paralelismul cu memorie partajată. Noul motor va debuta ca TypeScript 7.0 și versiuni ulterioare, iar versiunea 6.0 se află chiar înaintea lui ca o etapă de tranziție.

Majoritatea modificărilor și deprecierilor majore din versiunea 6.0 sunt menite să facă viitoarea actualizare la versiunea 7.0 supraviețuitoare.Opțiunile care nu pot fi suportate eficient în arhitectura nativă, sistemele de module vechi și particularitățile persistente sunt fie eliminate, fie marcate clar ca depreciate cu o trapă de urgență: puteți seta "ignoreDeprecations": "6.0" în ta tsconfig.json pentru a suprima diagnosticarea deprecierii în versiunea 6.0. Dar acel indicator nu te va ajuta în versiunea 7.0 - acele opțiuni sunt planificate să dispară complet.

Dacă ești tentat să „aștepți versiunea 7.0” înainte de a face orice curățare a configurației, aceasta este o capcană.Versiunea 6.0 RC este cea în care ar trebui să vă reparați tsconfig, normalizați tipurile și gestionați steagurile depreciate. Efectuarea a două salturi uriașe (5.x → 7.0) va afecta întotdeauna mai mult decât trecerea de la 5.x → 6.0 → 7.0 cu modificări mai mici, controlate.

Ce s-a schimbat de la versiunea beta 6.0

Între versiunea beta și cea RC, echipa TypeScript s-a concentrat în principal pe alinierea comportamentului cu viitorul motor 7.0., plus câteva modificări specifice la verificarea tipurilor și la tipizarea DOM.

O modificare importantă are impact asupra verificării tipurilor expresiilor de funcții transmise apelurilor generice, în special în contexte JSX. Când funcțiile generice sunt invocate cu apeluri inverse (de exemplu în React sau alte componente JSX), RC restricționează inferența astfel încât să reflecte mai precis ceea ce va face versiunea 7.0. În practică, este posibil să observați că unele apeluri care se bazau pe inferență implicită necesită acum un argument explicit de tip pentru a menține verificarea tipului satisfăcătoare, dar veți observa și mai multe erori reale în codul existent.

Deprecierea sintaxei aserțiunilor de import a fost, de asemenea, extinsă.TypeScript avertiza deja împotriva vechiului import ... assert {...} sintaxa în importurile statice datorită trecerii propunerii ECMAScript la importul de atribute cu withAcum, această depreciere se aplică și importurilor dinamice care utilizează import() cu obiecte de aserțiune precum import(..., { assert: {...}})Direcția este clară: treceți la importarea atributelor peste tot.

Tipurile de biblioteci DOM au fost actualizate pentru a se potrivi standardelor actuale ale platformei web, inclusiv actualizări ale API-urilor legate de Temporal în contexte web. Dacă construiți aplicații de browser, beneficiați de tastări mai precise și de instrumente de editare mai bune în jurul acestor API-uri mai noi.

Sensibilitate contextuală mai mică pentru funcțiile care nu folosesc niciodată this

TypeScript 6.0 introduce o modificare subtilă, dar foarte practică, în modul în care tratează funcțiile fără o definiție explicită. this utilizare în timpul inferenței de tipDin punct de vedere istoric, funcțiile cu parametri lipsiți de tipuri explicite puteau fi considerate „sensibile contextual”, adică parametrii și this Tipurile depindeau de locul în care erau utilizate. Acest lucru influențează inferența generică și poate duce la un comportament ciudat în funcție de sintaxa funcției.

Luați în considerare un helper generic care folosește o pereche producător-consumator:

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

Dar cu sintaxa metodei, comportamentul anterior ar putea fi surprinzătorAceeași logică, scrisă ca metode, ar putea eșua atunci când proprietățile sunt reordonate, deoarece TypeScript a omis funcțiile „sensibile contextual” atunci când a dedus argumente generice. Metodele au implicit un this parametru, care i-a plasat în acea categorie sensibilă chiar dacă this nu a fost niciodată menționată de fapt.

În 6.0, funcțiile care nu citesc niciodată this sunt acum tratate ca fiind mai puțin sensibile din punct de vedere contextualCu alte cuvinte, dacă compilatorul vede că this Dacă nu este utilizată deloc în interiorul unei funcții, nu va penaliza funcția respectivă în timpul inferenței. Aceasta înseamnă că sintaxa metodei și sintaxa săgeților sunt acum mult mai consistente în scenariile de inferență generică, iar comportamentul ciudat „funcționează într-o ordine a proprietăților, eșuează în alta” dispare în aceste cazuri.

Această modificare îmbunătățește prioritizarea candidaților pentru inferența de tip: funcții fără a fi utilizate this devin surse de informații cu prioritate mai mare atunci când se deduc argumente de tip precum TEfectul este mai puțin misterios unknown tipuri și o inferență mai stabilă între refactori. Această lucrare a fost realizată de Mateusz Burzyński.

Suport pentru Node #/ importuri de subcale

Funcția „import subpath” a Node permite pachetelor să definească aliasuri interne de import prin intermediul imports câmp în package.jsonAceste aliasuri simplifică importurile prin evitarea căilor relative profunde. Anterior, fiecare cheie de subcale trebuia să aibă cel puțin un segment după cheia inițială. #, ceea ce era o limitare mică, dar enervantă, pentru cei obișnuiți să grupeze convenții precum @/....

TypeScript 6.0 acceptă acum importuri de subcăi care încep cu #/, aliniindu-se cu comportamentul mai nou al Node 20. Aceasta înseamnă că puteți utiliza o configurație de genul:

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

Cu această configurație, modulele din interiorul pachetului - și chiar consumatorii - pot fi importate printr-o linie concisă #/... prefix în loc de căi relative lungi, cum ar fi ../../utils.jsTypeScript înțelege acest model atunci când --moduleResolution este setat la node20, nodenext, bundler, oglindind semantica Node-ului modern. Această îmbunătățire a fost implementată de contribuitorul magic-akari.

Utilizarea --moduleResolution bundler implementate cu --module commonjs

Anterior, --moduleResolution bundler putea fi folosit doar cu --module esnext or preserveOdată cu deprecierea celui mai vechi node/node10 În modul de rezoluție a modulelor, multe proiecte aveau nevoie de o cale de migrare care să se potrivească rezultatului lor CommonJS curent.

TypeScript 6.0 permite acum combinarea --moduleResolution bundler implementate cu --module commonjsAceastă combinație este adesea o rampă de lansare practică pentru bazele de cod care încă utilizează CommonJS, dar se îndreaptă către fluxuri de lucru centrate pe bundler sau către o logică de rezoluție mai nouă. De acolo, proiectele pot planifica o migrare pe termen lung către:

• module: "preserve" implementate cu moduleResolution: "bundler" pentru aplicații web incluse în pachet și configurații similare sau
• module: "nodenext" pentru medii care vizează direct Node.js modern.

Această schimbare este relevantă în special pentru echipele care pleacă moduleResolution: node în spatele dar nu este încă pregătit să îmbrățișeze pe deplin rezultatul ESM. Îți oferă un traseu etapizat în loc de o prăpastie.

--stableTypeOrdering steag pentru a emula ordinea 7.0

Una dintre principalele îmbunătățiri arhitecturale incluse în TypeScript 7.0 este verificarea paralelă a tipurilor.Rularea mai multor verificatoare în paralel înseamnă că diferite părți ale programului pot fi vizitate în ordine diferite. Dacă ID-urile de tip și ordinea simbolurilor depind de ordinea de vizitare, puteți ajunge la o ordine de uniune nedeterministă, o ordine a proprietăților și chiar la diferențe rare în diagnosticare.

Versiunile mai vechi de TypeScript atribuie ID-uri de tip interne pe baza ordinii de întâlnireAceste ID-uri sunt apoi folosite pentru a sorta lucruri precum tipurile de uniuni și proprietățile. De aceea, editările aparent inofensive - cum ar fi introducerea unui nou const înaintea unei funcții existente - poate inversa ordinea uniunilor literale în emise .d.ts fișiere sau să modificați modul în care se imprimă anumite tipuri în editor.

TypeScript 7.0 trece la o ordonare deterministă, bazată pe conținut, pentru obiectele interneFiecare tip sau simbol este sortat în funcție de structura sa, nu de ordinea incidentală de apariție, astfel încât același program va produce în mod constant aceeași ordine, indiferent de paralelism sau ordinea de compilare. Aceasta elimină misterul „de ce s-a inversat brusc uniunea mea?”.

Pentru a vă ajuta să comparați comportamentul între versiunile 6.0 și 7.0, RC introduce --stableTypeOrderingCând acest indicator este activat, TypeScript 6.0 adoptă același algoritm determinist de ordonare a tipurilor pe care îl folosește versiunea 7.0. Rezultatul este mult mai puține diferențe în fișierele de declarare emise și comparații mai previzibile între ieșirile versiunilor 6.x și 7.x.

Totuși, determinismul nu este gratuit. Activare --stableTypeOrdering poate încetini verificarea tipurilor cu până la aproximativ 25%, în funcție de baza de cod. Este conceput ca un ajutor pentru diagnosticare și migrare, nu ca o setare de performanță activă permanent.

Dacă vedeți erori de tipărire doar atunci când --stableTypeOrdering este pornit, de obicei înseamnă că codul anterior se baza pe vechea ordonare cvasi-accidentală a tipurilor pentru ca inferența să „funcționeze pur și simplu”. Corecțiile implică de obicei explicitarea tipurilor - adăugarea unui argument de tip la un apel generic problematic sau adnotarea unei variabile cu o interfață specifică în loc să se bazeze în întregime pe inferență pentru un obiect complex.

Nou es2025 opțiuni target și lib

TypeScript 6.0 adaugă o es2025 opțiune pentru ambele target și libDeși ES2025 nu introduce o sintaxă de bază nouă în comparație cu anii precedenți, aceasta include mai multe API-uri standardizate care anterior erau protejate de restricții. esnext.

Prin vizarea sau includerea es2025, obțineți tastări actualizate pentru noile elemente predefinite precum RegExp.escape, iar unele API-uri sunt mutate din esnext în es2025Asta include lucruri precum Promise.try, ajutoare pentru iteratori și extra Set metode care au atins maturitatea completă a specificațiilor. Această lucrare a fost realizată de Kenta Moriuchi.

Povestea mai amplă este că implicit target În versiunea 6.0, se urmărește acum anul curent ECMAScript, ceea ce în acest moment te duce efectiv la ES2025 atunci când nu specifici o țintă. Aceasta corespunde mai bine realității runtime-urilor evergreen și a instrumentelor moderne.

Tipuri încorporate pentru API-ul Temporal

Mult așteptata propunere Temporal a ajuns în etapa 3 și se așteaptă să înlocuiască infamul Date API pentru lucrul serios cu date/oreTypeScript 6.0 oferă acum tastări de primă clasă pentru Temporal, astfel încât să puteți începe să scrieți cod bazat pe Temporal cu siguranță completă a tipurilor și suport pentru editor.

Pentru a activa tipurile temporale, puteți utiliza --target esnext sau configurați explicit bibliotecile prin intermediul a ceva de genul:

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

Sau puteți opta doar pentru subsetul temporal cu "esnext.temporal" dacă doriți o configurație mai detaliată. După activare, puteți scrie cod de genul:

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

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

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

Temporalul este deja acceptat în unele runtime-uri și poate fi completat cu polifuncții în altele., deci aceste tipuri sunt cu adevărat utilizabile astăzi. Documentația este în curs de dezvoltare pe MDN (cu unele goluri încă umplute). Tipările au fost contribuite de utilizatorul GitHub Renegade334.

Suport Upsert: Map.getOrInsert și getOrInsertComputed

Dezvoltatorii JavaScript au scris manual modele de tip „check-then-set-then-get” pe Map pentru aniUn model tipic verifică dacă există o cheie, setează o valoare implicită dacă nu există și, în final, returnează o valoare - un model standard care este ușor de greșit sau de repetat peste tot.

Propunerea ECMAScript „upsert” (acum etapa 4) introduce getOrInsert și getOrInsertComputed on Map și WeakMapTypeScript 6.0 adaugă suport de tip pentru aceste metode în esnext lib, astfel încât să puteți începe să scrieți mai multe upsert-uri declarative imediat.

cu getOrInsert, un model detaliat ca acesta:

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

Poate fi restrâns la o singură linie:

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

Tovarășul getOrInsertComputed este ideal pentru implicite costisitoare—acceptă o funcție de apel invers care este invocată doar dacă cheia lipsește. Această funcție de apel invers poate chiar primi cheia ca parametru, permițându-vă să derivați valoarea implicită din cheia însăși. Tipările din TypeScript surprind aceste comportamente cu precizie, datorită din nou contribuțiilor Renegade334.

RegExp.escape și o construire mai sigură a expresiilor regulate

Dacă ați concatenat vreodată șiruri de caractere furnizate de utilizator într-o expresie regulată, știți că ar trebui să folosiți mai întâi caracterele speciale de escape.—dar majoritatea bazelor de cod fie reimplementează escape-ul într-un helper, fie îl uită complet. Propunerea RegExp Escaping (acum etapa 4) standardizează acest lucru cu RegExp.escape.

TypeScript 6.0 expune tipuri pentru RegExp.escape în temeiul es2025 libAsta înseamnă că atunci când vizați sau includeți ES2025, puteți scrie în siguranță helpere precum:

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

Nu mai este nevoie de o funcție de escape rulată manual...iar TypeScript va înțelege pe deplin și va verifica tipul API-ul. Această adăugire, la fel ca și lucrarea țintă ES2025, vine de la Kenta Moriuchi.

dom lib include acum API-uri pentru iterație și iterație asincronă

Din punct de vedere istoric, TypeScript a împărțit suportul pentru iteratoare DOM în dom, dom.iterable și dom.asynciterableDacă ați dori să repetați NodeList or HTMLCollection implementate cu for...of, trebuia să-ți amintești să adaugi dom.iterable în ta "lib" configurație alături domAceasta a fost o sursă frecventă de confuzie, mai ales că toate browserele moderne acceptă iterabile și iterabile asincrone în colecțiile DOM.

În TypeScript 6.0, lib.dom.iterable.d.ts și lib.dom.asynciterable.d.ts sunt efectiv îmbinate în lib.dom.d.tsAsta înseamnă să folosești "dom" alone vă oferă acum în mod implicit un comportament iterabil și asincron iterabil.

Încă poți menționa dom.iterable și dom.asynciterable în ta tsconfig, dar acele fișiere sunt acum shells goale. Dacă configurația anterioară arăta astfel:

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

Puteți simplifica în siguranță la doar "dom"și iterație peste colecții DOM, cum ar fi document.querySelectorAll("div") va verifica în continuare tipul:

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

Aceasta este o curățenie mică, dar binevenită. care aliniază biblioteca DOM implicită cu realitatea browserelor actuale și elimină o altă problemă din configurarea proiectului.

Valori implicite, perimile și modificările importante în TypeScript 6.0

Dincolo de API-urile strălucitoare, versiunea 6.0 aduce unele dintre cele mai puternice modificări ale setărilor implicite ale TypeScript de la versiunea 1.0 încoace.Aceste modificări reflectă ecosistemul JavaScript actual: runtime-uri evergreen, ESM ca bază, utilizarea pe scară largă a bundlerilor și un apetit puternic pentru tastare strictă și performanță.

Echipa evidențiază câteva tendințe generale care stau la baza acestor deciziiES5 și browserele cu adevărat vechi aproape că au dispărut; sistemele de module AMD/UMD sunt de nișă; aproape totul este livrat acum ca module; tastarea strictă este norma; iar performanța trebuie să rămână în prim-plan, mai ales că versiunea 7.0 aduce verificarea paralelă.

Prin urmare, TypeScript 6.0 și 7.0 sunt modelate cu setări implicite moderne și mai puține „valve de evacuare moștenite”.Pentru versiunea 6.0 RC, puteți dezactiva temporar deprecierile prin setarea "ignoreDeprecations": "6.0" în ta tsconfig, dar aceste opțiuni nu vor exista în versiunea 7.0. Unele ajustări pot fi automatizate cu instrumente precum versiunea experimentală ts5to6 codemod, care poate ajuta la rescrierea unor lucruri precum baseUrl și rootDir configurații în cadrul unui proiect.

Două ajustări de care multe proiecte vor avea nevoie imediat

Deși există o listă lungă de deprecieri, două modificări de configurare vor afecta probabil cel mai mare număr de baze de cod.:

• Setați explicit types mulțime (foarte des plus framework-ul de testare). Fără aceasta, veți pierde tipurile de ambient incluse automat din @types/*.
• Setați explicit rootDir (frecvent "./src") dacă te-ai bazat pe vechea „inferență a rădăcinii comune”. Altfel, structura fișierului emis s-ar putea modifica subtil.

Simptome ale lipsei types include o mulțime de erori despre valori globale, cum ar fi process, fs, path, describe fiind nedefinitSimptome ale unei schimbări rootDir sunt mai degrabă despre căile de ieșire care câștigă în mod neașteptat un plus src segment (de exemplu dist/src/index.js în loc de dist/index.js).

Valori implicite actualizate pentru proiecte moderne

Mai multe opțiuni de compilare au acum valori implicite noi care corespund modului în care sunt construite majoritatea aplicațiilor noi.:

• strict acum implicit la trueModul strict nu mai este un lux la care se poate opta; este nivelul de bază. Dacă anterior v-ați bazat pe un comportament nestrict, va trebui să îl setați explicit. "strict": false (deși veți rata o categorie importantă de verificări de siguranță).
• module acum implicit la esnext, reflectând faptul că ESM este formatul dominant de modul și se potrivește cel mai bine cu bundlere și Node modern.
• target implicit este anul ECMAScript curent (practic ES2025 în prezent), recunoscând că majoritatea implementărilor vizează medii evergreen sau trec printr-un grupator care poate realiza downgrade-uri suplimentare atunci când este cu adevărat necesar.
• noUncheckedSideEffectImports este acum true în mod implicit, ajutându-vă să identificați greșelile de scriere sau căile greșite în importuri, care sunt incluse doar pentru efecte secundare.
• libReplacement implicit la false, evitând o serie de rezoluții suplimentare eșuate ale modulelor și suprasolicitarea până când un proiect optează în mod explicit pentru comportamente specializate ale bibliotecilor.

Dacă oricare dintre aceste noi valori implicite vă strică compilarea, toate pot fi suprascrise explicit în tsconfig.jsonÎnsă intenția este ca noile proiecte să „facă pur și simplu ceea ce trebuie”, fără configurații suplimentare.

rootDir acum implicit este directorul de configurare

Anterior, dacă nu ați specificat rootDir, TypeScript a încercat să deducă o rădăcină sursă comună bazat pe toate fișierele nedeclarate din program. Acest lucru a îngreunat raționamentul asupra limitelor proiectului și a necesitat scanarea mai multor căi de fișiere doar pentru a decide unde ar trebui să aibă rădăcina emis.

În TypeScript 6.0, valoarea implicită rootDir este pur și simplu directorul care conține tsconfig.jsonVechiul comportament de inferență se aplică numai atunci când executați tsc pe linia de comandă fără nicio tsconfig la toate.

Această modificare înseamnă că proiectele cu fișiere sursă mai profunde decât directorul de configurare ar trebui să seteze explicit rootDirO configurație comună ar fi:

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

Dacă configurația ta face referire la fișiere de mai sus tsconfig locație, va trebui să extindeți și rootDir în consecință, De exemplu, "rootDir": "../src" pentru directoarele sursă partajate.

types acum implicit este o matrice goală

Aceasta este, fără îndoială, cea mai importantă schimbare pentru proiectele din lumea realăDin punct de vedere istoric, dacă nu ați specificat types in compilerOptions, TypeScript ar include automat tot ce se află sub node_modules/@typesAsta a fost convenabil, dar și scump și fragil: depozitele moderne atrag adesea sute de @types pachete tranzitoriu.

În TypeScript 6.0, types implicit la [], ceea ce înseamnă că niciun pachet de tip ambiental nu este încărcat automatAcum optezi explicit pentru mediile globale de care ai nevoie, de exemplu:

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

Acest lucru poate reduce cu 20-50% timpul de construcție în unele proiecte, deoarece compilatorul nu mai trebuie să parcurgă cu crawlere fiecare fișier de declarație din @typesDacă doriți cu adevărat vechiul comportament „încărcați totul”, puteți specifica:

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

Dacă vedeți brusc erori precum „Nu se poate găsi numele «proces»” sau „Nu se poate găsi modulul «fs»”, acesta este indiciul tău să adaugi node (și orice alte tipuri de teste/timp de execuție pe care vă bazați) către dvs. types matrice.

Învechit: target: es5 și --downlevelIteration

Vizarea ES5 este acum depreciatăAvând în vedere că toate browserele relevante au livrat ES2015+ timp de ani de zile și Internet Explorer a fost retras, rezultatul ES5 nu mai este considerat a merita complexitatea din interiorul TypeScript. Cea mai puțin suportată țintă de acum înainte este ES2015. Dacă trebuie neapărat să lansați ES5, recomandarea este să utilizați un transpiler extern (cum ar fi Babel sau un pipeline bundler) fie pe sursa TS, fie pe rezultatul TS.

--downlevelIteration steagul este, de asemenea, depreciat, deoarece singurul său caz de utilizare semnificativ era ajustarea comportamentului de emisie pentru țintele ES5. În TypeScript 6.0, setarea downlevelIteration deloc va produce o eroare de depreciere. Dacă folosești ES2015 sau o versiune mai nouă, steagul nu a avut oricum niciun efect.

Învechit: --moduleResolution node și moștenire classic

node (alias node10) modul de rezoluție a modulului este depreciatA modelat comportamentul Node 10, dar nu se potrivește cu ESM-ul și semantica de rezoluție ale Node-ului modern. Proiectele ar trebui să migreze către oricare dintre acestea. nodenext (pentru ținte directe ale nodului) sau bundler (pentru medii bazate pe pachete, cum ar fi aplicațiile web sau Bun).

Originală moduleResolution: classic Strategia a fost, de asemenea, eliminatăAceasta a fost povestea TypeScript de dinainte de rezolvarea Node. Astăzi, toate scenariile practice sunt mai bine servite de nodenext or bundler, deci clasicul a dispărut pentru a reduce complexitatea și cazurile limită.

Depreciate: AMD, UMD, SystemJS și module: none

Următoarele module valorile sunt acum depreciate și practic neacceptate:

• amd
• umd
• systemjs
• none

Aceste formate au fost esențiale în era pre-ESM, când browserele nu aveau suport nativ pentru module, iar dezvoltatorii se bazau pe AMD, UMD sau SystemJS pentru a umple golul. Astăzi, ESM plus pachete sau hărți de import gestionează practic toate cazurile de utilizare reale, iar „niciunul” nu a fost niciodată deosebit de bine definit.

Dacă încă vizați aceste formate de module vechi, recomandarea este de a migra către o țintă care emite ESM și de a se baza pe un bundler sau un compilator alternativ pentru împachetarea finală - sau de a rămâne pe TypeScript 5.x până când este implementat un plan de migrare. Ca parte a acestei curățări, vechiul amd-module Directiva este, de asemenea, abandonată.

Învechit: baseUrl

baseUrl opțiunea a fost mult timp o sursă de comportament ciudat și greu de depanat la rezolvarea modulelorMulte proiecte l-au folosit pur și simplu ca prefix pentru paths intrări, dar TypeScript a tratat-o ​​și ca o rădăcină de căutare generală, provocând importuri precum "someModule" a rezolva src/someModule.js în mod neașteptat, când tot ce a vrut dezvoltatorul a fost să accepte aliasuri personalizate precum @app/*.

În 6.0, baseUrl este depreciat și nu va mai fi folosit ca rădăcină de căutareMaparea căilor nu a fost necesară baseUrl de ceva vreme, așa că migrarea recomandată este pur și simplu de a încorpora prefixul în fiecare paths intrare. De exemplu:

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

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

Doar în cazuri rare în care ai folosit cu adevărat baseUrl ca o rădăcină de căutare generică ar trebui să reproduci acel comportament cu o mapare a căilor catch-all, cum ar fi:

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

Pentru majoritatea echipelor, simpla eliminare baseUrl și prefixe inline în paths va fi atât mai clar, cât și mai sigur.

Interoperabilitate și strictețe: esModuleInterop, allowSyntheticDefaultImports și alwaysStrict

TypeScript 6.0 blochează, de asemenea, ceea ce a fost mult timp comportamentul implicit de interoperabilitate recomandat.Nu mai puteți seta esModuleInterop or allowSyntheticDefaultImports la falseAceste opțiuni au fost inițial activate pentru a evita deteriorarea proiectelor mai vechi, dar dezactivarea lor în prezent duce adesea la probleme subtile de execuție atunci când se combină CommonJS și ESM.

Cu interoperabilitatea mereu activată, este posibil să fie nevoie să actualizați anumite modele de import.. De exemplu:

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

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

alwaysStrict steagul nu poate fi setat nici la false maiTypeScript presupune acum semantica modului strict JavaScript pe toate planurile, inclusiv modul în care cuvintele rezervate și this se comportă. Dacă aveți cod cu adevărat vechi care folosea cuvinte rezervate precum await or static ca identificatori, va trebui să le redenumiți.

Învechit: outFile, spațiu de nume vechi module cuvânt cheie și import asserts

--outFile opțiunea este eliminată în versiunea 6.0Concatenarea mai multor intrări într-un singur pachet JS este o sarcină mai bine gestionată de Webpack, Rollup, esbuild, Vite, Parcel sau instrumente similare. TypeScript își dublează eforturile de verificare a tipurilor și emit declarațiilor în loc să încerce să fie un pachet.

Utilizarea moștenită a module declararea spațiilor de nume este acum o eroare dificilă. TypeScript timpuriu permis:

module Foo {
  export const bar = 10;
}

Sintaxa modernă, acceptată, folosește namespace:

namespace Foo {
  export const bar = 10;
}

Această modificare este necesară pentru a evita conflictul cu potențiale viitoare ECMAScript module blocuriDeclarații de module ambientale, cum ar fi declare module "some-module" { ... } rămân pe deplin susținute.

Importați aserțiuni folosind asserts sunt, de asemenea, depreciate, deoarece propunerea de bază a evoluat în atribute de import folosind withCod de genul:

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

Ar trebui migrat la noul formular:

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

Învechit: no-default-lib referințe și liste de fișiere din linia de comandă cu tsconfig

/// <reference no-default-lib="true" /> Directiva nu mai este acceptatăA fost adesea înțeles greșit. Dacă trebuie să excludeți biblioteca implicită, utilizați --noLib or --libReplacement în schimb, care exprimă mai clar intenția la nivel de configurare.

O altă sursă persistentă de confuzie este modul în care tsc tratează argumentele explicite ale fișierului atunci când un tsconfig.json este prezentAnterior, alergarea tsc foo.ts într-un astfel de director ar ignora în mod silențios fișierul de configurare. În versiunea 6.0, acest scenariu produce o eroare explicită:

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

Dacă vrei cu adevărat să ocolești configurația și să compilezi un singur fișier cu valorile implicite, acum puteți utiliza tsc --ignoreConfig foo.ts pentru a clarifica această intenție.

Pregătirea pentru TypeScript 7.0

TypeScript 6.0 este complet funcțional și în mare parte în modul de stabilizareDe acum înainte și până la disponibilitatea generală, echipa se așteaptă doar la remedieri de erori critice. Versiunile nocturne sunt publicate în mod regulat, iar echipa livrează și versiuni nocturne ale viitoarei versiuni native (bazate pe Go) TypeScript 7.0, împreună cu o extensie VS Code dedicată pentru experimentarea cu noul motor.

Foaia de parcurs este intenționat strictă: se așteaptă ca versiunea 7.0 să urmeze versiunea 6.0 la scurt timp după aceea., deci bucla de feedback privind problemele legate de actualizare și migrare va fi scurtă. Dacă vedeți avertismente privind perimarea în versiunea 6.0, recomandarea principală este să le remediați acum, în loc să așteptați până când versiunea 7.0 impune problema.

Fluxul de lucru practic pentru majoritatea echipelor arată astfel: actualizați la TypeScript 6.0 RC, remediați-vă types și rootDir, abordează deprecierile (sau le blochează temporar în spatele "ignoreDeprecations": "6.0" în timp ce iterezi) și rulează cu --stableTypeOrdering dacă trebuie să comparați ieșirile sau să pregătiți conducte CI pentru ordonarea deterministă a versiunii 7.0. Odată ce acest lucru este implementat, trecerea la compilatorul bazat pe Go ar trebui să se simtă ca o îmbunătățire a performanței, mai degrabă decât ca o rescriere ulterioară.

Luate împreună, TypeScript 6.0 RC se concentrează mai puțin pe o sintaxă strălucitoare și mai mult pe pregătirea scenei.Viteză nativă în versiunea 7.0, configurații mai curate, setări implicite moderne și API-uri standardizate precum Temporal și ES2025 integrate, care facilitează codarea zilnică. Dacă le adoptați acum, remediați părțile zgomotoase și vă bazați pe noile setări implicite, veți fi într-o poziție mult mai bună atunci când va apărea compilatorul nativ.