Rularea unui fișier TypeScript nu îi verifică tipurile

Un mediu care elimină sintaxa TypeScript stabilește dacă poate executa codul JavaScript rămas. Nu stabilește dacă programul respectă tipurile declarate. Tratați execuția și verificarea prin compilator ca obligații separate, chiar dacă eliminarea unei etape de construire face un script mic mai ușor de rulat.

Privită din noiembrie 2026, aceasta este distincția utilă din discuția lunii ianuarie 2025. Împiedică transformarea unei comenzi locale convenabile într-o dovadă accidentală că aplicația a fost verificată. Consecința pentru o firmă este simplă: o cale mai ușoară spre execuție nu ar trebui să elimine tacit o sursă de feedback înainte de lansare.

Citiți anunțul beta în contextul său

Anunțul Microsoft pentru TypeScript 5.8 beta este datat 29 ianuarie 2025. Prezintă erasableSyntaxOnly, opțiune care respinge construcții TypeScript ce necesită transformări cu efect la execuție, inclusiv enumerări și proprietăți declarate prin parametrii constructorului. Este o funcționalitate beta istorică, nu o afirmație despre disponibilitatea stabilă din acea zi sau despre setările implicite ale unei instalări din noiembrie 2026.

Mai devreme în aceeași lună, versiunea Node.js 23.6.0, datată 7 ianuarie, activase implicit eliminarea experimentală a tipurilor pentru acea versiune. Eticheta „Current” aparține paginii de lansare datate. Nu recomandă folosirea acelei versiuni vechi într-o aplicație nouă astăzi.

Documentația aferentă Node 23.6 separă explicit eliminarea sintaxei de verificarea tipurilor și descrie o opțiune de transformare pentru construcțiile care cer generare de cod. Documentația unei versiuni oferă retrospectivei limite mai precise decât proiectarea documentației generale de azi asupra trecutului.

Eliminarea unei adnotări păstrează operația

Luați un exemplu explicit ilustrativ: o variabilă primește un număr, dar adnotarea spune că tipul său este șir de caractere. Eliminarea adnotării lasă o atribuire JavaScript care poate fi executată. Faptul că execuția continuă nu dovedește concordanța dintre valoare și adnotare; adnotarea a fost scoasă din această cale de execuție.

Verificarea prin compilator este locul în care trebuie raportată nepotrivirea. Un test la rulare poate descoperi o eroare ulterioară, dar numai dacă execută un comportament care o expune. Verificările au scopuri diferite. Înlocuirea uneia cu cealaltă schimbă dovezile pe care le primește echipa, chiar dacă ambele comenzi se încheie cu succes pentru o anumită revizie.

Distincția contează mai ales când scriptul crește. O operație ocazională poate ajunge să aibă apelanți, configurație și date externe fără ca cineva să îi regândească deliberat procesul de lansare. Dacă singura condiție de acceptare rămâne „a rulat o dată”, încrederea echipei poate depăși dovezile. Păstrați verificarea vizibilă în timp ce simplificați execuția.

Unele construcții cer un comportament nou

O proprietate declarată printr-un parametru al constructorului arată a doua limită. O declarație precum public name: string face mai mult decât să descrie tipul parametrului: declară și inițializează o proprietate a instanței. Simpla eliminare a cuvintelor specifice TypeScript ar pierde comportamentul proprietății, pe care se bazează codul apelant.

O enumerare introduce și ea o reprezentare disponibilă la execuție. Codul care citește un membru numit al enumerării așteaptă să existe o valoare în acel moment. Eliminarea declarației ca și cum ar fi doar o adnotare de tip nu păstrează această așteptare. Restricția din beta privește astfel sintaxa cu efecte la rulare, nu o presupusă echivalență dintre orice program TypeScript și JavaScript cu adnotări.

O variantă de reproiectare este scrierea explicită a operațiilor JavaScript, cu adnotări care pot fi eliminate. Alta este păstrarea construcțiilor necesare și folosirea unui compilator sau a unui instrument de rulare care le transformă. Nicio variantă nu este universal mai ieftină. Comparați claritatea sursei, restul proiectului și responsabilitățile instrumentelor înainte să rescrieți cod existent.

Denumiți separat execuția și verificarea

O convenție propusă pentru proiect ar trebui să definească o comandă de execuție și una de verificare. Prima rulează un punct de intrare ales în mediul agreat, de exemplu node file.ts în acea versiune istorică Node. A doua rulează compilatorul TypeScript fixat pentru proiect, cu configurația potrivită, fără să emită fișierele aplicației, de exemplu tsc --noEmit --project tsconfig.json. În contextul versiunii beta din ianuarie, restricția de sintaxă aparține acelei configurații, dacă echipa o alege.

Aceasta este o propunere de organizare, nu o configurație testată și furnizată de articol. Comenzile exacte depind de modelul de module, mediul de execuție acceptat și organizarea fișierelor. Dovada importantă este că ambele comenzi lucrează pe revizia și pe fișierele intenționate. Absența erorilor în editor este o dovadă mai slabă dacă editorul folosește alt compilator sau altă selecție a proiectului.

Când o comandă eșuează, distingeți responsabilitatea sa. Eșecul execuției poate ține de date, mediu sau sintaxă neacceptată. Eșecul compilatorului poate ține de relațiile dintre tipuri sau de politica de sintaxă aleasă. Păstrați context suficient pentru reproducerea rezultatului, în loc să tratați orice eroare ca motiv pentru dezactivarea noii opțiuni.

Instrumentele care transformă codul rămân utile

Cel mai puternic contraargument este că un proiect matur poate folosi în multe locuri construcții care cer transformare. Păstrarea unui proces de construire întreținut poate fi mai clară decât modificarea sursei doar pentru eliminarea acelui proces. Un instrument care face transformări poate fi potrivit și pentru sarcini de dezvoltare ce depășesc simpla eliminare a sintaxei.

Un asemenea instrument nu dovedește automat că a avut loc verificarea tipurilor. Examinați ce promite comanda sa. Dacă verificarea este separată, păstrați-o explicit. Un nume scurt poate ascunde mai multe comportamente; documentați rezultatul în loc să vă bazați pe cuvântul „TypeScript” din descrierea instrumentului.

Argumentul este separat de noile diagnostice ale compilatorului și de rescrierea căilor de import. Privește două limite: dacă sintaxa poate fi eliminată fără pierderea comportamentului la rulare și dacă o verificare separată validează tipurile programului. Alte adaptări pot rămâne necesare, dar nu ar trebui să ascundă aceste întrebări.

În dezvoltarea software la comandă, cereți echipei să arate calea de execuție și calea de verificare pentru un punct de intrare important. Confirmați versiunile mediului și compilatorului folosite de fiecare. Exercițiul face procesul simplificat ușor de evaluat, fără să confunde reducerea comenzilor cu reducerea responsabilităților.