TypeScript 7.0 RC – nowy kompilator w Go i migracja bez bólu

Stało się! 18 czerwca 2026 roku Microsoft wypuścił wersję Release Candidate dla TypeScript - wersja 7.0. Tym razem najważniejsza zmiana nie dotyczy jednak nowej składni, nowych operatorów czy jeszcze mądrzejszego wywnioskowywania typów. Tym razem zmiany zaszły w samych fundamentach.

Dotychczasowy kompilator był napisany w TypeScript, kompilowany do JavaScriptu i uruchamiany w środowisku Node.js. W TypeScript 7.0 jego kod został przepisany na język Go. Dzięki wykonywaniu kodu natywnego, współdzielonej pamięci oraz pracy na wielu wątkach, nowy kompilator jest - według doniesieć Microsoftu - do około dziesięciu razy szybszy od TS 6.0. Co ważne, nie jest to całkowite napisanie mechanizmu typów od zera, tylko metodyczny port istniejącej implementacji. Logika sprawdzania typów ma pozostać strukturalnie kompatybilna wstecz.

Krótko mówiąc: to ten sam TypeScript, ten sam tsconfig.json, ta sama komenda tsc - tylko z zupełnie nowym silnikiem pod maską. Ale czy oznacza to, że możemy po prostu zainstalować nową wersję i zapomnieć o problemie wolnego kompilatora? Niestety, nie do końca.

TypeScript 7.0 - nowy kompilator, stara komenda

Przez dłuższy czas natywna wersja TypeScriptu była publikowana jako osobny pakiet @typescript/native-preview, a jej kompilator uruchamialiśmy poleceniem tsgo.

Od wersji RC nie musimy już pamiętać o tej nazwie. TypeScript 7.0 ponownie korzysta ze standardowego pakietu typescript i udostępnia zwyczajną komendę tsc.

npm install -D typescript@rc

npx tsc --version
npx tsc --noEmit

To ważne z punktu widzenia codziennej pracy - nie musimy przepisywać żadnych skryptów, zmieniać konfiguracji CI ani tłumaczyć całemu zespołowi, że tsgo jest teraz właściwym kompilatorem.

Od strony użytkownika wszystko wygląda znajomo. Największe różnice zaczynają się dopiero pod maską.

A pod maską?

Nowy kompilator wykonuje wiele rzeczy równolegle, między innymi:

parsowanie plików,
sprawdzanie typów,
generowanie kodu,
budowanie projektów korzystających z project references.

O ile parsowanie i emitowanie kodu można stosunkowo łatwo podzielić pomiędzy pliki, to sprawdzanie typów jest bardziej skomplikowane, ponieważ informacje z jednego pliku mogą zależeć od typów z wielu innych części kodu.

TypeScript 7.0 rozwiązuje ten problem za pomocą określonej liczby niezależnych workerów sprawdzających typy. Domyślnie uruchamiane są cztery, ale ich liczbę możemy zmienić flagą --checkers.

npx tsc --checkers 6

Więcej workerów może przyspieszyć duży projekt, ale jednocześnie zwiększy zużycie pamięci. Na niewielkim runnerze CI ustawienie wysokiej wartości może więc dać rezultat odwrotny do oczekiwanego.

Dla monorepozytoriów korzystających z project references pojawiła się również flaga --builders, która określa, ile projektów może być budowanych jednocześnie.

npx tsc --build --builders 2 --checkers 4

W tym przypadku mogą działać maksymalnie dwa równoległe buildery, z których każdy wykorzystuje do czterech checkerów. W skrajnym przypadku daje to osiem jednocześnie pracujących checkerów.

Do dyspozycji mamy także tryb jednowątkowy:

npx tsc --singleThreaded

Może on przydać się przy diagnozowaniu problemów, porównywaniu wydajności albo pracy w środowisku z bardzo ograniczoną ilością pamięci.

Czy to realny koniec wolnego `tsc`?

