Jak przyspieszyć monorepo z pnpm i Turborepo na Windows 11

Dlaczego monorepo z pnpm i Turborepo wolno się buduje na Windows 11 i jak to naprawić

Czy Twoje monorepo z pnpm i Turborepo wolno się buduje na Windows 11, marnując cenne minuty, a nawet godziny pracy? Jeżeli tak, nie jesteś sam. Wielu deweloperów JavaScript/TypeScript na Windowsie zmaga się z podobnymi problemami, szczególnie w projektach monorepo.

Budowanie projektów, zarządzanie zależnościami i uruchamianie skryptów w takim środowisku generuje ogromną liczbę operacji na plikach. To sprawia, że różnice między Windows 11 a systemami Linux stają się wyjątkowo widoczne. Na szczęście istnieją konkretne, techniczne przyczyny tych kłopotów i – co ważniejsze – sprawdzone sposoby, które pozwalają je rozwiązać.

W tym artykule przejdziemy przez naturę problemu, omówimy, dlaczego monorepo z pnpm i Turborepo potrafi działać kapryśnie na Windows 11, a następnie pokażemy krok po kroku praktyczne rozwiązania. Dzięki temu możesz znacząco przyspieszyć swoje buildy i odzyskać produktywność, koncentrując się na tym, co najważniejsze – pisaniu dobrego kodu.

Monorepo, pnpm i Turborepo – krótkie wprowadzenie

Zanim przejdziemy do diagnozy i naprawy problemów z wydajnością, warto uporządkować podstawowe pojęcia. Jeśli dobrze znasz monorepo, pnpm i Turborepo, możesz tę sekcję potraktować jako krótką powtórkę.

Monorepo, pnpm i Turborepo tworzą razem potężny ekosystem do pracy nad dużymi projektami, ale jednocześnie stawiają wysokie wymagania systemowi plików. Rozumiejąc, jak każde z tych narzędzi działa „pod maską”, łatwiej zrozumiesz, dlaczego na Windows 11 wszystko może działać wolniej niż się spodziewasz.

Czym jest monorepo?

Monorepo to podejście, w którym wiele projektów trzymasz w jednym repozytorium kodu. Zamiast rozdzielać frontend, backend, biblioteki współdzielone i komponenty UI na oddzielne repozytoria, całość żyje w jednym drzewie katalogów.

Taka architektura daje liczne korzyści:

• Łatwiejsze zarządzanie zależnościami między projektami w ramach jednego repozytorium.
• Spójne wersjonowanie i prostsze wdrażanie zmian między wieloma pakietami.
• Uproszczona refaktoryzacja kodu krzyżującego się między modułami.
• Lepsza widoczność zmian w całym systemie, co sprzyja pracy zespołowej.

Wraz ze wzrostem rozmiaru monorepo pojawiają się jednak wyzwania wydajnościowe. Szczególnie dotkliwie widać je przy buildach, testach i instalacjach zależności, które w dużych projektach potrafią trwać zdecydowanie zbyt długo.

Dlaczego pnpm?

pnpm to menedżer pakietów JavaScript, który zdobył popularność dzięki swojej wydajności i nowatorskiemu modelowi przechowywania zależności. W odróżnieniu od npm czy Yarn:

• pnpm trzyma pakiety w globalnym magazynie (content-addressable store),
• zamiast kopiować pliki do każdego projektu, tworzy hardlinki i symlinki,
• każda wersja pakietu jest instalowana tylko raz na dysku.

Gdy w projekcie potrzebny jest pakiet, pnpm tworzy dowiązanie do wspólnej instancji. Dzięki temu:

• instalacje są zwykle znacznie szybsze,
• projekty zajmują mniej miejsca na dysku,
• w monorepo wiele pakietów może efektywnie współdzielić zależności.

To podejście idealnie pasuje do monorepo, ale jednocześnie generuje ogromną liczbę operacji I/O i odwołań do systemu plików – a to właśnie tutaj Windows 11 potrafi spowalniać pracę.

Czym jest Turborepo?

Turborepo to system budowania zaprojektowany dla monorepo i nastawiony na maksymalną wydajność. Jego kluczowe mechanizmy to:

• Analiza grafu zależności między pakietami i zadaniami,
• Uruchamianie tylko tych zadań, które są rzeczywiście potrzebne,
• Buforowanie wyników komend (build, test, lint itd.) lokalnie i zdalnie,
• Równoległe wykonywanie zadań wszędzie tam, gdzie to możliwe.

