Porównanie wydajności kompilatora Go w TypeScript 7 w rzeczywistym aplikacji Next.js

Tylko 412 plików, sprawdzone dwa razy przy użyciu dwóch różnych wersji kompilatora. W TypeScript 6 sprawdzenie zajęło 3,8 sekundy, natomiast w TypeScript 7 – 0,41 sekundy. Narzędzie do sprawdzania typów jest funkcjonalnie takie samo pod spodem.

Dane opublikowane przez Microsoft wskazują na przyspieszenie od 8 do 12 razy mierzone w VS Code. Liczy się tutaj to, co pokazuje polecenie tsc --extendedDiagnostics w danym repozytorium. Zadanie CI, które wcześniej zatrzymywało się przy nieudanej operacji generowania kodu Prisma, nie staje się nagle dziesięć razy szybsze tylko dlatego, że narzędzie do sprawdzania typów przyspieszyło – tylko ta jedna etapa staje się szybsza. Wszystko późniejsze w łańcuchu pozostaje dokładnie tak wolne, jak wcześniej.

Otwórz terminal.

Pomij next dev. Przejdź bezpośrednio do samego narzędzia sprawdzającego, uruchom je z katalogu głównego aplikacji:

pnpm exec tsc --noEmit --extendedDiagnostics

Zwróć uwagę na wartość Check time, którą wyświetla. To jedna linijka jest jedynym parametrem wartym śledzenia aż do samego końca.

Microsoft wydał TypeScript 7.0 8 lipca 2026 roku. Sam system typów się nie zmienił, a plik kompilatora nadal nazywa się tsc, ale wewnętrznie jest to teraz port kompilatora napisany w języku Go. Tabela z ogłoszenia dotyczącego wersji 1.0 pokazuje, że czas sprawdzania w VS Code spadł z 125,7 sekundy do 10,6 sekundy. Ta liczba odnosi się do własnego kodu Microsoftu, a nie do typowego projektu Next.js.

To, co jest naprawdę przydatne, to odpowiednia liczba dla małej aplikacji Next.js z czterema ścieżkami, która jest już testowana we wszystkich innych aspektach, wraz z dodatkową informacją: ile kosztuje next build, gdy używany jest nowy narzędzie sprawdzające. Równie ważne jest udokumentowanie rodzaju błędu, który pojawia się, gdy automatyczny pull request zakłada, że „szybsze działanie” i „inne zachowanie” oznaczają to samo.

Południowy proces CI skłamał na temat błędu typu

Wyobraźmy sobie zespół, który we wtorek zaktualizował zależność typescript do wersji 7 w aplikacji do wystawiania faktur, ponieważ artykuł na blogu obiecywał 10-krotny wzrost szybkości. Proces CI znacznie szybciej zmienił kolor na zielony. Zachęcony tym, jeden z recenzentów zatwierdził i połączył pomocnik branded-id, który okazało się nie sprawdzać typów na lokalnym komputerze kolegi z zespołu.

Pomocnik skompilował się pomyślnie na CI tylko dlatego, że CI nadal rozwiązywało problem z wersją 6 biblioteki typescript poprzez zależność w głównym workspace’u. Tymczasem na lokalnym komputerze zainstalowana była bezpośrednio wersja 7. Sam system typów się nie zmienił — to właśnie jest sedno twierdzenia Microsoftu — ale plik tsconfig na CI odwoływał się do aliasu pakietu @typescript/typescript6, który pozostał po wpisie z czasów wersji próbnej i nigdy nie został usunięty.

Zatem prawdziwym problemem nie było to, że TypeScript 7 zachowywał się inaczej. Chodziło o dwa oddzielne pliki binarne kompilatora, niespójny plik lockfile oraz wiadomość w Slacku twierdzącą, że „7 jest już dostępne”, podczas gdy w rzeczywistości tak nie było, przynajmniej nie wszędzie.

Oto jak to wyglądało w praktyce: prośba o integrację zatytułowana „usuń przekształcenia as InvoiceId, wersja 7 jest bardziej rygorystyczna”. W rzeczywistości TypeScript 7 nie był tutaj bardziej rygorystyczny. Ten sam commit aktywował również flagę kompilatora erasableSyntaxOnly, co stanowi zupełnie odrębną zmianę zasad i będzie przedmiotem osobnej dyskusji później. Łączenie czystego ulepszenia wydajności z zmianą zasad behawioralnych jest dokładnie tym, co powoduje powstawanie takich mityów.

