TypeScript 5.6: lăsați compilatorul să respingă condițiile suspecte

O condiție poate fi cod JavaScript valid fără să verifice ceea ce a intenționat autorul. TypeScript 5.6 a introdus o alegere utilă: respingerea unor expresii a căror sintaxă arată deja că rezultatul nu poate varia în modul așteptat. Pentru o echipă care întreține o aplicație, acesta este un motiv bun să evalueze actualizarea compilatorului. Promisiunea rămâne însă limitată. Compilatorul nu poate hotărî dacă regula comercială din spatele unei condiții aparent corecte este cea potrivită.

Privită din noiembrie 2026, etapa din iulie trebuie numită exact. Microsoft a anunțat TypeScript 5.6 Beta la 26 iulie 2024. Versiunea stabilă a urmat la 9 septembrie. În iulie puteați investiga noile mesaje de eroare; nu exista încă o versiune stabilă pe care orice echipă să o adopte imediat pentru aplicațiile folosite de clienți.

O greșeală pe care sintaxa o poate arăta

Exemplele Microsoft pentru versiunea beta includ un obiect expresie regulată folosit drept condiție if, fără apelul .test(...), o funcție săgeată scrisă în locul unei comparații și o comparație combinată cu ?? pe baza unei presupuneri greșite despre prioritatea operatorilor. Anunțul le include la verificările interzise de tip nullish și truthy. Sunt greșeli obișnuite de editare, care pot schimba comportamentul programului, fără să implice probleme neobișnuite ale sistemului de tipuri.

Diferența utilă este între cum arată condiția pentru cititor și ce înseamnă ea în JavaScript. Programatorul poate vedea un șablon și poate presupune că programul verifică un text. La execuție există însă un obiect. Un coleg poate recunoaște forma unei comparații și poate rata operatorul care creează o funcție. Sintaxa poate oferi suficiente indicii pentru un mesaj de eroare înainte să sosească date reale.

De aceea, compilatorul este un loc potrivit pentru această verificare. După includerea lui în verificările efective ale proiectului, detectarea nu mai depinde de atenția următorului coleg care citește modificarea. Este o recomandare despre locul unei verificări repetabile, nu un rezultat măsurat privind numărul de erori eliminate dintr-o aplicație.

Trei întrebări diferite despre corectitudine

O verificare sintactică stabilește dacă expresia are un rezultat suspect de previzibil. Restrângerea tipurilor stabilește ce se poate ști despre o valoare pe un anumit traseu din program. Validarea la execuție stabilește dacă datele primite respectă cerințele aplicației. Aceste întrebări se pot întâlni în același program, dar răspunsul bun la una nu le rezolvă pe celelalte.

Să presupunem că aveți un sistem de comenzi. O condiție poate compara un total numeric valid cu o limită numerică validă, folosind totuși limita greșită pentru clientul respectiv. Sintaxa poate fi firească, tipurile pot corespunde, iar decizia comercială poate rămâne greșită. Un test care exprimă regula agreată pentru acel client are un rol pe care actualizarea compilatorului nu îl poate prelua. Exemplul este ipotetic.

La fel, punctul în care aplicația primește date externe are nevoie de un răspuns explicit pentru valori lipsă sau nevalide. Declararea formei așteptate nu dovedește ce a trimis efectiv un sistem extern. Verificările din iulie justifică eliminarea unei clase evitabile de greșeli, fără să justifice o încredere mai mare în toate datele primite.

Diferența contează când alocați bugetul. Actualizarea poate fi utilă fără să înlocuiască munca de testare. Dacă o prezentați drept substitut pentru validare, lăsați o sarcină esențială nefăcută. Dacă respingeți orice verificare nouă fiindcă există deja teste, puteți rata un loc convenabil în care greșeala ar fi prinsă înaintea lor.

Evaluați compilatorul pe proiectul real

Un răspuns rezonabil la versiunea beta ar fi fost o evaluare separată, la care se putea renunța ușor. Fixați versiunea analizată, rulați verificările obișnuite ale proiectului și citiți noile mesaje. Separați adoptarea compilatorului de reorganizarea codului fără legătură cu el, ca să puteți explica de unde provin erorile nou raportate.

Pentru fiecare condiție suspectă, stabiliți regula dorită înainte să modificați expresia. Adăugarea automată a unei comparații sau ascunderea mesajului poate elimina eroarea raportată fără să elimine neînțelegerea. Dacă nu puteți deduce comportamentul dorit din codul apropiat ori din specificație, cereți lămuriri persoanei care răspunde de regulă. Rezultatul urmărit este o decizie corectă în aplicație.

O versiune beta aduce și incertitudini dincolo de funcția principală. Anunțul stabil din septembrie consemnează schimbări față de beta, inclusiv renunțarea la un comportament al serviciului de limbaj și redenumirea unor tipuri pentru iteratori. Aceste informații ulterioare explică de ce evaluarea din iulie și decizia de adoptare din septembrie sunt activități separate. Nu dovedesc disponibilitatea lor în iulie.

Obiecția serioasă: actualizarea poate aștepta

O echipă cu termen fix poate detecta deja greșeli asemănătoare prin reguli de analiză statică și revizuirea codului. Poate considera evaluarea unui compilator beta o folosire slabă a timpului disponibil. Obiecția este solidă, mai ales când instrumentele de compilare sau integrarea cu editorul sunt sensibile la schimbarea versiunilor.

Notele versiunii stabile Microsoft recunosc existența unei reguli ESLint apropiate și precizează că verificările nu se suprapun perfect. Regulile existente contează, dar nu dovedesc echivalența. Verificați ce face proiectul înainte să afirmați că noul compilator nu aduce nimic sau că poate înlocui complet analiza statică existentă.

Recomandarea are o limită clară: evaluați verificările utile când investigația este accesibilă, apoi programați adoptarea în funcție de compatibilitate și termene. Nu este necesar să livrați cu o versiune beta. Dacă aplicația nu are deloc verificări TypeScript, poate fi nevoie mai întâi de o decizie mai largă despre instrumente.

Într-un proiect de mentenanță software, cereți o explicație a erorilor găsite, a comportamentelor confirmate și a muncii necesare pentru compatibilitate. Un număr de versiune mai mare spune prea puțin. Un compilator care respinge consecvent o greșeală cunoscută, în timp ce aplicația continuă să își verifice regulile reale, aduce un rezultat util.