Przy poprawnej konfiguracji Turborepo potrafi ominąć ogromną część pracy: zamiast budować wszystko od nowa, odczytuje gotowe wyniki z cache, gdy pliki wejściowe nie uległy zmianie. W dużych monorepo oznacza to często różnicę między minutami a sekundami.

Dlaczego monorepo z pnpm i Turborepo jest wolne na Windows 11?

Skoro pnpm i Turborepo są „domyślnie szybkie”, dlaczego na Windows 11 tak często okazują się powolne? Źródłem problemu jest połączenie kilku czynników: systemu plików NTFS, działania antywirusa, ograniczeń długości ścieżek, konfiguracji narzędzi oraz używanych wersji.

Na wydajność wpływa nie tylko kod, ale też warstwa systemowa. W monorepo różnica między Windows a Linuxem staje się szczególnie wyraźna, bo narzędzia takie jak pnpm i Turborepo są mocno I/O-intensywne.

1. Wydajność systemu plików NTFS

Najczęstszym winowajcą jest system plików NTFS, domyślnie używany przez Windows 11. W porównaniu z ext4 (popularnym w Linuxie) ma on inne charakterystyki wydajnościowe, szczególnie przy:

• dużej liczbie małych plików,
• intensywnym korzystaniu z dowiązań symbolicznych i junction points,
• częstym tworzeniu i usuwaniu plików oraz katalogów.

pnpm, przez swój globalny magazyn i linkowanie, generuje tysiące operacji na plikach przy każdej instalacji. Turborepo z kolei wykonuje:

• skanowanie plików wejściowych,
• obliczanie sum kontrolnych,
• obsługę bufora wyników dla wielu zadań.

Na NTFS takie wzorce dostępu do plików są zwykle wolniejsze niż na ext4. Przy rozbudowanym monorepo, tysiącach plików i wielu linkach symbolicznych różnice te kumulują się, prowadząc do znacznego spadku szybkości.

2. Antywirus i Windows Defender

Drugi kluczowy czynnik to oprogramowanie antywirusowe, w tym domyślny Windows Defender. Każdy nowo utworzony lub zmodyfikowany plik może być:

• natychmiast skanowany pod kątem zagrożeń,
• monitorowany pod względem zmian i zachowania,
• dodatkowo „śledzony”, jeśli katalog jest na liście szczególnie chronionych.

Instalacja zależności pnpm, generowanie node_modules, tworzenie cache przez Turborepo – wszystko to produkuje tysiące plików w krótkim czasie. Jeżeli antywirus skanuje każdą z tych operacji, buildy zaczynają przypominać bieg z ciężkim plecakiem kontrolowanym na każdym kroku.

Bez odpowiedniej konfiguracji wyjątków antywirus potrafi:

• znacząco opóźnić operacje I/O,
• spowodować losowe „przycięcia” w trakcie buildów,
• wyraźnie pogorszyć ogólne wrażenia z pracy w monorepo.

3. Ograniczenia długości ścieżek (Max Path Length)

Windows od lat ma historyczne ograniczenie długości ścieżek do 260 znaków. Wprawdzie w nowszych wersjach Windows 10 i 11 można to ograniczenie zdjąć, ale:

• nie wszystkie aplikacje i biblioteki radzą sobie z tym poprawnie,
• część narzędzi wciąż zakłada istnienie limitu,
• długie ścieżki w monorepo mogą generować trudne do zdiagnozowania błędy.

W złożonej strukturze katalogów monorepo, z długimi nazwami pakietów i folderów, przekroczenie limitu jest bardzo realne. To może skutkować:

• nieoczywistymi problemami z dostępem do plików,
• nieudanymi instalacjami,
• a w najlepszym wypadku – dodatkowymi opóźnieniami, gdy system próbuje radzić sobie z takimi ścieżkami.

4. Niezoptymalizowana konfiguracja pnpm i Turborepo

Domyślne ustawienia pnpm i Turborepo są ogólnie sensowne, ale nie zawsze idealne dla danego środowiska. Typowe problemy to:

• Globalny magazyn pnpm trzymany na wolnym dysku (np. HDD lub partycja sieciowa),
• Niewłaściwie skonfigurowane buforowanie i inputs/outputs w turbo.json,
• Zbyt ogólnie zdefiniowane pliki wejściowe, przez co Turborepo zbyt często pomija cache i kompiluje wszystko od nowa.

Jeśli konfiguracja jest nieoptymalna, możesz nie wykorzystywać pełnego potencjału:

• pnpm może odwoływać się do wolnych zasobów,
• Turborepo może niepotrzebnie budować projekty od zera,
• a cały pipeline buildów może być znacznie wolniejszy niż powinien.

5. Starsze wersje Node.js, pnpm i Turborepo

Narzędzia takie jak Node.js, pnpm i Turborepo są aktywnie rozwijane. Nowe wersje regularnie przynoszą:

• poprawki błędów,
• optymalizacje wydajności,
• lepsze wsparcie dla nowych funkcji systemu i runtime.

Praca na przestarzałych wersjach może oznaczać:

• brak dostępu do istniejących już optymalizacji,
• większą podatność na znane problemy wydajnościowe,
• gorszą współpracę z nowszymi funkcjami Windows 11.

Zanim zaczniesz szukać egzotycznych rozwiązań, warto upewnić się, że używasz aktualnych wydań kluczowych narzędzi.

Krok po kroku: jak przyspieszyć monorepo na Windows 11

Skoro wiesz już, skąd biorą się spowolnienia, czas przejść do praktyki. Poniżej znajdziesz konkretne kroki, które pomogą przyspieszyć monorepo z pnpm i Turborepo na Windows 11. Nie wszystkie są obowiązkowe, ale im więcej z nich zastosujesz, tym większa szansa na odczuwalną poprawę.

Najważniejszą zmianą, która często rozwiązuje 80–90% problemów, jest migracja do WSL 2. Pozostałe kroki pomagają, gdy z różnych względów chcesz lub musisz zostać na „czystym” Windowsie.

Krok 1: Przenieś środowisko deweloperskie do WSL 2

Najbardziej rekomendowanym i najskuteczniejszym rozwiązaniem jest Windows Subsystem for Linux w wersji 2 (WSL 2). Oferuje on pełnoprawne jądro Linuksa działające jako lekka maszyna wirtualna, co pozwala na:

• użycie systemu plików ext4,
• natywne korzystanie z narzędzi linuksowych,
• wyeliminowanie znacznej części ograniczeń NTFS.

Dzięki temu pnpm i Turborepo działają praktycznie tak, jak na natywnym Linuksie, a problemy z wydajnością monorepo na Windows 11 dramatycznie się zmniejszają.

1. Instalacja WSL 2

1. Otwórz PowerShell lub Wiersz polecenia jako administrator.
2. Wpisz komendę:
   bash wsl --install
3. System zainstaluje domyślną dystrybucję Linuksa (zwykle Ubuntu) i może poprosić o restart.
4. Po restarcie uruchom terminal WSL, ustaw nazwę użytkownika i hasło.
5. Upewnij się, że domyślną wersją jest WSL 2:
   bash wsl --set-default-version 2
6. Jeśli masz już istniejącą dystrybucję w WSL 1, przekonwertuj ją:
   bash wsl --set-version <nazwa_dystrybucji> 2

2. Konfiguracja środowiska w WSL

1. Instalacja Node.js z nvm:
   bash curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash source ~/.bashrc nvm install --lts nvm use --lts

2. Instalacja pnpm:
   bash npm install -g pnpm

3. Sklonowanie monorepo w WSL:
   bash cd ~ mkdir projects && cd projects git clone <adres_repozytorium>

4. Praca w VS Code z WSL:

5. Zainstaluj rozszerzenie „Remote - WSL” w VS Code.
6. W terminalu WSL, w katalogu monorepo, wpisz:
   bash code .
7. VS Code otworzy projekt i wszystkie terminale będą działać natywnie w środowisku Linuksa.

3. Dodatkowe optymalizacje WSL (opcjonalne)

Możesz dostosować zasoby dostępne dla WSL 2, tworząc plik .wslconfig w katalogu domowym użytkownika w Windows (C:\Users\<TwojaNazwaUżytkownika>\):

[wsl2]
memory=8GB
processors=4
swap=0

Taka konfiguracja pozwala przydzielić więcej pamięci i rdzeni CPU, co pozytywnie wpływa na buildy pnpm i Turborepo w dużych monorepo.

