Aktualizacja kluczowych bibliotek w ekosystemie Node.js to zazwyczaj powód do radości. Lepsza wydajność, mniejszy rozmiar paczki, nowe funkcje. Jednak w przypadku przejścia z Prisma 5 na Prisma 6, użytkownicy systemu Windows mogą poczuć się, jakby ktoś zaciągnął hamulec ręczny. Choć "szóstka" obiecuje cuda w środowiskach Serverless i Edge, lokalny development na maszynach z Redmond stał się drogą przez mękę. Co dokładnie poszło nie tak?
Zmiana architektury: Library Engine vs. Binary Engine
Największą zmianą, która uderza w użytkowników Windowsa, jest domyślne i agresywne przejście na architekturę opartą na bibliotekach (Node-API library), zamiast oddzielnego procesu binarnego, który był standardem w starszych wersjach (i łatwiej konfigurowalnym w v5). W teorii, podpięcie silnika zapytań bezpośrednio do procesu Node.js redukuje narzut komunikacji HTTP/IPC. W praktyce, na Windowsie, tworzy to śmiertelną pułapkę.
Windows zarządza pamięcią i procesami inaczej niż systemy POSIX (Linux/macOS). Gdy Prisma 6 ładuje swój silnik Rustowy bezpośrednio do pamięci procesu Node, system operacyjny Windows staje się nadwrażliwy na jakiekolwiek operacje na plikach wykonywane przez ten proces. W efekcie, proste przeładowanie aplikacji (Hot Module Replacement) często kończy się zawieszeniem procesu, ponieważ Windows nie pozwala zwolnić uchwytów do plików DLL/node wystarczająco szybko.
Klątwa systemu plików NTFS i błędy EBUSY
Jeśli pracujesz na Windowsie, na pewno znasz błąd EBUSY: resource busy or locked. W Prisma 5 zdarzał się on sporadycznie. W Prisma 6 stał się codziennością dla wielu deweloperów niekorzystających z WSL2.
Nowy mechanizm generowania klienta (Prisma Client) w wersji 6 jest znacznie bardziej zintegrowany z cyklem życia aplikacji. Na systemach Linux, gdzie plik można usunąć lub nadpisać nawet gdy jest otwarty przez inny proces, nie stanowi to problemu. NTFS na to nie pozwala. Prisma 6, próbując dynamicznie optymalizować schemat i typy w locie, często napotyka na blokadę nałożoną przez sam proces edytora kodu (VS Code) lub działający serwer deweloperski. Wynik? Konieczność ręcznego zabijania procesów Node w menedżerze zadań, aby wykonać prisma generate.
Obsługa OpenSSL i natywne zależności
Prisma od zawsze miała burzliwą relację z bibliotekami systemowymi na Windows. Wersja 5 osiągnęła w tym zakresie pewną stabilność, dostarczając prekompilowane binaria, które radziły sobie z różnymi wersjami bibliotek C++. Wersja 6, w pogoni za odchudzeniem paczki, polega w większym stopniu na specyficznych wersjach OpenSSL dostępnych w systemie.
Na Windowsie instalacja OpenSSL w odpowiedniej wersji i dodanie jej do zmiennych środowiskowych to dla wielu deweloperów czarna magia. Prisma 6 jest pod tym względem mniej wyrozumiała. Często zdarza się, że po aktualizacji, silnik po prostu nie startuje, rzucając enigmatyczne błędy o braku kompatybilnych bibliotek TLS, mimo że na wersji 5 wszystko działało bez zarzutu. Wymusza to na programistach ręczną żonglerkę plikami .dll lub instalację dodatkowych narzędzi budowania, co zaprzecza idei "zero-config".
Wydajność 'Cold Start' kosztem 'Hot Path'
Twórcy Prisma 6 skupili się na optymalizacji tzw. zimnego startu (Cold Start), co jest kluczowe dla platform takich jak Vercel czy AWS Lambda. Aby to osiągnąć, zmieniono sposób inicjalizacji połączeń z bazą danych. Na systemach Windows, gdzie nawiązywanie połączeń TCP i rozwiązywanie nazw DNS trwa zazwyczaj nieco dłużej niż na Linuxie, te optymalizacje przyniosły odwrotny skutek.
Mechanizmy timeoutu w Prisma 6 są bardziej restrykcyjne. Lokalna baza danych Postgres czy MySQL uruchomiona w Dockerze na Windowsie (który sam w sobie dodaje narzut sieciowy) często nie zdąży odpowiedzieć w nowym, krótszym oknie czasowym narzuconym przez silnik v6 podczas inicjalizacji. To sprawia, że lokalne środowisko deweloperskie staje się niestabilne, rzucając błędami połączenia, które na produkcji (Linux) nigdy by nie wystąpiły.
WSL2 jako jedyna sensowna ścieżka
Patrząc na kierunek rozwoju Prisma 6, widać wyraźnie, że natywny Windows (PowerShell/CMD) nie jest już priorytetem. Zespół deweloperski optymalizuje narzędzie pod kontenery i chmurę – czyli pod Linuxa. Problemy z blokowaniem plików na NTFS czy zarządzaniem pamięcią w modelu Node-API na Windowsie są traktowane jako ograniczenia platformy, a nie błędy biblioteki.
Dla deweloperów pracujących na maszynach z Windowsem, migracja do Prisma 6 powinna wiązać się z jedną, kluczową decyzją: całkowitym przeniesieniem środowiska deweloperskiego do WSL2 (Windows Subsystem for Linux). Próba walki z Prisma 6 w natywnym środowisku Windows to walka z wiatrakami, gdzie zysk z nowych funkcji jest niwelowany przez frustrację związaną z ciągłym restartowaniem serwera deweloperskiego.