Według Microsoftu, TS 7.0 jest często około dziesięciu razy szybszy od TS 6.0. Zespół informuje również o dużych usprawnieniach w trybie --watch oraz w obsłudze projektu wewnątrz edytora. Nowy language server działa na bazie Language Server Protocol, dzięki czemu można go bardziej bezproblemowo integrować z edytorami kodu.

Tutaj trzeba jednak podkreślić, że jest tak "często", a nie "zawsze".

Największą różnicę powinny zauważyć duże projekty, w których kompilator przetwarza tysiące plików i może faktycznie rozdzielić pracę pomiędzy wiele rdzeni procesora. W małych aplikacjach, których sprawdzenie zajmuje sekundę, nawet dziesięciokrotne przyspieszenie nie zmieni szczególnie doświadczenia developera.

Dodatkowo tsc jest tylko jednym elementem całego procesu budowania aplikacji. Jeśli większość czasu zajmuje bundlowanie, testowanie, generowanie kodu albo inne czasochłonne zadania, nowy kompilator nie przyspieszy automatycznie wszystkich tych operacji.

Można więc powiedzieć, że TS 7.0 ma realną szansę zakończyć erę wolnego tsc. Nie oznacza to jednak, że każdy pipeline nagle będzie działał dziesięć razy szybciej, ale najpierw trzeba zmierzyć, czy to faktycznie u nas wąskie gardło.

time npx tsc --noEmit

Takie pomiary najlepiej wykonać kilka razy, zarówno lokalnie, jak i na CI. W przypadku bardzo szybkich projektów pojedynczy wynik może być łatwo zaburzony przez cache systemu operacyjnego, obciążenie procesora lub inne działające procesy.

TypeScript 6.0 i migracja do TypeScriptu 7.0

Najbezpieczniejsza migracja do TypeScriptu 7.0 nie zaczyna się od zainstalowania tej wersji, tylko od uporządkowania poprzedniej.

Microsoft wprost opisuje TS 6.0 jako wydanie pomostowe pomiędzy dotychczasową implementacją a nowym kompilatorem. Jest to ostatnia główna wersja oparta na starej bazie kodu napisanej w TypeScript i JavaScript. Większość nowych wartości domyślnych, deprecations i breaking changes została wprowadzona właśnie po to, aby przygotować projekty na TS 7.0.

Pierwszym krokiem powinno być więc zainstalowanie stabilnego TypeScriptu 6 i doprowadzenie projektu do czystej kompilacji.

npm install -D typescript@^6

npx tsc --noEmit

Jeśli pojawiają się błędy dotyczące deprecated opcji, możemy tymczasowo dodać:

{
    "compilerOptions": {
        "ignoreDeprecations": "6.0"
    }
}

ignoreDeprecations nie naprawia konfiguracji. Pozwala jedynie odłożyć migrację na później. TypeScript 7.0 nie implementuje opcji wycofanych w TS 6.0, więc tego rodzaju ustawienie nie uratuje projektu po właściwej aktualizacji.

Dobrą definicją projektu gotowego na TS 7.0 jest więc projekt, który:

kompiluje się w TypeScript 6.0,
nie korzysta z ignoreDeprecations,
przechodzi sprawdzanie ze stableTypeOrdering,
ma jawnie określone najważniejsze opcje w tsconfig.json.

Jawny `tsconfig.json`

W starszych projektach często możemy znaleźć bardzo krótki tsconfig.json, który polega na wartościach domyślnych kompilatora.

Na przykład:

{
    "compilerOptions": {
        "outDir": "./dist",
        "baseUrl": "./src",
        "paths": {
            "@/*": ["*"]
        }
    },
    "include": ["src"]
}

Taki plik nie mówi nam żadnej z tych rzeczy:

czy projekt działa w trybie strict,
do jakiej wersji JavaScriptu kompilujemy kod,
jaki system modułów generujemy,
w jaki sposób mają być rozwiązywane importy,
jakie globalne typy powinny zostać wczytane,
jaki katalog jest rzeczywistym katalogiem źródłowym.

W TypeScript 5, część tych decyzji była podejmowana za nas. W TS 6 i 7 zmieniło się jednak kilka wartości domyślnych, co może być ważne dla wielu projektów legacy:

strict domyślnie wynosi true,
module domyślnie wynosi esnext,
target wskazuje najnowszą stabilną wersję ECMAScript przed esnext - w TS 6 jest to es2025,
noUncheckedSideEffectImports domyślnie wynosi true,
rootDir wskazuje katalog zawierający tsconfig.json,
types domyślnie jest pustą tablicą.

Bezpieczniej jest nie polegać na tych wartościach i zapisać najważniejsze decyzje bezpośrednio w konfiguracji.

Przykładowy projekt korzystający z bundlera mógłby wyglądać następująco:

{
    "compilerOptions": {
        "target": "ES2022",
        "module": "ESNext",
        "moduleResolution": "Bundler",

        "strict": true,
        "noUncheckedSideEffectImports": true,

        "rootDir": "./src",
        "outDir": "./dist",

        "types": ["node", "jest"],

        "paths": {
            "@/*": ["./src/*"]
        }
    },
    "include": ["src"]
}

Nie jest to uniwersalny tsconfig.json, który należy bezmyślnie skopiować do każdego repozytorium. Wartości target, types i sposób emitowania kodu muszą odpowiadać środowisku, w którym działa konkretna aplikacja.

Najważniejsze jest to, że konfiguracja jasno opisuje swoje założenia.

`strict`

Od TS 6.0 opcja strict jest domyślnie włączona.

Jeśli projekt już wcześniej korzystał z:

{
    "compilerOptions": {
        "strict": true
    }
}

to nic się nie zmienia.

Jeżeli jednak starszy projekt polegał na domyślnej wartości false, po aktualizacji może nagle otrzymać dużą liczbę błędów. W takim przypadku możemy jawnie zachować stare zachowanie:

{
    "compilerOptions": {
        "strict": false
    }
}

Nie jest to docelowy ideał, ale pozwala oddzielić migrację kompilatora od osobnego projektu polegającego na wprowadzaniu pełnego strict mode. Najpierw stabilizujemy konfigurację, a dopiero potem można stopniowo zaostrzać typowanie.

`module` i `moduleResolution`

Dla aplikacji uruchamianej bezpośrednio w Node.js, najczęściej właściwą parą będzie:

{
    "compilerOptions": {
        "module": "NodeNext",
        "moduleResolution": "NodeNext"
    }
}

Dla aplikacji przetwarzanej przez bundler:

{
    "compilerOptions": {
        "module": "ESNext",
        "moduleResolution": "Bundler"
    }
}

Dotychczasowe moduleResolution: "node" – nazywane również node10 – opisuje stary sposób rozwiązywania modułów z czasów Node.js 10. W TS 6 zostało oznaczone jako deprecated, natomiast TS 7 już w ogóle go nie obsługuje. Microsoft rekomenduje wartość "nodenext" dla aplikacji uruchamianych w Node.js, oraz "bundler" dla aplikacji przetwarzanych przez bundler lub Bun.

`target`

Domyślny target jest obecnie wartością ruchomą. W TypeScript 6 wskazuje es2025, ale w kolejnych wersjach kompilatora może wskazywać nowszy standard.

To wygodne dla nowych projektów korzystających wyłącznie z aktualnych środowisk, ale mniej wygodne dla powtarzalnych buildów.

Dlatego warto określić target jawnie:

{
    "compilerOptions": {
        "target": "ES2022"
    }
}

Nie oznacza to, że ES2022 jest zawsze najlepszym wyborem. Trzeba wybierać standard obsługiwany przez najstarsze środowiska, na których rzeczywiście ma działać aplikacja. Ważne, aby była to świadoma decyzja, a nie przypadkowy efekt aktualizacji TypeScriptu.