Krok 2: Ustaw wyjątki w antywirusie (praca bezpośrednio na Windows)

Jeżeli z jakiegoś powodu nie możesz przejść na WSL 2 lub chcesz nadal budować bezpośrednio na Windows, kolejnym krytycznym krokiem jest konfiguracja wykluczeń w antywirusie.

Bez tych wyjątków każdy build może być spowalniany przez ciągłe skanowanie nowych plików.

Jak dodać wykluczenia w Windows Defender

1. Otwórz Ustawienia Windows → „Prywatność i zabezpieczenia” → „Zabezpieczenia Windows”.
2. Wejdź w „Ochrona przed wirusami i zagrożeniami”.
3. W sekcji „Ustawienia ochrony przed wirusami i zagrożeniami” kliknij „Zarządzaj ustawieniami”.
4. Przewiń do „Wykluczenia” i wybierz „Dodaj lub usuń wykluczenia”.

5. Dodaj wykluczenia dla:

6. Katalogów:

   • folder monorepo (np. C:\Users\TwojaNazwa\Documents\MojeMonorepo),
   • globalny magazyn pnpm, np.
     C:\Users\TwojaNazwa\AppData\Local\pnpm\store\v3,
   • foldery node_modules w projekcie,
   • katalog %TEMP%, jeśli intensywnie używany.

7. Typów plików (opcjonalnie, z rozwagą):

   • .js, .ts, .json, .mjs, .cjs, .lock, .bin.

8. Procesów (jeśli antywirus to umożliwia):

   • node.exe, pnpm.exe, turborepo.exe lub pełne ścieżki do binariów.

Po większych aktualizacjach systemu lub antywirusa sprawdzaj, czy wykluczenia nadal obowiązują. Ich utrata może sprawić, że monorepo z pnpm i Turborepo znów zacznie budować się zauważalnie wolniej.

Krok 3: Włącz obsługę długich ścieżek w Windows 11

Kolejny krok to włączenie długich ścieżek Win32, co zmniejsza prawdopodobieństwo problemów związanych z limitami długości.

Konfiguracja przez Edytor zasad grupy

1. Naciśnij Win + R, wpisz gpedit.msc i naciśnij Enter.
2. Przejdź do:
   Konfiguracja komputera → Szablony administracyjne → System → System plików → NTFS.
3. Znajdź ustawienie „Włącz długie ścieżki Win32” (Enable Win32 long paths).
4. Otwórz je, ustaw na „Włączone” (Enabled) i zapisz.

Konfiguracja przez Rejestr

1. Naciśnij Win + R, wpisz regedit i naciśnij Enter.
2. Przejdź do:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.
3. Znajdź wartość LongPathsEnabled lub utwórz nową wartość DWORD (32-bit).
4. Ustaw jej wartość na 1.
5. Uruchom ponownie komputer, aby zmiany zaczęły działać.

Dzięki temu zminimalizujesz ryzyko błędów i dziwnych zachowań przy pracy z bardzo głębokimi strukturami katalogów w monorepo.

Krok 4: Zaktualizuj Node.js, pnpm i Turborepo

Aktualizacja narzędzi to prosty krok, który często przynosi realny zysk wydajnościowy. Nowe wersje zawierają:

• usprawnienia w zarządzaniu pamięcią,
• optymalizacje operacji na plikach,
• poprawki w obsłudze nowych funkcji systemu.

Aktualizacja Node.js

Jeśli używasz nvm-windows (Windows) lub nvm (WSL):

# Windows z nvm-windows
nvm install latest
nvm use latest

# WSL z nvm
nvm install --lts
nvm use --lts

Jeśli Node.js instalowałeś ręcznie, pobierz najnowszą wersję LTS z oficjalnej strony i zainstaluj.

Aktualizacja pnpm

Zaktualizuj pnpm do najnowszej stabilnej wersji:

npm install -g pnpm
pnpm setup

Możesz też użyć:

pnpm add -g pnpm

Aktualizacja Turborepo

W katalogu monorepo, w package.json, upewnij się, że w devDependencies jest aktualna wersja Turborepo. Następnie:

pnpm update turbo

Dostosowanie wersji do najnowszej stabilnej często oznacza mniejsze czasy buildów i lepszą współpracę z nowszym Node.js i pnpm.

