TypeScript 7 i port do Go: szybsze budowanie, lepsza obsługa pamięci oraz informacje zwrotne od edytora.

Każdy, kto od lat używa TypeScript, zna ten rytm. Pisze się kod, edytor przez chwilę go analizuje, TypeScript przetwarza projekt, potem uruchamia się tsc i znów trzeba czekać. W dużym monorepo ta przerwa jest na tyle długa, że można pójść po kawę. To wcale nie oznacza, że narzędzie jest źle zaprojektowane. Jego system typów oraz narzędzia językowe stały się na tyle silne, że potrafią radzić sobie z bardzo dużymi bazami kodu, i właśnie dlatego stało się tak kluczowe dla świata JavaScript. Jednak ta siła miała swoją cenę: w miarę rozwoju projektów kompilator i serwer językowy stały się wąskim gardłem pod względem wydajności.

TypeScript 7.0 to odpowiedź Microsoftu, a najważniejsze jest to, że główną zmianą nie jest nowy operator, słowo kluczowe ani trik składniowy. Chodzi o silnik leżący u jego podstaw. Kompilator TypeScripta był wcześniej pisany w samym TypeScriptie, co stanowiło przyjemnie rekurencyjne rozwiązanie dobrze działające, choć oznaczało to, że kompilator musiał funkcjonować w ramach modelu runtime JavaScripta. W wersji 7 Microsoft przeniósł kompilator na język Go, tworząc implementację natywną zaprojektowaną do wykorzystania nowoczesnego sprzętu i możliwości paralelizmu.

To jest kluczowe do zrozumienia tej wersji. TypeScript 7 to przede wszystkim nie nowy język, lecz nowy silnik dla języka, którym ludzie już piszą, a to ujęcie wyjaśnia niemal wszystko inne na jego temat.

Wartości szybkości

Główna liczba wskazuje na dziesięciokrotnie większą szybkość. Testy Microsoft pokazują, że pełne kompilacje zwykle działają 8 do 12 razy szybciej, w zależności od projektu, przy czym dotyczy to dużych baz kodu z rzeczywistego świata, a nie syntetycznych mikrotestów.

Czas kompilacji to nawet nie najbardziej imponujący wynik, ponieważ przyspiesza się również serwer językowy. W przykładzie Microsoft wykorzystującym bazę kodu VS Code czas otwierania pliku zawierającego błąd zmniejszył się z około 17,5 sekundy przed pojawieniem się pierwszego błędu do niecałych 1,3 sekundy. To zupełnie inna jakość pracy, a w dużych repozytoriach ma to większe znaczenie niż skrócenie o kilkaset milisekund czasu kompilacji w środowisku produkcyjnym.

Wykorzystanie wszystkich rdzeni

Współczesne maszyny mają wiele rdzeni, podczas gdy tsc historycznie korzystał z jednego. TypeScript 7 wykorzystuje je znacznie lepiej: analiza, sprawdzanie typów oraz generowanie kodu mogą być wykonywane równolegle, gdzie to możliwe. Dodatkowo wprowadza kilka eksperymentalnych opcji:

--checkers
--builders
--singleThreaded

Pierwsze dwa umożliwiają dokładniejszą kontrolę nad sposobem dzielenia pracy równoległej, a --singleThreaded wyłącza równoległość w razie potrzeby, na przykład podczas debugowania zachowania kompilatora lub działania w ograniczonym środowisku.

Najwięcej zyskają monorepo. Wyobraź sobie repozytorium z katalogiem aplikacji:

apps/
  web/
  admin/
  mobile/

i katalog pakietów:

packages/
  ui/
  api/
  config/
  utils/
  domain/

TypeScript służy do wykonywania ogromnej ilości zadań sekwencyjnych w ramach tego grafu zależności. Od wersji 7 większa ich część może być realizowana jednocześnie. Dlatego nie chodzi tu tylko o to, że kompilator jest szybszy – chodzi o to, że w końcu może on wykorzystywać sprzęt, na którym działa.

