Am avut recent un proiect unde trebuia să ridicăm trei aplicații Next.js pentru niște clienți diferiți, dar care foloseau practic același design system. Vorbim de un grad de reutilizare de vreo 80%, de la butoane simple până la logica de autentificare și fetching de date. Prima tendință a fost să trântesc totul într-un repo mare și să sper că npm workspaces mă va salva. Spoiler: m-am încurcat în versiuni de dependencies mai repede decât aș fi vrut să admit.
Când ai 80% cod comun, problema nu e doar unde pui fișierele, ci cum te asiguri că o schimbare în shared/Button.tsx nu îți bușește toate cele trei aplicații în producție fără să știi. Am testat toate cele trei variante pe care le tot auziți pe forumuri și am rămas cu niște concluzii destul de clare.
Workspaces simple (npm/pnpm/yarn)
E varianta „săracului”, dar e perfect validă dacă ești la început. Am pornit așa la un proiect mic cu vreo 5k useri și a mers ok vreo două luni. Avantajul e că nu înveți nimic nou, doar configurezi un package.json la root.
Problema apare la build time. Fără un sistem de caching, CI-ul tău o să ruleze build pentru toate cele 3 aplicații de fiecare dată când schimbi un typo într-un README. La proiectul de care zic, am ajuns de la 4 minute de build la 15 minute doar pentru că am adăugat câteva librării mai grele în shared. Dacă nu ai nevoie de caching local sau remote, mergi pe pnpm workspaces și aia e. Dar la 80% shared code, o să plângi lângă terminal.
Turborepo: Sweet spot-ul pentru Next.js
După ce m-am săturat de timpii de build, am trecut la Turborepo. Mi s-a părut cea mai naturală tranziție. E făcut de băieții de la Vercel, deci „se pupă” perfect cu Next.js.
Ce am câștigat imediat: caching. Dacă aplicația B nu s-a schimbat și nici dependențele ei din packages/ui nu s-au atins, Turbo sare peste build și îmi dă rezultatul din cache. Am economisit cam 60% din timpul de CI din prima zi. Configurația e un fișier turbo.json de 20 de linii unde îi spui ce depinde de ce.
Trade-off-ul? Turborepo e destul de „hands-off”. Nu te ajută cu generarea de cod sau cu impunerea unor reguli stricte de arhitectură. E doar un orchestrator de task-uri foarte rapid. Dacă echipa e mică (2-3 oameni) și toți știți ce faceți, e ideal.
Nx: Când vrei să fii „enterprise”
Nx e o bestie total diferită. L-am folosit la un proiect mai vechi unde aveam și backend de NestJS în același repo. E mult mai „opinionated”. Îți oferă generatoare (dai o comandă și îți face componenta cu tot cu teste și storybook), are grafice de dependențe vizuale și e mult mai riguros.
Totuși, pentru 3 app-uri de Next.js, mi s-a părut overkill. Setup-ul durează mai mult, iar plugin-urile lor uneori rămân în urmă cu versiunile de Next.js. Dacă vrei să simți că lucrezi la Google și ai nevoie de „boundaries” stricte (să nu poți importa din app A în app B din greșeală), Nx e regele. Dar pregătește-te de o curbă de învățare serioasă.
Cum am structurat până la urmă
Indiferent de tool, secretul a fost să nu fac un singur pachet gigant numit shared. Am spart totul în:
packages/ui: doar componente „proaste” (butoane, input-uri, layout).packages/hooks: logica de react.packages/api: instanțele de axios/query și definițiile de tipuri.packages/utils: chestii de formatare, validări.
De ce așa? Pentru că dacă schimbi ceva în utils, nu vrei neapărat să re-testezi tot ce ține de vizual în ui.
Voi cum gestionați partajarea asta masivă de cod? Preferați libertatea din Turborepo sau structura rigidă din Nx?