TypeScript 7 to kompilator TypeScript przepisany w Go i dostarczany jako natywny program. Język jest ten sam, polecenie to nadal tsc, a pakiet npm to nadal typescript. Zmienia się szybkość (pełne budowanie około dziesięć razy szybsze), zestaw wartości domyślnych i to, że usunięto opcje oznaczone w TypeScript 6 jako przestarzałe. TypeScript 7.0 wydano 8 lipca 2026, a wersja w npm to 7.0.2.
npm install --save-dev typescript@latest
npx tsc --version
Version 7.0.2
Jedna z niewielu różnic widocznych na poziomie typów to sposób, w jaki template literal types dzielą stringi. JavaScript przechowuje stringi jako jednostki kodowe UTF-16, a emoji takie jak 😀 zajmuje dwie z nich:
TypeScript 6 dzielił template literal types według jednostek kodowych, jak text[0]. TypeScript 7 dzieli je według punktów kodowych, jak [...text], więc emoji zostaje w całości:
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// TypeScript 7: ["😀", "abc"]
// TypeScript 6: ["\ud83d", "\ude00abc"]
Dlaczego TypeScript przepisano w Go
Do wersji 6 kompilator TypeScript był napisany w TypeScript i działał w Node.js. W dużych projektach oznaczało to wolne budowanie, wolny start edytora i duże zużycie pamięci.
Anders Hejlsberg ogłosił natywny port 11 marca 2025 we wpisie zatytułowanym "A 10x Faster TypeScript". Nowa baza kodu dostała nazwę kodową Corsa, a ta w JavaScripcie Strada. Zespół przeniósł kod istniejącego kompilatora zamiast projektować moduł sprawdzania typów od nowa, więc nowy kompilator stosuje te same reguły i zgłasza te same błędy. TypeScript 6.0 (marzec 2026) był ostatnim wydaniem bazy kodu w JavaScripcie i pełnił rolę pomostu: oznaczył jako przestarzałe wszystko, co TypeScript 7 miał usunąć. TypeScript 7.0 ukazał się 8 lipca 2026.
Jak bardzo szybszy jest TypeScript 7
Pełne budowanie projektów open source według danych opublikowanych z wydaniem 7.0:
| Projekt | TypeScript 6 | TypeScript 7 | Przyspieszenie | Pamięć |
|---|---|---|---|---|
| VS Code | 125.7 s | 10.6 s | 11.9x | z 5.2 GB na 4.2 GB |
| Sentry | 139.8 s | 15.7 s | 8.9x | z 4.9 GB na 4.6 GB |
| Bluesky | 24.3 s | 2.8 s | 8.7x | z 1.8 GB na 1.3 GB |
| Playwright | 12.8 s | 1.47 s | 8.7x | z 1.0 GB na 0.9 GB |
| tldraw | 11.2 s | 1.46 s | 7.7x | z 0.6 GB na 0.5 GB |
Te pomiary używały domyślnych 4 workerów sprawdzania typów. Z --checkers 8 na tej samej maszynie budowanie VS Code trwało 7.51 s (16.7x), a tldraw 1.06 s (10.6x), kosztem większego zużycia pamięci.
Edytor zyskuje równie dużo. Language service działa teraz jako natywny serwer języka: w bazie kodu VS Code czas od otwarcia edytora do zobaczenia pierwszego błędu w pliku spadł z około 17,5 sekundy do poniżej 1,3 sekundy. Przyspieszenie najbardziej się liczy w monorepo, potokach CI i edytorach na dużych bazach kodu.
Co zostaje bez zmian
- Polecenie i pakiet.
npm install --save-dev typescriptinpx tsc. Przy instalacji npm wybiera gotowy plik binarny dla twojej platformy z opcjonalnych zależności, takich jak@typescript/typescript-linux-x64, więc nie trzeba niczego więcej konfigurować. - Język. Ta sama składnia, ten sam system typów, te same kody błędów.
- Wyniki. Informacje o wydaniu mówią, że praktycznie każdy kod, który czysto kompiluje się w TypeScript 6.0 z włączoną flagą
stableTypeOrderingi bez ustawieniaignoreDeprecations, powinien skompilować się identycznie w TypeScript 7.0.
Nowe wartości domyślne
TypeScript 6.0 zmienił te wartości domyślne, a TypeScript 7 je zachowuje. Mają znaczenie tylko dla opcji, których nie ustawia twój tsconfig.json:
| Opcja | Nowa wartość domyślna | Skutek, jeśli projekt polegał na starej |
|---|---|---|
strict | true | Projekty, które nigdy nie ustawiły strict, dostają teraz strict null checks, noImplicitAny i resztę |
target | es2025, najnowsza wersja przed esnext | Wyjście zachowuje nowoczesną składnię, dopóki nie ustawisz starszego targetu |
module | esnext | Wyjście w modułach ES, dopóki nie ustawisz nodenext albo commonjs |
types | [] | Zainstalowane pakiety @types nie ładują się już automatycznie: dodaj "types": ["node"] (["*"] przywraca stare zachowanie) |
rootDir | ./, folder, w którym leży tsconfig.json | Przy ustawionym outDir i źródłach w src pojawia się error TS5011, dopóki nie ustawisz "rootDir": "./src" |
noUncheckedSideEffectImports | true | Import dla efektów ubocznych, taki jak import "./styles.css", wymaga deklaracji modułu (declare module "*.css";), którą zwykle dostarczają pakiety typów frameworków |
stableTypeOrdering | Zawsze włączone, nie da się wyłączyć | Typy są porządkowane tak samo przy każdym uruchomieniu, więc komunikaty błędów i wyjście .d.ts nie zależą od kolejności sprawdzania |
Usunięte opcje i składnia
Opcje oznaczone jako przestarzałe w TypeScript 6 są w TypeScript 7 błędami:
target: es5orazdownlevelIteration, które istniało tylko dla wyjścia ES5.moduleResolution: node(nazywane teżnode10) iclassic. Użyjnodenextalbobundler.module: amd,umd,systeminone.baseUrl(piszpathswzględem pliku tsconfig) ioutFile(użyj bundlera).esModuleInterop: false,allowSyntheticDefaultImports: falseialwaysStrict: false: wszystkie trzy są zawsze włączone.
Kompilator mówi dokładnie, co usunąć:
error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
error TS5108: Option 'moduleResolution=node10' has been removed. Please remove it from your configuration.
Dwie stare formy składni też są błędami: module Foo { } dla przestrzeni nazw (pisz namespace Foo { }, a declare module "foo" dla pakietu działa bez zmian) i import assertions (assert { type: "json" } zamienia się w with { type: "json" }).
index.ts(2,8): error TS1540: A 'namespace' declaration should not be declared using the 'module' keyword. Please use the 'namespace' keyword instead.
Zmiana module na namespace w linii 2 to naprawia, a program wypisuje 4.
W wierszu poleceń tsc file.ts w folderze, w którym jest tsconfig.json, zatrzymuje się teraz z error TS5112, zamiast po cichu ignorować konfigurację. Uruchom samo tsc albo przekaż --ignoreConfig. W plikach JavaScript sprawdzanych przez JSDoc TypeScript 7 czyta typy bardziej tak jak w TypeScript: @enum nie jest już rozpoznawane, a wartość użyta jako typ wymaga typeof. Strona o tsconfig pokazuje zamiennik każdej usuniętej opcji.
Narzędzia, które nadal potrzebują TypeScript 6
TypeScript 7.0 nie ma stabilnego API dla JavaScriptu. require("typescript") zwraca tylko informacje o wersji (version i versionMajorMinor), a funkcji kompilatora wywoływanych przez inne narzędzia (createProgram, language service) tam nie ma. Punkty wejścia pakietu typescript/unstable/* są eksperymentalne i ich nie zastępują. Informacje o wydaniu mówią, że zespół spodziewa się nowego, innego API w TypeScript 7.1. Do tego czasu wszystko, co importuje kompilator jako bibliotekę, nadal używa TypeScript 6:
- typescript-eslint (reguły lintowania korzystające z typów)
- Narzędzia językowe dla plików Vue, Svelte i Astro, sprawdzanie typów w szablonach Angulara oraz MDX
- ts-node, który przy zainstalowanym TypeScript 7 wywraca się przy starcie
Dla nich TypeScript dostarcza pakiet zgodności @typescript/typescript6, który instaluje TypeScript 6 z pełnym API i poleceniem tsc6. Dzięki aliasom npm jeden projekt może mieć oba: TypeScript 7 buduje, a narzędzia, które importują typescript, dostają wersję 6.
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
Po npm install:
$ npx tsc --version
Version 7.0.2
$ npx tsc6 --version
Version 6.0.3
Jeśli nie używasz żadnego z tych narzędzi, zainstaluj zwykły typescript i pomiń ten krok.
Nowe opcje wiersza poleceń
Natywny kompilator parsuje, sprawdza i emituje równolegle. Sterują tym trzy nowe flagi, a informacje o wydaniu nazywają --checkers i --builders eksperymentalnymi:
| Flaga | Co robi |
|---|---|
--checkers N | Liczba workerów sprawdzania typów na projekt (domyślnie 4). Więcej może pomóc na maszynach z wieloma rdzeniami i kosztuje pamięć, mniej pasuje do małych runnerów CI. |
--builders N | Liczba projektów budowanych jednocześnie w --build z referencjami projektów. Mnoży się z --checkers: 4 buildery z 4 checkerami mogą uruchomić naraz 16 checkerów. |
--singleThreaded | Wyłącza całą równoległość, do debugowania albo przy ciasnych limitach pamięci. |
--watch też przepisano, na porcie do Go obserwatora plików z bundlera Parcel.
Obsługa w edytorach
Dla VS Code zespół TypeScript publikuje osobne rozszerzenie TypeScript 7. Po instalacji staje się ono domyślne, a polecenie "Disable TypeScript 7 Language Server" z palety poleceń przełącza z powrotem na TypeScript 6. Najnowsze Visual Studio włącza TypeScript 7 automatycznie na podstawie workspace, a inne edytory (Neovim, Zed, Sublime Text, Emacs) łączą się z nim przez Language Server Protocol. Projekty, które używają plików Vue, Svelte, Astro albo MDX lub szablonów Angulara, zostają przy obsłudze edytora opartej na TypeScript 6, dopóki TypeScript 7 nie udostępni API, z którego te narzędzia mogą korzystać. Projekt Angular może nadal uruchamiać tsc z TypeScript 7 do szybkiego sprawdzania całego projektu.
Jak zaktualizować do TypeScript 7
- Najpierw zaktualizuj do TypeScript 6, jeśli używasz 5.x:
npm install --save-dev typescript@6. Popraw każdy zgłoszony błąd przestarzałej opcji, zamiast go wyciszać przez"ignoreDeprecations": "6.0". - Włącz
"stableTypeOrdering": truew TypeScript 6 i popraw wszystko, co się zmieni. To konfiguracja, o której zespół mówi, że kompiluje się identycznie w 7. - Ustaw opcje, których wartości domyślne się zmieniły, jeśli projekt zależał od starych wartości, na przykład
"types": ["node"]i"rootDir": "./src". - Zainstaluj TypeScript 7:
npm install --save-dev typescript@latest. Potem możesz usunąćstableTypeOrdering, bo w 7 jest zawsze włączone. - Sprawdź swoje narzędzia. Jeśli używasz typescript-eslint, ts-node albo frameworka ze sprawdzaniem typów w szablonach, skonfiguruj pokazany wyżej alias TypeScript 6.
- Potwierdź wersję przez
npx tsc --versioni upewnij się, że CI instaluje z zaktualizowanego lockfile.
tsgo i wersje preview
Przed wydaniem natywny kompilator był publikowany jako @typescript/native-preview z poleceniem tsgo, żeby dało się go wypróbować obok tsc w JavaScripcie. Artykuły z 2025 i początku 2026 roku mówią o tsgo. Od wersji 7.0 ta nazwa zniknęła z codziennego użytku: natywny kompilator to tsc, a jego wersje nightly są publikowane jako typescript@next (obecnie wersje rozwojowe 7.1).
Najczęściej zadawane pytania
Czym jest TypeScript 7?
TypeScript 7 to pierwsze wydanie kompilatora TypeScript przepisanego w Go i skompilowanego do natywnego programu, zamiast działania jako JavaScript w Node.js. Sprawdza typy tego samego języka tym samym poleceniem tsc, a według informacji o wydaniu pełne budowanie jest zwykle od 8 do 12 razy szybsze niż w TypeScript 6. Premiera odbyła się 8 lipca 2026.
Czy TypeScript 7 jest napisany w Go?
Tak. Kompilator i language service przeniesiono z TypeScript do Go (projekt miał nazwę kodową Corsa, a baza kodu w JavaScripcie Strada). Nadal instalujesz go z npm jako pakiet typescript, a npm wybiera gotowy natywny plik binarny dla twojego systemu operacyjnego i procesora.
Czy muszę zmienić kod pod TypeScript 7?
Zwykle nie kod, czasem konfigurację. TypeScript 7 usuwa opcje oznaczone w 6.0 jako przestarzałe (target: es5, moduleResolution: node, baseUrl, outFile i inne) i zmienia wartości domyślne, takie jak strict: true i types: []. Kod, który czysto kompiluje się w TypeScript 6.0 z włączonym stableTypeOrdering i bez ignoreDeprecations, powinien skompilować się identycznie.
Czym jest tsgo?
tsgo to nazwa polecenia w wersjach preview natywnego kompilatora, publikowanych jako pakiet npm @typescript/native-preview przed wydaniem 7.0. W TypeScript 7 natywny kompilator to po prostu tsc w pakiecie typescript, a wersje nightly pochodzą z typescript@next.
Czy typescript-eslint działa z TypeScript 7?
Nie bezpośrednio. TypeScript 7.0 nie ma stabilnego API dla JavaScriptu, a narzędzia takie jak typescript-eslint, ts-node oraz narzędzia sprawdzające szablony Vue, Svelte i Angulara wywołują to API. Zostaw dla nich zainstalowany TypeScript 6 przez pakiet @typescript/typescript6 (alias npm), a do budowania używaj tsc z TypeScript 7. Zespół TypeScript spodziewa się, że TypeScript 7.1 dostarczy nowe, inne API.