Pamięć

Wydajność to nie tylko czas pracy procesora. Duże projekty napisane w TypeScript mogą zużywać kilka gigabajtów pamięci RAM, szczególnie gdy serwer językowy działa obok edytora, przeglądarki, Dockera oraz serwerów deweloperskich. Opublikowane przez Microsoft testy wydajności pokazują, że zużycie pamięci spada o około 6% do 26% w przypadku kilku dużych projektów:

• Bluesky: o około 26% mniej
• VS Code: o około 18% mniej
• tldraw: o około 15% mniej
• Playwright: o około 11% mniej

Choć szybsze o dziesięć razy procesy kompilacji mogą wydawać się niewielkie, każdy, kto obserwował, jak pamięć w laptopie znika w dużym monorepo, rozumie ich wartość.

Nowy serwer językowy

Większość zalet TypeScript nie pochodzi przecież od tsc. Pochodzą one od edytora: uzupełnianie kodu, pokazywanie informacji o typach przy przewijaniu kursorem, szybkie przechodzenie do definicji, wyświetlanie wszystkich odniesień, zmiana nazwy symbolu we wszystkich miejscach, pokazywanie błędów bezpośrednio w tekście oraz możliwość ich szybkiego naprawienia jednym kliknięciem. Duży udział w tym, co sprawia wrażenie nowoczesnego rozwoju w JavaScript, przypada właśnie na te funkcje.

TypeScript 7 wprowadza nowy serwer językowy oparty na Language Server Protocol, wykorzystujący natywną implementację oraz wielowątkowość. Zespół ciągle rozwija jego funkcjonalności: pojawiły się soczewki kodu, wskazówki w tekście, semantyczne podświetlanie, sortowanie importów oraz usuwanie nieużywanych importów, a także automatyczne importy, możliwość szybkiego przechodzenia do definicji źródłowej oraz edycja powiązana z JSX i uzupełnianie tagów. Celem jest coś więcej niż tylko szybszy tsc: cały proces od wpisywania kodu do otrzymania informacji zwrotnej staje się szybszy, a to jest chyba największym atutem.

Deterministyczny wynik w warunkach równoległości

Jedna z zmian nie jest tak efektowna, ale technicznie ciekawa. TypeScript prowadzi liczne wewnętrzne rejestry związane z typami, symbolami, uniami i deklaracjami. Gdy kilka procesów działa jednocześnie, kolejność tworzenia wewnętrznych obiektów może się różnić, co może zmienić ich wewnętrzne ID i tym samym wpłynąć na kolejność generowanych deklaracji.

TypeScript 7 radzi sobie z tym, ustalając deterministyczną kolejność na podstawie zawartości wewnętrznych obiektów, zamiast polegać na kolejności, w jakiej zostały one odnalezione. Weźmy tę funkcję:

function foo(condition: boolean) {
  return condition ? 100 : 500;
}

Może dać takie oświadczenie:

export declare function foo(
  condition: boolean
): 100 | 500;

a kolejność operacji unii pozostaje stabilna, niezależnie od tego, jak przebiega praca równoległa. Większość programistów tego nie zauważy, ale to właśnie takie rozwiązania inżynieryjne sprawiają, że kompilator o wysokim stopniu równoległości jest niezawodny.

To nie jest wersja z nowymi funkcjami

Każdy, kto oczekuje czegoś takiego:

type NewSuperPower<T> = ...

Wielka liczba nowych funkcji językowych może sprawić, że TypeScript 7 wyda się na początku nieco rozczarowujący. Większość wysiłków została poświęcona infrastrukturze, a nie nowym możliwościom systemu typów. Zespół spędził lata na budowaniu fundamentów pod następną generację TypeScript, a teraz już istnieje. Plan rozwoju wskazuje na dalszą pracę nad nowymi funkcjami, ulepszenia ergonomii, jeszcze większe wzrosty wydajności oraz nową API kompilatora po wersji 7.0. Ta wersja lepiej pasuje do opisu początku nowej ery niż końca poprzedniej.