`types` domyślnie jako pusta tablica

W TypeScript 5 i wcześniejszych wersjach kompilator automatycznie przeglądał dostępne katalogi node_modules/@types i dodawał znajdujące się tam pakiety do globalnego zakresu typów. Dzięki temu projekt mógł korzystać z takich nazw jak:

process,
Buffer,
describe,
it,

mimo że odpowiednie pakiety nie zostały jawnie wpisane do tsconfig.json.

W TS 6 wartością domyślną types jest []. Oznacza to, że potrzebne globalne deklaracje należy wskazać samodzielnie:

{
    "compilerOptions": {
        "types": ["node", "jest"]
    }
}

Nazwy podajemy bez prefiksu @types/. Pakiet @types/node wpisujemy więc jako node, a @types/jest jako jest. Stare zachowanie, jeśli jest taka potrzeba, można przywrócić poprzez:

{
    "compilerOptions": {
        "types": ["*"]
    }
}

Nie jest to jednak rekomendowane rozwiązanie docelowe. Jawna lista sprawia, że kompilacja jest bardziej przewidywalna i nie wciąga przypadkowych globalnych typów z zależności. Według obserwacji zespołu Microsoftu, samo odpowiednie ustawienie types poprawiało czas kompilacji niektórych projektów o 20-50%.

Nowe domyślne `rootDir`

Wcześniej TypeScript próbował samodzielnie wywnioskować wspólny katalog źródłowy projektu.

Dla struktury:

project/
├── src/
│   └── index.ts
├── dist/
└── tsconfig.json

kompilator mógł uznać src za katalog główny i wygenerować:

dist/index.js

Od TS 6 domyślnym rootDir jest katalog zawierający tsconfig.json. W tym samym projekcie rezultat może więc wyglądać następująco:

dist/src/index.js

Jeśli chcemy zachować poprzednią strukturę, powinniśmy też jawnie dodać:

{
    "compilerOptions": {
        "rootDir": "./src",
        "outDir": "./dist"
    },
    "include": ["src"]
}

Zmiana upraszcza pracę kompilatora, ponieważ nie musi on najpierw analizować wszystkich plików, aby określić wspólny katalog źródłowy. Pomaga również language server szybciej ustalić, do którego projektu może należeć konkretny plik.

Koniec `baseUrl`

baseUrl jest jedną z najbardziej podstępnych zmian w tej migracji.

W wielu projektach opcja ta była używana wyłącznie jako wspólny prefiks dla wpisów w paths:

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

Problem polega na tym, że baseUrl nie służył wyłącznie jako prefiks - stawał się również dodatkowym miejscem, w którym TypeScript próbował rozwiązywać wszystkie importy bez ścieżki względnej.

Import:

import * as helpers from "helpers.js";

mógł więc zostać odnaleziony jako:

src/helpers.js

nawet jeśli autor konfiguracji chciał jedynie utworzyć aliasy zaczynające się od @app/ i @lib/.

W TS 7 baseUrl nie został ponownie zaimplementowany. Zamiast niego należy usunąć opcję i wpisać pełne prefiksy bezpośrednio do paths:

{
    "compilerOptions": {
        "paths": {
            "@app/*": ["./src/app/*"],
            "@lib/*": ["./src/lib/*"]
        }
    }
}

Jeżeli projekt rzeczywiście korzystał z baseUrl jako miejsca rozwiązywania wszystkich importów, możemy zachować zachowanie za pomocą mapowania:

{
    "compilerOptions": {
        "paths": {
            "*": ["./src/*"],
            "@app/*": ["./src/app/*"],
            "@lib/*": ["./src/lib/*"]
        }
    }
}

Jest to jednak znacznie rzadszy przypadek. Najczęściej wystarczy usunąć baseUrl i uzupełnić ścieżki.