Rozwiązaniem jest podzielenie takiego commita na dwie części: sam wzrost wersji oraz osobną zmianę zasad. Dopiero wtedy pomiary czasu mają jakikolwiek sens.

Zdanie, które faktycznie opublikowała Microsoft

W oficjalnym komunikacie o wydaniu TypeScript 7.0 z dnia 8 lipca 2026 roku Daniel Rosenwasser opisał to wydanie jako dostarczające możliwość wykonania kodu w języku natywnym, przetwarzanie wielowątkowe za pomocą pamięci wspólnej oraz szereg optymalizacji, które generalnie przyspieszają działanie o 8 do 12 razy przy pełnych budowach.

Część tego komunikatu, którą większość ludzi pomija, to informacja o tym, że system typów pozostaje niezmieniony.

Zgodnie z komunikatem, nowa implementacja oparta na Go została przeniesiona z istniejącej poprzez staranny proces portowania, a nie zbudowana od podstaw; jej zachowanie w zakresie sprawdzania typów jest strukturalnie identyczne z TypeScript 6.0.

W tym opisie aktualizacji nie ma żadnej nowej składni. Zmieniła się jedynie szybkość wykonywania dla tej samej logiki podstawowej. Jeśli po podniesieniu wersji pojawią się błędy typu, nie jest to zachowanie oczekiwane — to błąd, który warto zgłosić.

Next.js 16.3 dodał dokumentację wskazującą, że next build będzie używał TypeScript 7 do sprawdzania typów, jeśli w projekcie zainstalowany jest TypeScript 7 jako bezpośrednia zależność. Dzięki temu masz drugie źródło do pomiaru czasu, oprócz osobnego uruchomienia tsc.

Dwa zegary, których faktycznie użyłem

Przez cały czas używano tego samego aplikacji testowej. Next.js 16.3, React 19, cztery trasy, tabela faktur oraz flaga kompilatora wyłączona podczas tej sesji, aby liczby się nie mieszały.

Zegar pierwszy: tsc --noEmit --extendedDiagnostics. Zegar drugi: next build, z uwagą obserwując linię dotyczącą sprawdzania typów w jego wynikach.

Dodałem TypeScript 7 do projektu jako zależność.

pnpm add -D typescript@7

Wykonywalny plik nadal nazywa się tsc. W fazie wstępnej pakiet nosił nazwę @typescript/native-preview, a jego plik binarny nazywał się tsgo. Takie nazewnictwo zostało porzucone, ponieważ to już stabilna wersja. Jeśli natrafisz na jakikolwiek materiał lub temat, który nadal odnosi się do tsgo, dotyczy to okresu wstępnego, a nie obecnego narzędzia.

Aby obie główne wersje mogły współistnieć na dysku, Microsoft opublikował dodatkowy pakiet @typescript/typescript6. Udostępnia on plik binarny tsc6, dzięki czemu zwykły polecenie tsc może odwoływać się do wersji 7, nie rezygnując przy tym z narzędzi i zespołów, które nadal polegają na wersji 6.

pnpm add -D @typescript/typescript6

Następnie, używając tego samego pliku tsconfig.json dla obu wersji:

pnpm exec tsc6 --noEmit --extendedDiagnostics
pnpm exec tsc --noEmit --extendedDiagnostics

To same pliki źródłowe. Ta sama ustawienie strict. Te same aliasy ścieżek, które wygenerował Next.js podczas tworzenia projektu za pomocą create-next-app.

Każda komenda została wykonywana trzy razy, a pierwsze wykonanie zostało odrzucone, ponieważ szybki cache systemu plików nie stanowi realistycznego pierwszego sprawdzenia.

Jak wyglądały liczby w tym kodzie

Aplikacja testowa ma cztery trasy oraz około 80 plików TypeScript należących do samego projektu, oprócz plików automatycznie generowanych przez Next.js.

Wykonywanie TypeScript 6.0 za pomocą tsc6, przy użyciu mediany z dwóch zachowanych wykonań:

• Plików sprawdzonych: 412
• Czas sprawdzenia: 3,82 sekundy
• Ogólny czas: 4,25 sekundy

Wykonywanie TypeScript 7.0 za pomocą tsc, przy identycznej konfiguracji:

• Plików sprawdzonych: 412
• Czas sprawdzenia: 0,41 sekundy

Czas całkowity: 0,60 sekundy