Uwagi dla twórców narzędzi

Tutaj sytuacja staje się ciekawa dla osób tworzących narzędzia. TypeScript 7.0 nie zawiera już starej API kompilatora, a zespół spodziewa się, że wersja 7.1 wprowadzi nową. To istotna kwestia, ponieważ duża część ekosystemu nie polega wyłącznie na uruchamianiu tsc. Narzędzia do sprawdzania kodu, kompilatory frameworków, usługi językowe oraz narzędzia do budowania aplikacji komunikują się z TypeScript w sposób programowy.

To jeden z powodów, dla których TypeScript 6 i 7 mogą na razie musieć istnieć obok siebie. Microsoft wprowadził @typescript/typescript6, aby ułatwić tę migrację – dzięki temu projekt może nadal używać wersji 6 w narzędziach, które wciąż wymagają jej API, jednocześnie korzystając oddzielnie z kompilatora wersji 7. Aktualizacja kompilatora nie zawsze jest tak prosta, jak edycja jednej linii kodu:

{
  "devDependencies": {
    "typescript": "^7.0.0"
  }
}

W dużych ekosystemach kompilator stanowi infrastrukturę, a infrastruktura ma swoje zależności.

Kolejna ograniczenie dotyczy frameworków i narzędzi, które włączają TypeScript do swoich własnych procesów kompilacji lub usług językowych. Zespół określa Vue, MDX, Astro, Svelte i Angular jako narzędzia, w których wsparcie dla nowej architektury usług językowych nadal się rozwija, a brak stabilnej API programowej jest tego powodem. Zwykła aplikacja oparta na React i TypeScript może zostać przeniesiona bez większych problemów. Zintegrowanie zaawansowanego frameworku, pluginu kompilatora lub pluginu usług językowych wiąże się z trudniejszym procesem. Warto to sprawdzić przed aktualizacją jakiegokolwiek dużego repozytorium produkcyjnego.

TypeScript 6 jako kamień milowy

TypeScript 6 nie był tylko wersją poprzedzającą 7. Został celowo stworzony jako most pomiędzy wersjami. Kilka starych opcji kompilatora zostało tam oznaczonych jako przestarzałe i całkowicie zniknęło w wersji 7, dlatego zespół zaleca usunięcie ich przed przejściem na nowszą wersję. Korzystanie z wersji pośredniej, jak pokazano poniżej, jest lepsze niż traktowanie wersji 7 jako samodzielnej aktualizacji:

TypeScript 5.x
      ↓
TypeScript 6
      ↓
TypeScript 7

Wszystkie ostrzeżenia o deprecjacji generowane przez projekt w TypeScript 6 zasługują na uwagę. Są one w rzeczywistości komunikatami o migracji przesyłanymi z przyszłości.

Dlaczego pętla zwrotna jest ważna

TypeScript znika po skompilowaniu, więc deweloperzy frontendu rzadko traktują je jako element czasu działania aplikacji. Jednak silnie wpływają one na czas działania procesu rozwoju. Za każdym razem, gdy edytor przechodzi przez taki cykl:

type something
↓
autocomplete appears
↓
you navigate to a definition
↓
you rename a symbol
↓
you save
↓
CI runs
↓
the project gets type-checked

TypeScript bierze udział za każdym razem, a jego rola rośnie wraz z rozwojem aplikacji. Opóźnienie o 100 ms nie ma znaczenia, ale opóźnienie o 10 sekund już tak, 30-sekundowe oczekiwanie zmienia sposób pracy osoby, a pięciominutowa weryfikacja kodu typu w środowisku CI wpływa na pracę całego zespołu. Główną cechą TypeScript 7 nie jest więc dziesięciokrotnie szybsza kompilacja, lecz krótszy czas pomiędzy napisaniem kodu a sprawdzeniem, czy jest poprawny.

