Rychlý tsc je jen začátek

Microsoft oznámil nativní port TypeScriptu v březnu 2025. Tehdy slíbil zhruba řádové zrychlení buildů, rychlejší start editoru a nižší paměťovou stopu. V dubnu 2026 následovala TypeScript 7.0 Beta, veřejně použitelná přes balík @typescript/native-preview@beta a příkaz tsgo.

Lákavý titulek by zněl jednoduše: TypeScript přepsaný do Go je desetkrát rychlejší. Důležitější je změna role TypeScriptu v toolingu. Kompilátor dlouho fungoval zároveň jako běžná npm knihovna, do které mohl framework, editorový plugin nebo interní nástroj sáhnout přes ts.Program, checker, transformery nebo tsserver. V TypeScriptu 7 už tenhle předpoklad neplatí automaticky. Nový základ tvoří nativní kompilátor, paralelní checker, LSP server a teprve vznikající programové API.

Microsoft interně používá označení Strada pro původní JavaScriptovou větev a Corsa pro nový port. TypeScript 6.0 proto není běžná major verze, ale přechodový release: poslední verze postavená na staré kódové základně a zároveň most k sedmičce. Kdyby šlo jen o rychlejší binárku, nebylo by potřeba vydávat meziverzi, měnit výchozí nastavení, zavádět diagnostické přepínače a připravovat kompatibilní balík @typescript/typescript6.

Migraci rozhodne programové API

U TypeScriptu jsme si zvykli, že kompilátor je zároveň knihovna. Spousta nástrojů si vytvoří ts.Program, sáhne do checkeru, použije Compiler API, napojí vlastní transformer nebo jede přes plugin do tsserveru. V TypeScriptu 7 tahle jistota zatím neplatí.

Microsoft v oznámení bety píše otevřeně, že stabilní programové API nebude hotové při vydání 7.0 a má přijít nejdřív v TypeScriptu 7.1 nebo později. Proto existuje přechodový balík @typescript/typescript6, který poskytuje tsc6 a reexportuje staré API. Praktický přechodový model je dvojkolejný: tsgo, později tsc ze sedmičky, pro rychlé buildy a typové kontroly; TypeScript 6 pro nástroje, které importují typescript jako knihovnu.

Hlavní migrační problém je v nástrojích, které TypeScript nevolají jen jako CLI. Frameworkové kompilátory a jazykové servery stojí jinde než jednoduchý npm skript. Diskuse kolem Astro language serveru a roadmapa Angularu ukazují stejný vzorec: problém není syntaxe TypeScriptu, ale to, že frameworky TypeScript často hostují, rozšiřují nebo obcházejí jeho interní API. Angular to formuluje přímo: patří mezi projekty s nejhlubší integrací do TypeScript compileru, takže podpora tsgo bude vyžadovat větší architektonické změny.

Při migraci se ukáže, kolik nástrojů v JavaScriptovém ekosystému nestojí jen na CLI, ale na detailech kompilátorového API. Starý model byl pohodlný, jen nebyl zadarmo. Platilo se za něj latencí, pamětí a slabší možností paralelizace.

Co se zrychluje a proč na tom záleží

Výkonová čísla jsou výrazná, ale patří k nim opatrnost. Prosincový update Microsoftu uvádí u plných buildů mimo jiné zrychlení VS Code 10,2×, Sentry 8,19×, TypeORM 9,88× a Playwrightu 7,51×. Pořád jde o měření dodavatele, ne o nezávislou studii, ale rozdíl není v jednotkách procent.

Zrychlení nestojí na samotné volbě Go. TypeScript 7 využívá nativní kód a paralelismus se sdílenou pamětí. V betě Microsoft popisuje paralelizaci parsingu, type-checkingu i emitu a přidává nové přepínače: --checkers pro počet type-checker workerů a --builders pro paralelní build více projektů přes project references. Pro monorepa je důležitá právě paralelizace project references, kde se dřív část času ztrácela čekáním na jeden dlouhý graf závislostí.

Praktický dopad začíná ve chvíli, kdy se typová kontrola vrátí blíž k běžné práci vývojáře. Když typecheck trvá minuty, týmy ho přesouvají do CI, spouštějí selektivně, obcházejí přes skipLibCheck nebo oddělují od lokální práce. Když se stejná kontrola dostane pod hranici, kterou vývojář ještě vnímá jako součást editovací smyčky, přestává být typový systém vzdálenou kontrolou na konci procesu.