Jak zoptymalizować pnpm i Turborepo na Windows 11

Sama instalacja WSL i aktualizacja narzędzi to dopiero część pracy. Kolejnym etapem jest dostrojenie pnpm i Turborepo, tak aby lepiej wykorzystywały możliwości Twojego środowiska sprzętowego i systemowego.

Dzięki odpowiedniej konfiguracji możesz skrócić czas buildów, ograniczyć niepotrzebne przebudowy i zmniejszyć liczbę operacji I/O na dysku.

Krok 5: Zoptymalizuj konfigurację pnpm

Kilka prostych zmian w konfiguracji pnpm potrafi poprawić wydajność szczególnie na Windows.

1. Przenieś globalny magazyn pnpm na szybszy dysk

Jeżeli nie korzystasz z WSL i masz więcej niż jeden dysk (np. szybki SSD i wolniejszy HDD), przenieś globalny store pnpm na najszybszy dostępny nośnik.

• Utwórz katalog na szybkim dysku, np. D:\pnpm\store.
• Ustaw zmienną środowiskową PNPM_HOME (lub odpowiedni klucz konfiguracyjny pnpm) na tę ścieżkę.
• Dodaj tę ścieżkę do zmiennej Path, jeśli to konieczne.
• Po zmianie uruchom pnpm install w projekcie, aby pnpm przebudował potrzebne linki.

Dzięki temu większość odwołań pnpm do magazynu pakietów będzie trafiać na szybszy nośnik, co przyspieszy instalacje i aktualizacje.

2. Okresowo czyść globalny store

W miarę pracy nad wieloma projektami pnpm gromadzi w store stare, nieużywane pakiety. Warto go od czasu do czasu „odchudzić”:

pnpm store prune

To nie tylko zwalnia miejsce, ale też może przyspieszyć pewne operacje pnpm, gdy nie musi przeszukiwać tak dużej liczby wersji.

3. Skonfiguruj .npmrc

W katalogu głównym monorepo (lub w katalogu domowym użytkownika) utwórz .npmrc z kluczowymi ustawieniami:

hoist=false
shamefully-hoist=false

Te wartości są zgodne z filozofią pnpm i zapewniają:

• bardziej deterministyczne rozwiązywanie zależności,
• mniejszą liczbę potencjalnych konfliktów,
• przewidywalną strukturę node_modules.

Choć w pojedynczych przypadkach możesz potrzebować innych ustawień, warto mieć świadomość, że zmiana ich może wpływać zarówno na stabilność, jak i na wydajność.

Krok 6: Zoptymalizuj konfigurację Turborepo

Turborepo jest bardzo wydajne, ale tylko wtedy, gdy jego konfiguracja dobrze odwzorowuje strukturę Twojego monorepo i precyzyjnie opisuje, co powinno być cache’owane.

1. Doprecyzuj turbo.json

W pliku turbo.json skup się szczególnie na sekcjach pipeline i globalDependencies.

Przykładowa konfiguracja:

{
  "$schema": "https://turborepo.org/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**", "public/**"],
      "inputs": ["src/**", "package.json"]
    },
    "test": {
      "outputs": [],
      "inputs": ["src/**", "package.json", "jest.config.js"]
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false
    }
  },
  "globalDependencies": ["tsconfig.json", "tailwind.config.js"]
}

Zwróć uwagę na:

• inputs – jeśli są zbyt ogólne (np. obejmują cały repozytorium), Turborepo będzie zbyt często ignorowało cache, bo zawsze „coś” się zmienia.
• outputs – muszą obejmować wszystkie katalogi i pliki generowane przez build, aby cache był kompletny.
• globalDependencies – tu umieszczaj pliki wspólne, których zmiana rzeczywiście powinna powodować przebudowę wielu pakietów (np. tsconfig.json).

Właściwe dobranie inputs i outputs jest kluczowe, by uniknąć sytuacji, w której monorepo z pnpm i Turborepo mimo wszystko ciągle buduje się od zera.

2. Rozważ zdalne cache’owanie

Jeśli pracujesz w zespole, warto włączyć zdalny cache Turborepo (np. przez usługę chmurową lub własny serwer). Dzięki temu:

• build wykonany przez jednego członka zespołu może być ponownie użyty przez innych,
• osoby na wolniejszym sprzęcie lub Windows mogą korzystać z cache wygenerowanego np. na szybszym Linuxie,
• czas całkowity buildów w zespole znacząco się skraca.