Pozostałe deprecated opcje i konstrukcje

`target: "es5"`

TypeScript 7 nie obsługuje już generowania kodu ES5. Najniższym kierunkiem jest ES2015.

Jeżeli aplikacja nadal musi działać w środowisku wymagającym ES5, TypeScript powinien wygenerować nowszy kod, który zostanie następnie przetworzony przez zewnętrzny toolchain.

Razem z ES5 znika również sens korzystania z:

{
    "compilerOptions": {
        "downlevelIteration": true
    }
}

Ta opcja dotyczyła właśnie emitowania starszego kodu.

`outFile`

outFile zostało usunięte już w TypeScript 6.0.

Jego zadaniem było łączenie wielu plików wejściowych w jeden plik wynikowy. Obecnie tę pracę wykonują bundlery, które mają znacznie więcej możliwości optymalizacji, dzielenia kodu i obsługi zasobów.

TypeScript ma zajmować się przede wszystkim sprawdzaniem typów i generowaniem deklaracji. Bundlowanie należy do bundlera - webpack, vite etc..

Stare systemy modułów

TS 7 nie obsługuje wartości:

amd
umd
systemjs
none

dla opcji module.

Współczesne projekty powinny korzystać z ESM, CommonJS przez odpowiednią konfigurację Node albo z kodu przekazywanego dalej do bundlera.

`esModuleInterop: false`

Opcje:

{
    "compilerOptions": {
        "esModuleInterop": false,
        "allowSyntheticDefaultImports": false
    }
}

nie mogą już zostać ustawione na false. Bezpieczniejsza obsługa interoperacyjności pomiędzy CommonJS i ESM jest zawsze włączona.

Może to wymagać poprawienia części starszych importów:

// Wcześniej
import * as express from "express";

// Obecnie
import express from "express";

`module` używane jako namespace

Stara składnia:

module Application {
    export const version = "1.0";
}

powinna zostać zastąpiona przez:

namespace Application {
    export const version = "1.0";
}

Nie dotyczy to deklaracji modułów zewnętrznych:

declare module "some-package" {
    export function run(): void;
}

Taka składnia nadal pozostaje prawidłowa.

Import assertions

Starsza składnia import assertions: lang:typescript import data from "./data.json" assert { type: "json" };

została zastąpiona przez import attributes:

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

Warto wyszukać takie importy w całym repozytorium, ponieważ mogą znajdować się również w wywołaniach dynamicznego import().

Uwaga na `tsc file.ts`

Starsze skrypty CI lub komendy, mogą uruchamiać TypeScript w następujący sposób:

tsc src/index.ts

Jeśli w aktualnym katalogu istnieje tsconfig.json, TypeScript 6 zgłosi błąd. Podawanie plików bezpośrednio w command line powodowało bowiem, że konfiguracja projektu była całkowicie ignorowana, co często prowadziło do zaskakujących rezultatów.

Standardowo powinniśmy uruchamiać cały projekt:

tsc --project tsconfig.json

Jeśli rzeczywiście chcemy pominąć konfigurację, musimy zrobić to jawnie:

tsc --ignoreConfig src/index.ts

Dzięki temu intencja polecenia nie pozostawia wątpliwości.

Automatyczna migracja za pomocą `ts5to6`

Część zmian wokół baseUrl i rootDir może zostać wykonana automatycznie przez narzędzie ts5to6. Jeśli nie boimy się automatów wykonujących trudne migracje, to warto spróbować.

npx @andrewbranch/ts5to6 --fixBaseUrl .
npx @andrewbranch/ts5to6 --fixRootDir .

Dla konfiguracji o innej nazwie możemy podać konkretny plik:

npx @andrewbranch/ts5to6 --fixBaseUrl ./tsconfig.app.json
npx @andrewbranch/ts5to6 --fixRootDir ./tsconfig.app.json