To oznacza mniej więcej 9-krotny wzrost szybkości weryfikacji typów. Nie 12-krotny, i daleki od spadku z 125 sekund do 10 sekund, o którym czasami mowa w przypadku VS Code. To po prostu wynik uzyskany w tym konkretnym repozytorium.

Patrząc na krok weryfikacji typów wewnątrz next build:

• W wersji 6: 5,1 sekundy
• W wersji 7: 1,4 sekundy

Wszystko inne w next build — pakowanie i generowanie statycznych plików dla czterech tras — pozostało mniej więcej bez zmian. Jeśli w twoim pipeline CI najpierw uruchamia się lint, potem weryfikacja typów, następnie budowa, a na końcu testy end-to-end, to część związana z weryfikacją typów stała się wyraźnie krótsza, ale część testów end-to-end nie przynosi żadnych korzyści.

Drugi projekt, obciążony schematami Zod oraz około 300 plikami z logiką walidacji i obsługą, wykazał większy skok:

• Czas sprawdzenia wersji 6: 11,4 sekundy
• Czas sprawdzenia wersji 7: 1,3 sekundy

Wydaje się, że kod zawierający dużo typów przekłada się na większy wzrost wydajności. Mała strona marketingowa z kilkunastoma plikami nie pokazałaby nawet zbliżonego do 10-krotnego przyspieszenia, po prostu dlatego, że nie ma tam prawie nic, co narzędzie do sprawdzania mogłoby przetworzyć.

Błąd, który pojawił się po aktualizacji

To nie była zmiana w zachowaniu narzędzia do sprawdzania typów — to był problem z samym narzędziem.

eslint-plugin-react-hooks nadal uruchamiał typescript za pośrednictwem ustawienia parserOptions.project. Działało to poprawnie w wersji 7, ale uległo awarii podczas wcześniejszych miesięcy wersji roboczej tsgo. Stary blok parserOptions wskazywał nadal na oddzielny plik tsconfig.eslint.json, w którym ustawiono "compilerOptions": { "strict": false }, aby uniknąć komentarzy ze strony starszych testów.

CI używało tej łagodniejszej konfiguracji do sprawdzania kodu, podczas gdy tsc korzystało z rzeczywistej konfiguracji projektu. Dwie różne źródła prawdy. W rezultacie w narzędziu testowym pojawił się brak zasady noImplicitAny, który pozostał niezauważony przez narzędzie do sprawdzania kodu. Gdy wersja 7 sprawiła, że uruchamianie tsc stało się na tyle tanie, by robić to ciągle, dodałem opcję tsc --noEmit bezpośrednio do sprawdzeń w pull-requestach i całkowicie usunąłem uproszczoną konfigurację tsconfig przeznaczoną wyłącznie dla ESLint.

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "lint": "biome check .",
    "ci": "pnpm typecheck && pnpm lint && pnpm test && pnpm build"
  }
}

Rzeczywiste rozwiązanie nie było imponujące. Krążyła historia, że „wersja 7 zepsuła nasze typy”. To nie tak – to duplikowana konfiguracja to zrobiła.

Zanim zaufasz jakiejkolwiek liczbie, upewnij się, który plik binarny wykonywać te zadania.

pnpm exec tsc -v

W wynikach szukasz Version 7.x. Jeśli nadal widnieje tam numer 5 lub 6, twoja przestrzeń robocza korzysta z przestarzałej kopii z jakiegoś źródła. W monorepo z pnpm funkcja which skieruje cię w niewłaściwym kierunku, natomiast pnpm exec nie będzie miał takiego problemu.

Zrób diagnostykę trzy razy osobno i odrzuć wynik pierwszego wykonywania.

pnpm exec tsc --noEmit --extendedDiagnostics

Pole, na które należy zwrócić uwagę w tych wynikach: liczba przetworzonych plików, jaka część całkowitej objętości pochodzi z kodu biblioteki, jaka z definicji typów, a jaka to twój własny kod źródłowy, plus czas trwania sprawdzenia oraz całkowity czas wykonywania.

Następnie zainstaluj wersję 6 obok wersji 7 i skieruj je na ten sam zestaw plików.

pnpm add -D @typescript/typescript6
pnpm exec tsc6 --noEmit --extendedDiagnostics

Jeśli czas sprawdzania nie zmniejsza się o znaczącą liczbę wartości w bazie kodu składającej się z setek plików, albo faktycznie nie używasz wersji 7, albo twój przykład jest zbyt mały – tuzin plików nic ci nie pokaże.

