Sprawdzanie versus uruchamianie: Jak kompilator Go w TypeScript 7 pasuje do twojego zestawu narzędzi
Dowiedz się, co naprawdę przyspiesza wbudowany kompilator Go w TypeScript 7, dlaczego narzędzia takie jak Angular i typescript-eslint pozostają w tyle, oraz jak oddzielić sprawdzanie typów od wykonywania kodu.
Źródła: TypeScript 7 Moved Its Compiler to Go. Here’s What Actually Changes
TypeScript 7 zastępuje kompilator samodzielnie uruchamiany wersją natywną napisaną w Go, a podane liczby są na tyle duże, że mogą wprowadzać zamieszanie co do tego, co faktycznie staje się szybsze. Twoje JavaScript używane w produkcji w ogóle nie zmienia swojej szybkości; zmieniają się natomiast twoja edytor, narzędzie do sprawdzania typów w procesie CI oraz procesy budowania monorepo. Jednocześnie Node, Bun i Vite uczyniły kompilator TypeScript opcjonalnym przy uruchamianiu i przekształcaniu kodu. Ten przewodnik rozdziela te aspekty, abyś mógł zdecydować, co należy zaktualizować, na czym poczekać oraz jak zorganizować zestaw narzędzi, w którym sprawdzanie i wykonywanie to dwa odrębne zadania.
Zasięg TypeScript sprawia, że warto to zrobić poprawnie. W sierpniu 2025 roku GitHub poinformował, że TypeScript stał się najczęściej używanym językiem wśród miesięcznych współtwórców, wyprzedzając zarówno Python, jak i JavaScript – ponad 2,6 miliona osób codziennie przyczynia się do rozwijania kodu napisanego w tym języku. Zmiana w podstawach tego ekosystemu ma wpływ na frameworki, narzędzia do sprawdzania kodu, menedżery pakietów oraz edytory, przy czym nie wszystkie z nich rozwijają się w tym samym tempie.
Od kompilatora self-hosted do natywnego
Przed wersją 7 tsc był programem typu bootstrapped. Jego źródłem był TypeScript, który był kompilowany do JavaScriptu, a ten JavaScript uruchamiany w Node w celu analizy, sprawdzania i przetwarzania projektów innych osób. Samodzielne hostowanie jest cenioną praktyką dla kompilatorów, a taka architektura umożliwiła rozwojowi tego języka przez dekadę gwałtownego wzrostu. Jego ograniczeniem jest jednak środowisko wykonawcze JavaScriptu: pojedyncza główna wątek, pamięć typu heap zarządzana przez mechanizm garbage collection, która nigdy nie była optymalizowana pod ogromne struktury w pamięci składające się z węzłów składniowych i typów, oraz ograniczone możliwości udostępniania tych danych pomiędzy różnymi procesami.
Odpowiedzią Microsoftu była adaptacja, a nie przepisanie kodu. Baza kodowa w Go celowo odzwierciedla strukturę i zachowanie istniejącej implementacji, więc system typów oraz jego semantyka mają pozostać niezmienione. Zmienia się natomiast podstawa, na której one opierają się: kod maszynowy typu native, wątki mogące dzielić się pamięcią oraz znacznie większe możliwości wykonywania zadań równolegle. Właśnie z tego powodu Go okazało się rozwiązaniem praktycznym – jego model pamięci i kolektor śmieci umożliwiają zespołowi przeniesienie istniejącego kodu przy użyciu podobnych struktur danych, zamiast projektowania wszystkiego od nowa wokół reguł własności.
Opublikowane testy wydajności pokazują, że typowe pełne budowanie aplikacji jest 8 do 12 razy szybsze:
- Baza kodu VS Code skraca się z 125,7 sekundy przy TypeScript 6 do 10,6 sekundy przy TypeScript 7.
- Czas pełnego budowania Playwright zmniejsza się z 12,8 sekundy do 1,47 sekundy.
„TypeScript jest dziesięć razy szybszy” to dokładne podsumowanie tych danych. Jest jednak łatwe do błędnego zrozumienia, ponieważ nie precyzuje, co jest dziesięć razy szybsze.
Co staje się szybsze, a co nie
Weźmy mały, zwykły fragment kodu typowanego: interfejs oraz obiekt, który do niego pasuje.
interface User {
id: string;
name: string;
}
const user: User = {
id: '42',
name: 'Arthur',
};
Niezależnie od narzędzia, które go kompiluje, przeglądarka lub serwer otrzymują w końcu zwykły JavaScript bez informacji o typach:
const user = {
id: '42',
name: 'Arthur',
};
W czasie wykonywania nie ma pojęcia, który kompilator przetworzył źródło ani w jakim języku został on zaimplementowany. Widzi jedynie wygenerowany JavaScript, a ten wynik jest taki sam jak wcześniej. Dlatego przepisanie tsc na Go nie ma żadnego wpływu na szybkość działania Twojej aplikacji. Jeśli strona działa wolno lub obsługa API jest obciążona procesorem, TypeScript 7 nic w tym nie zmieni.
Zyski są widoczne już we wczesnym etapie rozwoju, gdy TypeScript działa nieprzerwanie: podczas ładowania projektów, obliczania diagnoz, dostarczania sugestii i funkcji znajdowania wszystkich odniesień, monitorowania plików oraz ponownej weryfikacji budowy w środowisku CI. Jeden wskaźnik dobrze to ilustruje – otwarcie pliku zawierającego błąd w repozytorium VS Code zajmowało wcześniej około 17,5 sekundy przed pojawieniem się pierwszej diagnozy; z TypeScript 7 czas ten spada poniżej 1,3 sekundy. Nowy serwer językowy jest zbudowany na bazie Language Server Protocol, może wykorzystywać wiele wątków, a Microsoft donosi również o znacznie mniejszej liczbie nieudanych poleceń serwera językowego oraz awarii.
Przydatne ujęcie sytuacji brzmi tak: sama aplikacja nie staje się szybsza, ale praca z nią tak. W dużym kodzie lub monorepo skrócenie czasu każdej weryfikacji typów o kilka minut oraz czasu diagnozowania błędów w edytorze o kilka sekund zmienia cały cykl informacyjny, z którym mamy do czynienia przez cały dzień. To rzeczywisty wzrost produktywności, chociaż żaden użytkownik tego nie zauważy.
Pozostałe zmiany w wersji TypeScript 7
Kompilator natywny dominuje w dyskusjach, ale kilka podsystemów zostało zbudowanych wokół niego.
Paralelizm, który można dostosować
Analiza składni, generowanie kodu oraz części weryfikacji typów mogą przebiegać równolegle, a budowanie projektów z odniesieniami umożliwia jednoczesne kompilowanie kilku projektów, co jest szczególnie ważne w monorepo. Można wyraźnie zwiększyć liczbę procesów zajmujących się weryfikacją typów:
tsc --checkers 8
Lub wyłącz całkowicie paralelizm w przypadku maszyn o ograniczonych zasobach lub gdy chcesz zachowania deterministycznego podczas debugowania:
tsc --singleThreaded
Odrębna flaga --builders kontroluje, ile budowań odnośników projektu jest wykonywanych jednocześnie. Traktuj je jako elementy do dostrojenia, a nie jako przełączniki typu „maksymalnie wszystko”. Każdy dodatkowy procesor pamięciowy zajmuje własną część programu w pamięci, więc runner CI z wieloma rdzeniami, ale ograniczoną ilością RAM-u, może być wolniejszy lub wyczerpać pamięć, jeśli po prostu dopasujesz liczbę procesorów do liczby rdzeni. Zmierz wydajność na swoich rzeczywistych runnerach przed ustawieniem tej wartości.
Zmodyfikowany tryb obserwacji
--watch został również ponownie zaimplementowany. Zespół najpierw próbował bardziej konwencjonalnych, międzyplatformowych rozwiązań dostępnych w Go, ale monitorowanie systemu plików okazało się zbyt kosztowne w dużych projektach. Ostatecznie przenieśli pomysły z narzędzia do monitorowania plików w C++ od Parcel do Go i stworzyli nowy mechanizm monitorowania, który ma na celu lepsze wykorzystanie zasobów w różnych systemach operacyjnych.
Nowe domyślne ustawienia i usunięte opcje starsze
TypeScript 7 kontynuuje zmiany konfiguracyjne wprowadzone podczas przejścia na TypeScript 6:
strictjest włączony domyślnie.- Domyślną wartością dla
modulejest terazesnext. typesrozpoczyna się jako pusta tablica, więc globalne pakiety typów nie są już automatycznie pobierane.target: es5został usunięty.- Klasyczne rozwiązywanie problemów z modułami zostało usunięte.
baseUrl nie jest już obsługiwany.tsconfig.json, który nie był modyfikowany od czasów, gdy Internet Explorer stanowił problem przy wdrażaniu, prawdopodobnie wymaga uwagi. Szczególnie zmiana w polu types może powodować mnóstwo błędów typu „nie można znaleźć nazwy” dotyczących globalnych zmiennych testowych lub wbudowanych funkcji Node, dopóki nie wymienisz pakietów, od których zależysz. Jeśli jeszcze nie zajmowałeś się tymi standardowymi ustawieniami, nasz praktyczny przewodnik migracji dotyczący zmieniających się standardowych ustawień TypeScript 6.0 omawia je szczegółowo, a te same poprawki mają zastosowanie również tutaj.
Najważniejszym aspektem jest brak w TypeScript 7.0 stabilnej, programowej API. Dla wielu projektów ma to większe znaczenie niż jakikolwiek flag lub domyślna wartość, ponieważ to ona decyduje o tym, czy narzędzia współpracujące z kompilatorem w ogóle mogą funkcjonować.
Dlaczego ekosystem nie może zmienić się od ręki
Uruchamianie kompilatora z terminala oraz tworzenie narzędzi na jego bazie to zupełnie różne podejścia. Wiele frameworków, narzędzi językowych i linterów nie polega wyłącznie na uruchamianiu pliku binarnego:
tsc
Ładują TypeScript jako bibliotekę i proszą ją o drzewa składni, rozwiązane typy, odpowiedzi z usługi językowej oraz inne elementy wewnętrzne kompilatora. Zastąpienie tej API jest przewidziane w TypeScript 7.1, a do tego czasu Microsoft oficjalnie wspiera instalację obu głównych wersji równolegle. W chwili pisania tego tekstu oznacza to, że wiele zespołów będzie używać natywnego kompilatora do sprawdzania w linii poleceń, podczas gdy ich integracje z edytorami i narzędzia do analizy kodu nadal będą ładować wersję opartą na JavaScript.
Pod wpływem tego znajduje się kilka popularnych narzędzi:
- Kontrola typów w szablonach Angular jest ściśle zintegrowana z TypeScript, dlatego pełne wsparcie edytora Angular musi na razie pozostać przy starszej usłudze językowej.
- Narzędzia do pracy z Vue, Astro, Svelte, MDX oraz innymi formatami, które zawierają TypeScript w innych typach plików, napotykają podobne ograniczenia do momentu wprowadzenia nowej API.
To wszystko nie jest wadą portu. Taki właśnie wygląda proces migracji kluczowego narzędzia w rzeczywistym ekosystemie: silnik jest gotowy, zanim wszystko do niego dodane zostanie dostosowane.
Cztery sposoby, w jakie narzędzie może polegać na TypeScript
typescript-eslint jest dobrym przykładem tego zjawiska. Sam ESLint nie jest oparty na kompilatorze TypeScript, więc twierdzenie, że „ESLint stał się szybszy, ponieważ TypeScript przeniósł się na Go”, byłoby po prostu błędne. typescript-eslint natomiast stanowi most, który umożliwia ESLint analizowanie składni TypeScript oraz, w przypadku reguł uwzględniających typy, uzyskiwanie informacji o typach z TypeScript. Obecny parser nadal polega na starszej API kompilatora, mimo że projekt eksperymentuje z implementacją natywną. Twórcy wyraźnie się przygotowują, ale wdrożenie TypeScript 7 nie polega jedynie na zwiększeniu numeru wersji.
To przykład pokazuje różnicę, o której warto pamiętać, gdy ktoś mówi, że narzędzie „wykorzystuje TypeScript”. Istnieje co najmniej cztery różne rodzaje związków:
- Napisane w TypeScript. Sam kod źródłowy narzędzia jest napisany w tym języku. Narzędzie korzysta na szybszej walidacji typów i kompilacji przez jego utrzymujących, ale użytkownicy nie zauważają żadnych zmian.
- Rozpoczyna działanie z TypeScript. Środowiska takie jak Node i Bun przyjmują pliki
.tsjako dane wejściowe bez udziału narzędziatsc. - Tranformuje TypeScript. Narzędzia do pakowania i transpilacji usuwają informacje o typach oraz przepisują składnię, przechodząc po jednym pliku.
- Zależy od semantyki TypeScript. Narzędzia do sprawdzania kodu z regułami uwzględniającymi typy, usługi językowe frameworków oraz edytory potrzebują kompilatora, aby zrozumieć cały program.
Domowy port zmienia się w zależności od kategorii w różny sposób. Tylko ostatnia z nich wymaga API kompilatora, i to właśnie ta kategoria musi czekać na wersję 7.1.
Menedżer pakietów w trakcie migracji
pnpm pokazuje, jak te kategorie ze sobą współpracują. Jest to duże monorepo w TypeScript z wieloma pakietami, rozbudowanym procesem CI oraz intensywną analizą w edytorze, co teoretycznie czyni je idealnym beneficjentem TypeScript 7. Ostatecznie tak powinno być. Tymczasem jego utrzymujący muszą również zapewnić poprawne działanie typescript-eslint, a integracja tego lintera nadal jest powiązana ze starszą interfejsem kompilatora. Łańcuch zależności wygląda mniej więcej tak:
pnpm
↓
typescript-eslint
↓
TypeScript compiler API
↓
TypeScript 6 — for now
Warto również jasno określić, co doświadczą użytkownicy pnpm. TypeScript 7 nie sprawia, że ten polecenie będzie szybsze:
pnpm install
Instalowanie pakietów to zachowanie pnpm w czasie wykonywania, a pnpm działa jako JavaScript w Node, niezależnie od tego, który kompilator sprawdził jego kod źródłowy. To, co TypeScript 7 może poprawić, to doświadczenie przy rozwijaniu pnpm: sprawdzanie typów, uruchamianie procesów CI oraz inne procesy sterowane przez kompilator. Nawet te ulepszenia pojawiają się tylko z taką szybkością, jak najsłabszy element w jego grafie zależności. Duży projekt nie może przyjąć fundamentalnej zmiany szybciej niż narzędzia, od których zależy.
Gdzie korzyści są natychmiastowe
Projekty, które potrzebują jedynie kompilatora jako narzędzia do weryfikacji z linii poleceń oraz serwera językowego, mogą od razu skorzystać z tych korzyści. Najlepszym przykładem jest VS Code: ogromna baza kodu napisana w TypeScript, która służy milionom programistów jako narzędzie do codziennej pracy z tym językiem. Skrócenie czasu pełnej kompilacji z ponad dwóch minut do około dziesięciu sekund ma znaczenie; skrócenie czasu oczekiwania na pierwszą diagnozę edytora z około siedemnastu sekund do nieco ponad jednej sekundy jest czymś, co każdy może odczuć.
Playwright, jeden z projektów służących do testowania wydajności firmy Microsoft, skraca czas pełnej kompilacji przy użyciu domyślnej konfiguracji z 12,8 sekundy do 1,47 sekundy. To jednak nie oznacza, że Playwright uruchamia Chromium szybciej – oznacza to po prostu, że utrzymywanie i sprawdzanie własnego kodu Playwright staje się znacznie szybsze. Biorąc pod uwagę, że wiele narzędzi dla programistów jest napisanych w TypeScript, szybsze utrzymywanie tych narzędzi przynosi korzyści dla całego ekosystemu.
Vite traktuje już sprawdzanie typów i transformację jako oddzielne zadania
Vite jest głównie napisany w TypeScript, ale podczas serwowania lub budowania aplikacji typu TypeScript nie wywołuje kompilatora TypeScript w celu transpilacji każdego modułu. Nowoczesny Vite wykorzystuje dedykowany pipeline transformacji i celowo pomija sprawdzanie typów. Jego dokumentacja zaleca uruchamianie TypeScript oddzielnie, jako jednorazową weryfikację:
tsc --noEmit
lub w sposób ciągły podczas rozwoju:
tsc --noEmit --watch
Uzasadnienie jest słuszne. Przekształcenie pliku wymaga jedynie usunięcia adnotacji, przepisania kilku konstrukcji i dalszej pracy. Sprawdzanie typów wymaga znajomości całego drzewa modułów, ponieważ zmiana w jednym pliku może zakłócić funkcjonowanie innego. Wykonywanie obu czynności w jednym kroku zmusza szybką operację do oczekiwania na wolniejszą. Dlatego typowy projekt Vite ma dwa równoległe ścieżki wychodzące z tego samego źródła:
┌── Vite / Oxc ── transform ──> Browser
TypeScript source ──┤
└── TypeScript ───── type-check
Z tej perspektywy TypeScript 7 nie musi stać się najszybszym transformatorem JavaScriptu, ponieważ Vite posiada już narzędzie zoptymalizowane do tego celu. TypeScript może skupić się na zadaniach wymagających zrozumienia całego programu, a te zadania są teraz znacznie szybsze. Jeśli używasz tej konfiguracji obecnie, jedną z praktycznych konsekwencji jest to, że błąd typu nie zatrzymuje serwera deweloperskiego; upewnij się, że polecenie tsc --noEmit jest wykonywane w środowisku CI lub w hooku przed wysłaniem zmian, aby błędy nie mogły przejść niezauważone.
Narzędzia do JavaScriptu napisane we wszystkim oprócz JavaScriptu
Istnieje tu szerszy trend. Obecny proces budowania w Vite wykorzystuje Rolldown, a zarówno Rolldown, jak i Oxc są napisane w języku Rust. esbuild już lata temu wybrał Go. Bun implementuje duże części siebie w języku Zig. Teraz do nich dołączył TypeScript z użyciem Go.
To nie jest krytyka języka JavaScript. Interfejsy publiczne wciąż wydają się naturalne dla programistów JavaScript i TypeScript, podczas gdy intensywne obliczeniowo procesy analizy, rozwiązywania problemów i interpretacji odbywają się jako kod natywny. Różne warstwy mają różne wymagania, a TypeScript 7 jest najważniejszym przykładem z ostatnich lat wyboru języka implementacji dla poszczególnych warstw.
Środowiska wykonawcze, które uruchamiają TypeScript bez tsc
To samo podział występuje również po stronie środowiska wykonawczego. Tradycyjny model mentalny projektu typu TypeScript zakładał prostą ścieżkę od źródła przez kompilator do JavaScript, a następnie do Node:
TypeScript
↓
tsc
↓
JavaScript
↓
Node.js
W rzeczywistych projektach zawsze było więcej kroków, ale podstawa pozostawała ta sama: Node uruchamiał JavaScript, więc TypeScript musiał najpierw zostać przekształcony w JavaScript. Dziś to działa bezpośrednio:
node server.ts
Kluczowym szczegółem jest to, że Node nie uruchamia kompilatora TypeScript. Jego wbudowana obsługa jest celowo minimalna: usuwa elementy składni TypeScript, które można usunąć, i wykonywa to, co pozostaje. Nie przeprowadza sprawdzania typów, a składnia wymagająca generowania rzeczywistego JavaScriptu (zamiast po prostu usuwania adnotacji) nie podlega temu modelowi usuwania. Deklaracja typowana, taka jak ta:
const port: number = 3000;
przed wykonaniem faktycznie staje się następująca:
const port = 3000;
Słowem kluczowym jest „Erasable”. Konstrukcje takie jak enum, namespace z wartościami w czasie wykonywania lub właściwości parametrów konstruktora tworzą kod JavaScript, którego nie było w źródle, więc czyste usuwanie elementów nie może sobie z nimi poradzić. TypeScript oferuje opcję kompilatora erasableSyntaxOnly, aby oznaczyć takie konstrukcje, jeśli chcesz, aby twój kod pozostał kompatybilny z usuwaniem typów; sprawdź aktualną dokumentację Node i TypeScript, aby poznać dokładne zachowanie w Twoich wersjach.
Ta funkcjonalność istniała już przed Node 26, więc bezpośrednie uruchamianie TypeScript nie powinno być przedstawiane jako cecha Node 26. Node 26 przynosi własne zmiany, w tym Temporal włączone domyślnie, nowszą wersję V8, kolejne istotne uaktualnienie Undici oraz standardową oczyszczoną wersję po dużym wydaniu, ale to już inny temat. Dla tej dyskusji ważny jest kierunek rozwoju: Node coraz częściej traktuje TypeScript jako dane, które może bezpośrednio przetwarzać, nie prosząc najpierw o program tsc o wygenerowanie JavaScriptu.
Bun traktuje TypeScript jako zwykłe dane wejściowe
Bun, który nadal używa wersji 1.x, od samego początku funkcjonował w ten sposób. Uruchomienie pliku TypeScript polega po prostu na:
bun server.ts
Loader Bun usuwa i modyfikuje składnię TypeScript przed jej wykonaniem, wykorzystując własne narzędzia. I ponownie – transpilacja nie polega na sprawdzaniu typów. Dlatego doskonale funkcjonujący proces w Bun składa się z dwóch poleceń:
tsc --noEmit
bun server.ts
Pierwsze odpowiada na pytanie „czy ten program spełnia wymogi systemu typów?”. Drugie odpowiada na pytanie „czy ten program może działać?”. Współczesny Node obsługuje takie samo rozdzielenie:
tsc --noEmit
node server.ts
W obu przypadkach silnik w czasie wykonywania nigdy nie czeka na sprawdzacz typów, a sprawdzacz typów nie musi tworzyć plików wyjściowych. Należy pamiętać, że projekt uruchamiany w ten sposób nie ma kroku budowania, który przypadkowo wykryłby błędy typów; jeśli sprawdzenie nie jest włączone do procesu CI, po prostu się to nie wydarzy.
Zadaniem TypeScript jest lepsze zrozumienie programów
Przez lata proces pracy skupiał się w jednej łańcuchowej procedurze, gdzie kompilator znajdował się bezpośrednio pomiędzy pisaniem a uruchamianiem kodu:
Write TypeScript
↓
Compile TypeScript
↓
Run JavaScript
Współczesne narzędzia coraz częściej przypominają dwie gałęzie wychodzące z tego samego źródła – jedną do rozumienia i sprawdzania, a drugą do transformacji i wykonywania:
┌── TypeScript ── understand and check
TypeScript source ────────┤
└── Runtime / bundler ── transform and execute
Vite może wykorzystywać Oxc do transformacji kodu, podczas gdy tsc sprawdza go. Node sam usuwa składnię, którą można usunąć. Bun ma swój własny loader. Żaden z tych narzędzi nie wymaga TypeScript 7 ani żadnego tsc, aby uruchomić aplikację. Właśnie dlatego kompilator natywny wciąż ma znaczenie: najważniejszym zadaniem TypeScript nie jest już szybkie przekształcanie pliku .ts w plik .js, co inne narzędzia już robią dobrze. Jego prawdziwa wartość leży w kwestiach dotyczących całego programu, takich jak:
- Czy ta wartość jest kompatybilna z kontraktem, do którego została przekazana?
- Czy refaktoryzacja uszkodziła jakąś funkcję w innym pakiecie?
- Czy to ograniczenie typu jest poprawne?
- Do czego odnosi się ten symbol i gdzie jeszcze jest używany ten typ?
- Jakie uzupełnienia powinien zaproponować edytor w tym miejscu?
Aby sprostać tym wymaganiom, potrzebny jest znacznie większy kontekst niż usunięcie : string z linii kodu, a analiza całego programu to właśnie ta część, którą wersja dla Go przyspiesza znacznie. Aby dowiedzieć się więcej na temat uruchamiania TypeScript w sposób natywny w tych narzędziach, zapoznaj się z naszym przewodnikiem migracyjnym dotyczącym kompilatora TypeScript dla Go i natywnego uruchamiania.
Główne wnioski
- TypeScript 7 to port istniejącego kompilatora do Go, a nie przebudowa języka; generowany JavaScript oraz wydajność aplikacji w czasie działania pozostają bez zmian.
- Korzyści są widoczne podczas rozwoju: pełne budowanie projektu jest zazwyczaj 8 do 12 razy szybsze, diagnostyka w edytorze odbywa się znacznie szybciej, a serwer językowy jest bardziej stabilny.
--checkers, --builders oraz --singleThreaded zgodnie z rzeczywistymi ograniczeniami pamięci w środowisku CI, zamiast ślepo maksymalizować liczbę procesorów.typescript-eslint mogą zmusić cię do używania TypeScript 6 w niektórych integracjach, a działanie obu wersji równocześnie jest obsługiwane.tsconfig.json pod kątem nowych standardów oraz usuniętych opcji (strict, module, types, cel ES5, klasyczne rozwiązywanie konfliktów typów, AMD/UMD, baseUrl). tsc --noEmit jako obowiązkowy element procesu CI.Pozycje pokrewne
- Zmiany w JavaScriptie w 2026 roku: środowiska wykonywania, TypeScript 7 i narzędzia do Rusta — Przewodnik po zmianach w ekosystemie JavaScripta przewidzianych na 2026 rok: konkurencja między Bun, Deno i Node.js, przepisanie TypeScripta na bazie Go oraz narzędzia do budowania aplikacji oparte na Rustzie — z wyjaśnieniem, co naprawdę ma znaczenie dla programistów.
- Rola „mostu” TypeScript 6 w drodze do natywnego kompilatora TS 7 — Dowiedz się, w jaki sposób TypeScript 6 aktualizuje domyślne konfiguracje, mechanizmy rozwiązywania modułów oraz składnię importów, aby przygotować bazy kodowe na szybszy kompilator TypeScript 7 oparty na Go.