Narzędzie potrafi przechodzić po references oraz szukać powiązanych konfiguracji korzystających z extends; jest szczególnie przydatne w monorepozytoriach, w których ręczna zmiana kilkunastu plików łatwo prowadzi do pomyłek.

Nadal jest to jednak narzędzie eksperymentalne. Po jego uruchomieniu warto sprawdzić, czy nasza aplikacja dalej się poprawnie transpiluje i działa prawidłowo. Codemod powinien wykonać mechaniczną część pracy, ale to do nas należy potwierdzenie, że rezultat odpowiada oczekiwaniom.

`stableTypeOrdering` – test zgodności TS 6 i TS 7

Jedna z trudniejszych zmian polega na kolejności typów.

W TypeScript 6 wewnętrzne identyfikatory typów były nadawane w kolejności, w której kompilator napotykał poszczególne konstrukcje. Mogło to wpływać na kolejność elementów unii generowanych w plikach deklaracji.

Przykładowo:

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

mogło wygenerować:

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

Po dodaniu niezwiązanej deklaracji wcześniej w tym samym pliku kolejność mogła zmienić się na:

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

Dla TypeScriptu oba typy są równoważne - ale różnica powoduje szum w snapshotach i porównaniach plików .d.ts. W TypeScript 7 sprawdzanie typów działa równolegle. Gdyby każdy worker nadawał identyfikatory według własnej kolejności pracy, rezultat mógłby stać się niedeterministyczny. Dlatego TS 7 korzysta ze stabilnego sortowania opartego na zawartości typów i symboli.

TypeScript 6 udostępnia flagę, która pozwala wcześniej zasymulować to zachowanie:

npx tsc --noEmit --stableTypeOrdering

Warto uruchomić również generowanie deklaracji:

npx tsc \
    --declaration \
    --emitDeclarationOnly \
    --stableTypeOrdering \
    --outDir .tmp/types-ts6

Następnie, możemy porównać błędy oraz pliki .d.ts z rezultatem TypeScriptu 7.

Flaga nie jest przeznaczona do stałego używania w TS 6 - w zależności od projektu może spowolnić sprawdzanie t0ypów nawet o około 25%. Służy przede wszystkim do wykrywania różnic migracyjnych. W TS 7 stabilna kolejność jest włączona zawsze i nie można jej wyłączyć.

Jeśli po włączeniu flagi pojawi się błąd wnioskowania, często pomaga jawne podanie typu:

// Wcześniej
someFunction(value);

// Po migracji
someFunction<ExpectedType>(value);

albo dodanie adnotacji do zmiennej:

const value: ExpectedType = createValue();

TypeScript 6 i 7 obok siebie

TypeScript 7.0 RC jest gotowy do używania jako kompilator CLI, ale jego stabilne programmatic API ma pojawić się najwcześniej w TS 7.1.

Ma to znaczenie dla narzędzi, które nie tylko wywołują tsc, ale importują pakiet typescript bezpośrednio i korzystają z Compiler API. Dotyczy to między innymi części integracji lintujących, generatorów kodu i własnych skryptów analitycznych.

Microsoft udostępnił pakiet @typescript/typescript6, dzięki któremu możemy zainstalować obie wersje jednocześnie:

{
    "devDependencies": {
        "typescript": "npm:@typescript/typescript6@^6.0.0",
        "typescript-7": "npm:typescript@rc"
    }
}

Pakiet kompatybilności udostępnia komendę tsc6, natomiast TypeScript 7 nadal korzysta z tsc.

npx tsc6 --noEmit
npx tsc --noEmit

Dzięki temu narzędzia wymagające API TypeScriptu 6 mogą nadal importować pakiet typescript, a sam projekt może być równolegle sprawdzany nowym kompilatorem.

Migracja krok po kroku

Najbezpieczniejszy proces może wyglądać następująco.

Krok 1: zapisz punkt odniesienia

