Salutare, am nevoie de un sfat de la cineva care a bătut drumul ăsta mai des decât mine. Am de ridicat 3 platforme Next.js pentru un client – un admin, un portal de clienți și un landing page – și am realizat rapid că vreo 80% din componentele de UI, logica de auth și utilitarele de formatare sunt identice.
Am început clasic cu npm workspaces, dar deja simt că mă îngroapă. Problema nu e neapărat partajarea codului, ci cum gestionez dependințele și, mai ales, cum fac să nu rulez teste pe tot repo-ul când modific un singur buton în UI-kit. La un proiect anterior, cu doar 2 app-uri, am ajuns să avem build-uri de 15 minute pe GitHub Actions pentru că nu aveam un sistem de cache inteligent. Vreau să evit mizeria aia.
Varianta 1: Turborepo (Favoritul meu momentan)
Am testat Turborepo pe un mic demo și mi se pare că e exact ce trebuie pentru cineva care vrea să rămână în ecosistemul JS fără să învețe un toolchain complet nou. Se configurează super ușor cu un turbo.json unde definești pipeline-ul. Ce mi-a plăcut enorm e treaba cu Remote Caching. La un alt proiect, am economisit vreo 30% la build time imediat ce am legat Vercel-ul la el, ceea ce e mare lucru când ai pipeline-uri care rulează de 20 de ori pe zi.
Totuși, mă tem că la 3 app-uri complexe, structura de packages/ui vs packages/utils o să devină un pic rigidă dacă nu sunt atent. Plus că am auzit colegi care s-au plâns de erori dubioase la importuri când foloseau versiuni diferite de Next între aplicații în interiorul aceluiași monorepo. Voi ați pățit-o?
Varianta 2: Nx (Tancul enterprise)
Am lucrat cu Nx pe un proiect gigant, cu peste 10 micro-frontends și 8k useri activi simultan. E incredibil de puternic, n-ai ce zice. Generatoarele alea de cod (nx generate @nx/next:app) te ajută enorm să păstrezi totul uniform și să nu ai fiecare app cu altă versiune de ESLint.
Dar vă zic sincer, mi se pare un pic prea mult „overhead” pentru ce am eu acum. Configurarea aia cu project.json în fiecare folder și tonele de plugin-uri mă fac să mă simt ca și cum aș învăța un framework nou, nu doar un tool de build. E un trade-off sincer: primești o structură foarte solidă și tool-uri de vizualizare a graficului de dependințe, dar plătești cu o curbă de învățare destul de abruptă. Merită efortul pentru doar 3 aplicații sau mă scarpin cu mâna stângă la urechea dreaptă?
Varianta 3: Workspaces simple (Fără nimic extra)
Asta e varianta „haiducească”. Folosești ce oferă pnpm sau yarn nativ. E varianta cea mai ușoară la setup, dar te doare capul la CI/CD. Dacă nu ai ceva care să știe ce s-a schimbat (celebrele affected commands), o să pierzi ore întregi în pipeline-uri rulând chestii care n-au nicio legătură cu commit-ul tău. Am încercat la un moment dat să scriu eu niște scripturi de bash care să detecteze folderele modificate, dar m-am lăsat păgubaș. Viața e prea scurtă pentru așa ceva și bug-urile care apar sunt pur și simplu frustrante.
Până la urmă, marea mea dilemă e legată de mentenanța pe termen lung. Vreau ceva care să nu explodeze peste 6 luni când un junior o să instaleze o librărie nouă doar într-unul dintre app-uri și o să bușească tot arborele de node_modules.
Voi cum ați aborda problema asta? Ați merge pe simplitatea de la Turborepo sau ați băga direct Nx pentru că „oricum o să crească proiectul”? Sau poate există o a patra cale, un setup de pnpm cu ceva scripturi de caching mai deștepte, de care nu m-am prins eu încă?