Konfiguracja środowiska Turborepo + Prisma + Nuxt bez problemów z importami na Vercelu

Konfiguracja środowiska Turborepo + Prisma + Nuxt pod moje projekty wyglądała na zadanie, które powinno być proste, ale po drodze trafiłem na kilka problemów — zwłaszcza przy próbie deployu na Vercelu. Oto co próbowałem, co poszło nie tak i jakie rozwiązanie w końcu zadziałało.

Wyzwanie: współdzielony Prisma Client

Zacząłem od szukania sposobu na skonfigurowanie współdzielonego Prisma Clienta w wielu aplikacjach wewnątrz Turborepo. Nie chciałem powielać tej samej konfiguracji Prismy w każdej aplikacji, więc szukałem rozwiązania, w którym mógłbym wyeksportować Prisma Clienta ze wspólnego pakietu i uniknąć duplikacji.

Znalazłem pomocny przykład na GitHubie, który sugerował eksportowanie client/index.js i client/index.d.ts oraz zadbanie o to, żeby zarówno prisma, jak i @prisma/client były zainstalowane w aplikacji, w której współdzielony klient miał być używany. Takie podejście dawało dostęp do PrismaClienta bez problemów z importami, przy zachowaniu poprawnych typów.

Co poszło nie tak

I tu zaczęły się schody:

Powielanie ustawień Prisma Clienta: największym problemem okazało się to, że i tak musiałem powielać te same ustawienia Prisma Clienta w każdym projekcie. Każda aplikacja musiała konfigurować swojego PrismaClienta osobno, mimo że celem była centralizacja klienta. Wydawało się to zbędne i prowadziło do powtarzalnej konfiguracji rozsianej po aplikacjach.
Problemy z deployem na Vercelu: nawet gdy wszystko działało lokalnie, deploy na Vercelu ciągle się wywalał. Szybko zorientowałem się, że Vercel nie obsługuje współdzielonego Prisma Clienta tak, jak się tego spodziewałem. Nawet po zastosowaniu instrukcji i ustawieniu komend builda Vercel nie potrafił poprawnie wygenerować Prisma Clienta po stronie serwera, co kończyło się nieudanym deployem.

Ostateczne rozwiązanie: centralizacja schematu Prismy

Po przetestowaniu różnych podejść znalazłem rozwiązanie, które działa, choć nie jest idealne. Zamiast współdzielonego Prisma Clienta zdecydowałem się scentralizować schemat Prismy w jednej aplikacji. Oznacza to trzymanie schematu Prismy w jednym miejscu i uruchamianie stamtąd komendy generującej Prisma Clienta.

Rozwiązanie sprowadza się do:

Trzymania schematu Prismy w jednej aplikacji.
Generowania Prisma Clienta z centralnej aplikacji przy użyciu poniższej komendy w pozostałych aplikacjach:

prisma generate --schema=../app1/prisma/schema.prisma

To podejście rozwiązało problem bez konieczności duplikowania konfiguracji Prismy we wszystkich projektach i pozbyło się kłopotów z tym, że Vercel nie generował klienta poprawnie. Deploye na Vercelu zaczęły działać bez zarzutu i przestałem się przejmować problemami z importem Prisma Clienta.

Dodatkowo mogłem ponownie wykorzystać klienta Prismy wyeksportowanego z app1, gdzie ustawienia były już zadeklarowane, dzięki czemu cała konfiguracja została w jednym miejscu.

Podsumowanie

Choć nie było to najczystsze rozwiązanie, centralizacja schematu Prismy i generowanie klienta z jednej aplikacji pozwoliły mi w końcu uniknąć problemów z importami i rozwiązać kłopoty z deployem na Vercelu — a w międzyczasie czekamy, aż Prisma naprawi to u siebie, miejmy nadzieję, że w nadchodzącej wersji V7.

Jeśli pracujesz z Turborepo + Prisma + Nuxt i deployujesz na Vercelu, a mierzysz się z problemami przy imporcie Prisma Clienta albo z powielaniem konfiguracji w wielu projektach, polecam scentralizować schemat Prismy i generować klienta z jednej aplikacji. To podejście nie jest doskonałe, ale u mnie zadziałało i może oszczędzić ci sporo czasu i nerwów.

Mam nadzieję, że komuś jeszcze oszczędzi to kilku straconych wieczorów.