Velké TypeScriptové kódové základny z toho mohou těžit hlavně tam, kde dnes používají project references spíš z nutnosti než z radosti. Ani s TypeScriptem 7 nezmizí potřeba orchestrátorů a správy monorepa typu Nx, Rush, pnpm workspaces nebo Bazel, ale může se zkrátit běh jednotlivých typových kontrol uvnitř jejich grafu. Orchestrátor pořád rozhoduje, co se má spustit. tsgo rozhoduje, jak dlouho poběží konkrétní typecheck.

Paralelismus přináší nové ladění

Paralelní kompilátor přidává do buildu další parametr: počet workerů a jejich paměťové nároky. Microsoft u --checkers upozorňuje, že vyšší počet workerů může zrychlit větší kódové základny, ale obvykle zvýší paměťovou spotřebu. U kombinace --checkers 4 --builders 4 může běžet až 16 checkerů najednou, což na běžném CI runneru nemusí být výhra.

Proto v betě existuje také --singleThreaded. Hodí se při ladění, při porovnávání TypeScriptu 6 a 7, v prostředí s omezenými prostředky nebo tam, kde paralelismus řídí externí build systém. U větších repozitářů nebude stačit změřit jeden cold build na vývojářském notebooku. Bude potřeba najít nastavení, které dává smysl pro lokální práci i pro CI.

Důležité je i deterministické chování. TypeScript 6 přidal přepínač --stableTypeOrdering, aby stará větev lépe odpovídala pořadí typů v sedmičce. Release notes TypeScriptu 6.0 upozorňují, že tento režim může podle kódové základny zpomalit type-checking až o 25 %. Není to kosmetické nastavení. Přechod na paralelní interní model sahá do míst, která se projeví v declaration emit výstupech, diffech a reprodukovatelnosti buildu.

Jednoduché srovnání rychlosti tady přestává stačit. Pokud aplikace spouští tsc --noEmit a čte exit code, bude migrace nejspíš poměrně přímočará. Pokud knihovna publikuje .d.ts, build generuje sourcemapy, CI spoléhá na tsbuildinfo nebo se typová kontrola skládá s vlastním cache systémem, nestačí porovnat jeden plný build. Je potřeba měřit i no-op build, změnu v balíčku bez dalších závislých projektů, paměť, emitované artefakty a chování po změně závislostí.

Editor bude rychlejší, ale ne všude stejně

Editorová část může být pro každodenní práci důležitější než CI. Microsoft už v prvním oznámení uváděl, že načtení kódové základny VS Code v editoru kleslo zhruba z 9,6 s na 1,2 s a paměťová stopa byla přibližně poloviční. K betě Microsoft dál doporučuje TypeScript Native Preview extension pro VS Code, která vznikla už v rámci dřívějších native preview buildů a používá novou jazykovou službu postavenou na LSP.

Přechod na LSP dává technicky smysl. TypeScriptový tsserver byl dlouho de facto standardem, ale zároveň šlo o specifický protokol s vlastními zvyklostmi. Architektura postavená na LSP může usnadnit integraci mimo VS Code a lépe sedí k dnešnímu editorovému prostředí. U konkrétních editorů ale bude záležet na jejich vlastní podpoře a na tom, jak rychle dozraje nová language service.

Aktuální README repozitáře microsoft/typescript-go ke dni přípravy článku uvádí language service jako „in progress“, watch mode jako „prototype“ a API jako „not ready“. Stejný dokument označuje parsing, type checking, emit, build mode, project references a incremental build jako hotové, ale výslovně varuje, že projekt ještě není v plné paritě s TypeScriptem.

To je potřeba číst doslova. Editor může projekt načíst výrazně rychleji a běžné akce typu completion, hover nebo go-to-definition mohou působit lépe. Současně není rozumné předpokládat, že všechny okrajové editorové příkazy, pluginy a watch scénáře budou ve všech kódových základnách fungovat stejně jako zralý tsserver.

Starší tsconfig bude potřeba uklidit

Microsoft využívá přechod na TypeScript 7 také k úklidu starých konfiguračních voleb. První část úklidu přichází už v TypeScriptu 6: strict je nově výchozí, module míří na esnext, target na aktuální stabilní ECMAScript, types už automaticky nenasává všechno z node_modules/@types, rootDir se chová předvídatelněji a baseUrl končí jako podporovaná volba. V TypeScriptu 7 se část dříve podporovaných voleb mění v tvrdý problém místo pouhého varování.

Nejvíc se to projeví u starších repozitářů s historickým tsconfig.json, hybridních JavaScript/TypeScript projektů a kódových základen, které si dlouho držely implicitní chování. U rootDir Microsoft popisuje velmi praktický důvod: dřívější odvozování společného kořenového adresáře vyžadovalo analyzovat vstupní soubory dopředu. Nové výchozí chování je méně magické a pomáhá výkonu.