To nie usuwa problemów Windows 11 z systemem plików, ale pozwala je częściowo ominąć, gdy duża część pracy została już wykonana gdzieś indziej.

Sprzęt, dysk, RAM i monitorowanie – ostatnie elementy układanki

Oprócz konfiguracji narzędzi ważne są też kwestie sprzętowe i monitoring. Nawet najlepiej skonfigurowane pnpm i Turborepo będą się męczyć na powolnym dysku i przy zbyt małej ilości pamięci.

Krok 7: Zadbaj o wydajny dysk i pamięć

Aby monorepo z pnpm i Turborepo działało szybko na Windows 11, zwróć uwagę na:

• SSD zamiast HDD – jeśli nadal korzystasz z dysku talerzowego, przejście na SSD (a najlepiej NVMe) daje ogromny wzrost wydajności operacji I/O.
• Dużo RAM – rekomendowane minimum to 16 GB, a przy większych projektach i wielu równoległych procesach build/test wygodniej jest mieć 32 GB.
• Brak synchronizacji z chmurą – nie trzymaj monorepo w folderach synchronizowanych przez OneDrive, Google Drive czy Dropbox. Synchronizacja plików w tle może bardzo spowalniać operacje na plikach.

Wykluczenie projektów z katalogów chmurowych często przynosi wyraźną poprawę, bo usuwa dodatkową warstwę I/O nad systemem plików.

Krok 8: Monitoruj i profiluj proces builda

Jeśli po zastosowaniu poprzednich kroków monorepo nadal wolno się buduje, warto przeprowadzić profilowanie procesu.

Analiza Turborepo z perf-viewer

Turborepo potrafi generować szczegółowy raport wydajnościowy. Możesz go przeanalizować narzędziem perf-viewer:

pnpm install -g @turborepo/perf-viewer
turbo build --graph=out.json && perf-viewer out.json

Dzięki temu zobaczysz:

• które zadania trwają najdłużej,
• jakie zależności powodują najczęstsze przebudowy,
• gdzie potencjalnie możesz poprawić konfigurację lub rozbić zadania na mniejsze kroki.

Narzędzia systemowe Windows

Użyj Menedżera zadań i Monitora zasobów, aby sprawdzić:

• zużycie CPU, RAM, dysku i sieci podczas buildów,
• czy nie ma procesów spoza ekosystemu pnpm/Turborepo, które obciążają system,
• jak bardzo dysk jest wysycony podczas instalacji zależności i kompilacji.

Takie obserwacje pomagają zidentyfikować wąskie gardła i czasem wskazują na niespodziewane problemy, jak np. inne aplikacje zbyt agresywnie korzystające z dysku.

Podsumowanie – jak skutecznie przyspieszyć monorepo na Windows 11

Monorepo z pnpm i Turborepo na Windows 11 może działać bardzo wolno, ale nie wynika to wyłącznie z samych narzędzi. Główną rolę gra tutaj:

• charakterystyka systemu plików NTFS,
• działanie antywirusów (zwłaszcza Windows Defendera),
• historyczne ograniczenia długości ścieżek,
• nieoptymalna konfiguracja pnpm i Turborepo,
• oraz używanie przestarzałych wersji narzędzi.

Najbardziej skutecznym i długoterminowym rozwiązaniem jest przeniesienie środowiska do WSL 2, co pozwala wykorzystać wydajność ext4 i narzędzi linuksowych bez rezygnowania z Windows jako głównego systemu.

Jeśli jednak musisz pozostać na natywnym Windowsie, kluczowe jest:

• ustawienie wykluczeń w antywirusie,
• włączenie długich ścieżek,
• aktualizacja Node.js, pnpm i Turborepo,
• przeniesienie globalnego store pnpm na szybki dysk,
• poprawna konfiguracja turbo.json,
• dbałość o sprzęt (SSD, RAM) i unikanie folderów synchronizowanych z chmurą.

Zastosowanie tych kroków pozwoli Ci znacząco skrócić czas buildów, ograniczyć frustrację i odzyskać kontrolę nad procesem deweloperskim. Im szybciej zoptymalizujesz swoje środowisko, tym więcej energii będziesz mógł poświęcić na to, co naprawdę ważne: tworzenie świetnego kodu w Twoim monorepo.