Warto również wykonać next build dwa razy, po raz jeden dla każdego pliku binarnego, i za każdym razem zapisywać tylko linię dotyczącą sprawdzania typów. Nie łącz całkowitego czasu budowania w jeden opis szybkości TypeScript – Turbopack to odrębny system wykonujący oddzielne zadania.

Jeśli napotkasz błąd typu, który pojawia się w wersji 7, ale nie w wersji 6, przy identycznym pliku tsconfig, zgłoś to. To wykracza poza zakres omawianych tu kwestii. Sam Microsoft stwierdza, że logika sprawdzania pozostała strukturalnie niezmieniona, więc taka różnica to błąd, a nie coś, co należy traktować jako oczekiwany koszt migracji.

Gdzie naprawdę pochodzi szybkość

Zysk wynika bezpośrednio z samego narzędzia do sprawdzania kodu. Proces analizy i wiązania również stał się szybszy, ale to czas trwania sprawdzania jest wartością widoczną w logach CI i tą, którą faktycznie odczuwają użytkownicy.

Odpowiedź edytora to inna sprawa – dotyczy to usługi językowej, a nie samodzielnego kompilatora. W tabeli faktur działania nawigacyjne, takie jak przechodzenie do definicji, subiektywnie wydawały się szybsze. Nie zarejestrowano czasu reakcji na każde naciśnięcie klawisza, więc nie ma tu tabeli z czasem w milisekundach.

next dev oraz jego cykl szybkiego odświeżania nie stały się znacznie szybsze dzięki tej zmianie, ponieważ Fast Refresh i tak nigdy nie był blokowany podczas pełnego uruchomienia tsc.

Największe korzyści daje to w przypadku agentów lub zautomatyzowanych pętli, które uruchamiają tsc --noEmit po każdym pliku, który edytują. Pętla teraz działa na tyle szybko, że pominięcie tej weryfikacji przestaje być kuszącym skrótem. To jest prawdziwa, choć niewyrażona publicznie korzyść. Ten sam agent, który nadal tworzy zwykłe enum zamiast obiektów as const, otrzymuje teraz szybsze powiadomienia na ten temat.

Obliczanie rzeczywistych kosztów

Instalacja: jedna aktualizacja zależności oraz usunięcie pozostałego skryptu tsgo, który już nie był potrzebny.

Wpływ na CI: w głównej aplikacji czas wykonywania kroku sprawdzania typów spadł z 3,8 sekundy do 0,4 sekundy; w drzewie workerów spadł z 11,4 sekundy do 1,3 sekundy. Pozostałe ponad osiem minut procesu pozostało bez zmian.

Koszt plotek: jeden pull request obwiniał wersję 7 za regresję, która w rzeczywistości była spowodowana zmianą flagi zawartej w tym samym commitie. Trzymaj te commity oddzielnie.

Doświadczenie użytkownika: przyjemna poprawa, ale nie taka, która zasługuje na kwantyfikację liczbą w komentarzach.

Nazewnictwo: tsc od teraz oznacza wersję 7, a tsc6 służy jako alternatywa. Jeśli oba pliki binarne znajdują się na twoim PATH, opisz to jasno w README, aby nikt później nie miał problemów.

Czy powinieneś zaktualizować na wersję 7, czy pozostać przy 6?

Pереjdź na wersję 7. Zachowanie sprawdzania typów jest takie samo, tylko działanie jest szybsze — nie ma żadnej nowej składni do opanowania.

Zostań przy wersji 6 tylko wtedy, gdy istnieje konkretny plugin, którego nazwę możesz podać, a który jeszcze nie dodał obsługi wersji 7. Wpisz bezpośrednio nazwę tego pluginu do swojego wskaźnika wersji. „Czekanie na ustabilizowanie się sytuacji” samo w sobie nie jest ważnym powodem.

Nie łącz aktualizacji na wersję 7 z zmianą typu erasableSyntaxOnly w tym samym pull request – jeśli coś się zepsuje, nie będziesz mógł stwierdzić, która zmiana to spowodowała.

Również nie usuwaj polecenia tsc --noEmit ze swojego procesu CI tylko dlatego, że wersja 7 sprawia, iż jest ono szybsze. Szybkość to powód do zachowania tego mechanizmu, a nie do jego usunięcia.

Szczerze mówiąc, ograniczenia tego porównania