V issue trackerech se to nejspíš bude objevovat jako „TypeScript 7 mi rozbil build“, ale často půjde o odložený dluh v konfiguraci. Přechod přes TypeScript 6 proto dává smysl i týmům, které chtějí se sedmičkou počkat. Šestka ukáže deprecace, dovolí je dočasně ignorovat a dá čas narovnat tsconfig dřív, než z nich sedmička udělá tvrdý problém.

Zvláštní pozornost si zaslouží JavaScript a JSDoc. TypeScript 7 sjednocuje analýzu JavaScriptových souborů s TypeScriptem a odřezává část historické podpory pro Closure styl, constructor functions, některé expando patterny a volnější JSDoc interpretace. CHANGES.md to popisuje poměrně otevřeně: cílem je modernější a jednodušší model, ne přesná reprodukce všech starých idiomů. Pro čistý TypeScript to nemusí být téma. Pro repozitáře s velkým podílem JavaScriptu ano.

Jak testovat bez zbytečného rizika

Rozumný přechod na TypeScript 7 nezačíná přepsáním hlavního typecheck skriptu. Začíná měřením vedle stávající cesty. Praktický postup je nainstalovat @typescript/native-preview@beta, přidat paralelní skript typecheck:tsgo, ponechat běžný typecheck na TypeScriptu 6 a několik dní sbírat čísla z lokálu i CI.

Měřit má smysl víc než jeden scénář. Plný build po smazání cache ukáže nejviditelnější rozdíl. Warm no-op build ukáže, jestli inkrementální režim skutečně pomáhá. Změna v balíčku bez dalších závislých projektů ukáže, jak se chová project-reference graf. Editorový startup a několik LSP operací ukáže, jestli se zrychlení projeví tam, kde vývojář tráví nejvíc času. U knihoven přidejte diff emitovaných .d.ts a sourcemap.

Minimální přechodový model může vypadat takto:

{
  "scripts": {
    "typecheck:tsc6": "tsc6 -b tsconfig.json --extendedDiagnostics",
    "typecheck:tsgo": "tsgo -b tsconfig.json --extendedDiagnostics"
  }
}Code language: JSON / JSON with Comments (json)

K tomu stačí porovnávat wall-clock čas, CPU čas, maximum RSS, Check time, Emit time, výstupní artefakty a počet nalezených chyb. Pokud se čísla i výstupy chovají dobře, lze tsgo zapnout nejdřív jako dobrovolnou lokální rychlou cestu, pak jako neblokující CI job a teprve potom jako hlavní blokující kontrolu.

U CI bych byl opatrný hlavně u tsbuildinfo, změn závislostí a dlouhých monorepo grafů. Není to argument proti TypeScriptu 7. Je to argument proti tomu, aby se beta zapnula jako jediná kontrola bez možnosti návratu.

Kdo může zrychlit hned a kdo má počkat

TypeScript 7 je důležitý kvůli tomu, že rychlost kompilátoru ovlivňuje každodenní návyky týmu. Rozhoduje, jak často se spouští kontrola, jak rychle vývojář dostane zpětnou vazbu v editoru, jestli se tým nebojí většího refactoringu a zda si může dovolit přísnější typovou konfiguraci bez toho, aby trestal každého committera.

Současně to není release srovnatelný s výměnou bundleru za rychlejší bundler. TypeScript je u mnoha týmů součást interního toolingu, frameworkového compileru, lintovací infrastruktury, editoru a publish pipeline. Právě tam bude sedmička potřebovat opatrnost.

Střízlivá strategie pro rok 2026 je přejít nejdřív na TypeScript 6, opravit deprecace, narovnat tsconfig, spustit tsgo paralelně a měřit. Týmy s čistým CLI typecheckem mohou na TypeScriptu 7 vydělat rychle. Týmy s custom transformery, tsserver pluginy, frameworkovým compilerem nebo starší JSDoc kódovou základnou by měly počkat na stabilnější API, sledovat rozdíly popsané v typescript-go a mezitím si připravit záložní cestu.

Pokud TypeScript 7 dopadne dobře, nezmění jen délku čekání na tsc. Posune hranici toho, co ještě dává smysl pouštět při každém uložení, každém pull requestu a každém větším refactoringu. Týmy pak mohou typovou kontrolu znovu používat jako součást běžné práce vývojáře, ne až jako pomalou kontrolu na pozadí.