Uruchom testy, pełny build i generowanie deklaracji. Zapisz również czas kompilacji:

time npx tsc --noEmit

Bez punktu odniesienia nie będziemy wiedzieli, czy nowy kompilator rzeczywiście poprawił sytuację, czy będziemy mieli raczej do czynienia co najwyżej z efektem placebo.

Krok 2: przejdź na TypeScript 6

npm install -D typescript@^6
npx tsc --noEmit

Na tym etapie nie instalujemy jeszcze TS 7.

Krok 3: ustaw jawne wartości

Sprawdź przede wszystkim:

strict
target
module
moduleResolution
types
rootDir
noUncheckedSideEffectImports

Nie trzeba zmieniać ich wszystkich, ale trzeba wiedzieć, jakie wartości faktycznie mamy zadeklarowane.

Krok 4: usuń deprecated opcje

Wyszukaj:

baseUrl
target: es5
downlevelIteration
moduleResolution: node
moduleResolution: node10
moduleResolution: classic
outFile
module: amd
module: umd
module: systemjs
esModuleInterop: false
allowSyntheticDefaultImports: false
alwaysStrict: false

W razie potrzeby skorzystaj z ts5to6.

Krok 5: usuń `ignoreDeprecations`

Projekt powinien kompilować się bez tej opcji. W przeciwnym razie część problemów nadal tylko siedzi w ukryciu.

Krok 6: uruchom `stableTypeOrdering`

npx tsc --noEmit --stableTypeOrdering

Porównaj również generowane deklaracje, zwłaszcza jeśli publikujesz bibliotekę.

Krok 7: uruchom TypeScript 7.0 RC

npm install -D typescript@rc
npx tsc --noEmit

W większych projektach bezpieczniej najpierw robić to w osobnym jobie CI, który nie blokuje głównego pipeline’u.

Krok 8: porównaj rezultaty

Sprawdź:

błędy typów,
pliki .d.ts,
wygenerowany JavaScript,
testy,
integracje z linterem,
skrypty używające Compiler API,
zachowanie edytora.

Krok 9: dopiero teraz dostrajaj wydajność

Zacznij od ustawień domyślnych. Następnie przetestuj inne wartości --checkers, a w monorepo --builders.

Nie zakładaj automatycznie, że najwyższa liczba daje najlepszy rezultat. Szybsze sprawdzanie typów okupione zbyt dużym zużyciem pamięci może zamiast tego pogorszyć pracę CI.

Na zakończenie

TypeScript 7.0 jest jedną z największych zmian infrastrukturalnych w historii tego języka. Kod, który piszemy, nadal wygląda znajomo, ale mechanizm odpowiedzialny za jego analizę został przeniesiony na całkowicie nowy fundament.

Kompilator napisany w Go faktycznie może zakończyć wieloletnie narzekania na wolne działanie tsc, zwłaszcza w dużych repozytoriach i monorepo. Największe ryzyko migracji nie wynika jednak z języka Go ani z równoległego sprawdzania typów, ale z wieloletniego polegania na niejawnych wartościach w tsconfig.json.

Dlatego najbezpieczniejsza droga do TypeScriptu 7.0 prowadzi przez uporządkowany TypeScript 6.0: usunięte deprecated opcje, jawne types, rootDir, moduleResolution i target, a na końcu test ze stableTypeOrdering. Gdy projekt przechodzi ten etap bez błędów, podmiana starego kompilatora na nowy przestaje być wielką migracją, a sprowadza się do uruchomienia jednej komendy

TypeScript 7.0 RC – nowy kompilator w Go i migracja bez bólu

TypeScript 7.0 - nowy kompilator, stara komenda

A pod maską?

Czy to realny koniec wolnego tsc?

TypeScript 6.0 i migracja do TypeScriptu 7.0

Jawny tsconfig.json

strict

module i moduleResolution

target

types domyślnie jako pusta tablica

Nowe domyślne rootDir

Koniec baseUrl