Próba użycia

W przypadku nowego projektu TypeScript 7 zdecydowanie warto rozważyć. W przypadku projektu istniejącego bardziej umiarkowany podejście jest odpowiednie. Zacznij od zainstalowania go jako zależności deweloperskiej:

npm install -D typescript@7

Następnie przeprowadź sprawdzenie typu bez wyprowadzania:

npx tsc --noEmit

i sprawdź wyniki, przechodząc przez następujące obszary:

1. Błędy kompilatora
2. Ustarzała konfiguracja
3. Kompatybilność narzędzi budowania
4. Integracja z ESLint
5. Integracja z frameworkiem
6. Behawior IDE
7. Wydajność CI
8. Użytek pamięci

W dużym monorepo warto przeprowadzić pomiar wydajności przed i po zmianach, używając czegoś takiego jak:

time npx tsc --build

I porównaj wynik z obecną wersją TypeScript. Ostateczna liczba nie powinna być jedynym punktem uwagi – liczy się całe doświadczenie programisty.

Odbudowa podstaw

TypeScript 7 wyróżnia się w narzędziach front-endowych, ponieważ zespół pominął typowe podejście polegające na dodawaniu kolejnych funkcji do istniejącej architektury, a zamiast tego odbudował jej podstawy. Język nie wymagał przemyślenia, natomiast infrastruktura tak. Czas wprowadzenia tego rozwiązania jest również uzasadniony – w dobie większych projektów JavaScript, powszechnych monorepo, API zabezpieczonych typami, inteligentniejszych edytorów, narzędzi programistycznych wykorzystujących sztuczną inteligencję do przetwarzania danych semantycznych oraz programistów oczekujących niemal natychmiastowych odpowiedzi. Kompilator wystarczająco szybki dla aplikacji z 2015 roku niekoniecznie nadąży za monorepo z 2026 roku.

Proście mówiąc, ta wersja przyznaje, że stary projekt funkcjonował, ale nowoczesne oprogramowanie przewyższyło jego możliwości. Zamiast porzucić system typów, który już podoba się programistom, zespół odbudował to, co działa w tle. Z tego powodu ta wersja ma większe znaczenie, niż sugeruje jej widoczna lista funkcji. Stanowi ona podstawę dla przyszłych wersji TypeScript oraz szybszego tsc. Jeśli obiecane korzyści przeniosą się na cały ekosystem, najbardziej ekscytujące funkcje TypeScript mogą nawet nie pojawić się w wersji 7 – mogą to być te, które staną się praktyczne tylko dlatego, że wersja 7 jest wystarczająco szybka, by je zaimplementować.

Głównym tematem jest dziesięciokrotny wzrost wydajności. Za tym kryje się paralelizm, wykonywanie w trybie natywnym, zmniejszone zużycie pamięci, nowy serwer językowy, deterministyczny wynik kompilacji oraz podstawa pod przyszłe narzędzia. Dla każdego, kto utrzymuje duże aplikacje napisane w TypeScript, jest to zapewne cenniejsze niż kolejna narzędzie do obsługi typów.

Literatura pokrewna

• RAG-Anything na 65 książkach o winie: Gdzie technologia Graph Retrieval odnosi sukcesy, a gdzie ponosi porażki — Praktyczny test grafu wiedzy RAG-Anything na 65 plikach PDF o winie: wybór narzędzi do analizy, koszty, odpowiedzi oparte na grafach w porównaniu z wektorami oraz problemy związanе z winem musującym.
• Porównanie 16 architektur RAG: Który model pasuje do jakiego problemu — Przegląd szesnastu modeli RAG w czterech kategoriach, od standardowych i hybrydowych metod wyszukiwania po rozwiązania oparte na agentach, grafach i federacjach, wraz z planem budowy krok po kroku.