Spadek z 3,82 s do 0,41 s dotyczy tego konkretnego aplikacji z czterema ścieżkami. Spadek z 11,4 s do 1,3 s pochodzi z odrębnej bazy kodu skupionej na workerach. Poprawa 8 do 12 razy, o której mówi Microsoft, odnosi się do pełnych budów w repozytoriach takich jak VS Code. Nikt tutaj nie uruchamiał ponownie VS Code.

Wyrażenie „strukturalnie identyczne”, datowane na 8 lipca 2026 roku, pochodzi bezpośrednio z oficjalnego oświadczenia Microsoftu. Jeśli błędy zgłaszane przez twój projekt rzeczywiście się zmieniają po aktualizacji, traktuj to jako wadę do zgłoszenia, a nie jak jakiś dziwny skutek uboczny, który można zignorować.

Nie ma możliwości sprawdzenia tu przenoszenia zależności. Jeśli pnpm exec tsc -v pokazuje lokalnie jedną główną wersję, podczas gdy logi CI wykazują inną, to tak naprawdę jeszcze nie zweryfikowałeś TypeScript 7 – masz tu problem z rozwiązywaniem PATH, który przybiera postać porównania wersji.

Zrób trzy rundy z każdym z programów tsc6 i tsc. Zapisz czas wykonania testu oraz liczbę plików po każdej rundzie. Te cztery liczby stanowią surowy zestaw danych, który warto udostępnić, jeśli chcesz otrzymać informacje zwrotne dotyczące Twojej konfiguracji.

Minimalna konfiguracja do testowania w folderze scratch

Jeśli wolisz na razie nie zmieniać swojego rzeczywistego aplikacji, oto najmniejsza możliwa para instalacji, która nadal ilustruje problem z przenoszeniem zmiennych.

mkdir ts7-lab && cd ts7-lab
pnpm init
pnpm add -D typescript@7 @typescript/typescript6
echo '{ "compilerOptions": { "strict": true, "noEmit": true } }' > tsconfig.json
echo 'export type InvoiceId = string; export const n: InvoiceId = "inv_1";' > index.ts
pnpm exec tsc -v
pnpm exec tsc6 -v
pnpm exec tsc --extendedDiagnostics
pnpm exec tsc6 --extendedDiagnostics

Zapisz numery wersji oraz czasy wykonania testu dla obu wariantów. Następnie dodaj pakiet do środowiska pracy, który nadal używa typescript@6 jako zależności, i sprawdź, co pokaże komenda pnpm exec tsc -v w korzeniu repozytorium. To niezgodność jest dokładnie tym rodzajem niespodzianki, jaką może przynieść CI.

W projekcie faktur warto również odnotować, czy next build rzeczywiście wyświetlał wiersz Finished TypeScript pochodzący z wersji 7. Jeśli ten wiersz nigdy się nie pojawia, oznacza to, że Next.js używa innego narzędzia do sprawdzania typów niż to, które wywołuje skrypt typecheck. Należy je dostosować – działanie dwóch różnych narzędzi równocześnie było właśnie przyczyną tego, że błąd branded-id przeszedł niezauważony podczas weryfikacji.

Jednominutowa kontrola dla recenzentów: otwórz plik app/invoices/page.tsx, przesuń kursor nad typem searchParams i poczekaj na pokazanie informacji pomocniczej. Powtórz to zarówno w wersji 6, jak i w wersji 7. W tej kontroli nie potrzeba zegarka – chodzi po prostu o to, by tekst pokazujący się przy przesunięciu kursora nie zmienił się pomiędzy wersjami. To samo zachowanie, ale szybszy silnik w tle.

Jeśli twój projekt posiada oddzielny plik tsconfig.eslint.json z łagodniejszymi ustawieniami, pozbyj się go w tym samym tygodniu, gdy dokonujesz aktualizacji. Tani sprawdzacz typów eliminuje wymówkę, by narzędzie lint sprawdzało pliki według innych zasad niż proces budowania.

Jedna wartość, którą warto zarejestrować od pierwszego dnia: uruchom polecenie tsc --noEmit --pretty false 2>&1 i przepuść jego wynik przez wc -l, przed i po aktualizacji. Liczba błędów musi być dokładnie taka sama. W aplikacji do faktur była to zero i zero. W projekcie worker-tree również zero i zero – te same pliki, te same komunikaty obie razy. Ta zgodność stanowi właściwie całą historię migracji. Jeśli liczby się nie pokrywają, przestań powtarzać hasło o 10-krotnym wzroście wydajności i zacznij bezpośrednio porównywać oba pliki wyjściowe.

Zachowaj oba pliki dziennika w formie /tmp/tsc6.txt oraz /tmp/tsc7.txt przez około tydzień po każdej aktualizacji. Usuń je, gdy sytuacja się ustabilizuje – ale nie w noc faktycznej publikacji aktualizacji.

Wskazówki dla osoby, która przejmie ten kod w przyszłości

W szablonie prośby o pull request należy wymagać wyjścia z polecenia pnpm exec tsc -v. Jeśli nie pojawi się tam liczba 7, oznacza to, że poprawa wydajności tak naprawdę nie została wdrożona.

Nie łącz tej aktualizacji z ustawieniami erasableSyntaxOnly, verbatimModuleSyntax ani szerszą czyszczenią konfiguracji tsconfig w ramach tej samej zmiany. Te elementy należą do późniejszych kroków. Ta aktualizacja dotyczy wyłącznie szybszego kompilatora wykonującego tę samą pracę.

Kontynuuj uruchamianie polecenia tsc --noEmit w środowisku CI, mimo że teraz nie kosztuje to prawie nic. Właśnie ta niska cena jest argumentem za jego zachowaniem.

Sesja laboratoryjna, nagrana na żywo: polecenia i wyniki

Część ta opisuje ten sam laboratorium do tworzenia faktur z czterema trasami, używany we wszystkich częściach tej serii. Wersje ustalone przed rozpoczęciem to: Node 24, TypeScript 7, Next 16.3.

Kroki te znajdują się w pliku notes/lab.md repozytorium, aby przyszłe sesje nie polegały na pamięci. Możesz je skopiować po kolei.

node -v
pnpm exec tsc -v
pnpm exec next --version

Zapisz wszystkie trzy numery wersji na górze swoich notatek. Jeśli jakaś główna wersja nie odpowiada temu, co uważasz za aktualnie uruchomioną wersję, zatrzymaj się – wszystko, co nastąpi później, przyniesie mylące wyniki w bardziej subtelny sposób.

Następnie przystępujemy do analizy tras:

pnpm exec next dev

Odwiedź /, /invoices, /invoices/1, /settings, a następnie ponownie /invoices. Włącz opcję „Preserve log” w DevTools. Zrób zrzut ekranu zarówno pola filtrów, jak i paska adresu. Okazuje się, że ta kombinacja dostarcza najbardziej przydatnych informacji podczas większej liczby tych sprawdzeń, niż się spodziewano.

Następnie uruchom sprawdzacz typów:

pnpm exec tsc --noEmit --pretty false
echo $?

Kod wyjścia równy zero nie jest ostatecznym wynikiem — to jedynie zielone światło do sprawdzenia zachowania w czasie wykonywania programu.

Wreszcie to, o czym naprawdę chodzi w tym tekście: należy wykonać polecenia już wymienione pod hasłem „Jak to zobaczyć na swoim komputerze”. Nie pomijaj ich tylko dlatego, że już widziałeś tu liczby — to nie twój komputer jest źródłem tych wartości. Ciepło otoczenia, laptop o pojemności 16 GB oraz to, co Chrome robi w tle, wpłyną na wartości RSS, czas sprawdzania oraz czas przerwania pobierania znacznie bardziej niż jakakolwiek niewielka aktualizacja frameworka.

Kolejny nawyk, który warto zachować: jedna linijka z informacją o nieudanej próbie naprawy w notatce — jedno zdanie, na przykład „Próbowałem X, nadal widzę Y”. To właśnie ta linijka sprawia, że dokument pozostaje aktywnym zapisem, a nie dopracowaną prezentacją. Przydatnym uzupełnieniem jest lista wersji, dokładne polecenie, wynik jego wykonania oraz informacja o nieudanej próbie naprawy. Zdjęcie ekranu z panelu sterowania nie spełnia tej funkcji.

Literatura pokrewna

• Kompilator TypeScript oparty na Go i wykonywanie natywne: Przewodnik po migracji — Dowiedz się, jak kompilator TypeScript oparty na Go oraz wykonywanie natywne w Node.js wpłyną na projekty React i Next.js oraz co należy natychmiast poprawić w pliku tsconfig.
• Wnętrze przepisania TypeScript 7 na Go: Zyski w szybkości bez zmian w kodzie — Dowiedz się, jak kompilator TypeScript 7 oparty na Go zapewnia 8–12 razy szybsze budowanie projektów, dlaczego ta zmiana architektury jest skuteczna oraz jak bezpiecznie zaktualizować istniejące projekty.