{
"$schema": "https://turbo.build/schema.json",
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": [".next/**", "!.next/cache/**"]
},
"lint": {},
"dev": {
"cache": false,
"persistent": true
}
}
}M-am lovit recent de problema asta la un proiect cu trei SaaS-uri care foloseau practic aceleași butoane, tabele și layout-uri. Dacă ești în punctul în care dai copy-paste la componente de la un proiect Next.js la altul, oprește-te acum. Hai să îți zic cum am trecut de la frustrare la un build time redus cu 40% alegând tool-ul potrivit de monorepo.
Opțiunea 1: Workspaces simple (pnpm / npm workspaces)
Am început clasic, cu pnpm workspaces. Fără tool-uri fancy, doar un package.json în rădăcină care declară unde sunt aplicațiile și pachetele shared.
E genial de simplu de configurat, îți ia fix 5 minute. Dar am dat rapid cu capul de pragul de sus. Problema apare când rulezi next build în CI/CD. Fără un sistem inteligent de cache, serverul tău de build va compila de fiecare dată absolut tot, chiar dacă ai modificat doar un text într-un singur app. La un proiect cu 8k utilizatori unde făceam deploy des, să aștept 15 minute la fiecare push a devenit rapid insuportabil.
Trade-off: E perfect pentru proiecte mici sau la început de drum, dar devine un coșmar pe măsură ce codul crește.
Opțiunea 2: Nx (Artileria grea)
Disperat de timpii de build, am zis să trecem la Nx. Nx e un monstru sacru. Știe de toate: dependency graphing vizual, generatoare de cod, caching local și în cloud, ba chiar îți poate rula doar testele afectate de o anumită modificare.
Dar m-am lovit de o barieră mentală a echipei. Curba de învățare e abruptă rău. Configurația seamănă cu ceva scris în Java acum 10 ani, plină de JSON-uri gigantice și concepte pe care un dev de frontend nu vrea să le învețe doar ca să pornească un server local.
Trade-off: Dacă ai o echipă de peste 15 oameni și un monorepo mixt (să zicem Next.js plus un backend în NestJS sau Go), Nx își merită toți banii. Pentru cele 3 aplicații ale noastre, a fost overkill curat. Ne-am simțit ca și cum am fi cumpărat un tanc ca să mergem la Mega Image.
Opțiunea 3: Turborepo (The Sweet Spot)
Aici am găsit în sfârșit liniștea. Fiind dezvoltat de Vercel, Turborepo se înțelege perfect cu Next.js. Configurația se reduce la un fișier turbo.json de 15-20 de linii unde definești pipeline-ul de build și testare.
Spre deosebire de Nx, Turbo nu încearcă să-ți controleze codul sau să-ți impună cum să scrii rutele. Rămâi tot cu structura clasică de pnpm workspaces, dar Turbo vine ca un strat ultra-rapid de cache deasupra. Dacă nu ai modificat nimic în pachetul de UI shared, Turbo ia build-ul direct din cache-ul local (sau din cloud, dacă folosești Vercel) în sub o secundă.
Cum am structurat proiectul
Am împărțit monorepo-ul extrem de simplu:
apps/admin(Next.js)apps/site-prezentare(Next.js)apps/app-client(Next.js)packages/ui(aici am pus cele 80% din componente shared)packages/eslint-configșipackages/tsconfig(pentru reguli comune)
În packages/ui am exportat componentele direct ca TypeScript (fără build separat), lăsând Next.js din fiecare aplicație să facă transpilarea prin opțiunea transpilePackages în next.config.js. Asta ne-a scutit de un pas în plus de build pentru librăria de componente.
Concluzia mea
Mergi pe pnpm + Turborepo. Este cea mai curată, rapidă și lipsită de bătăi de cap combinație pentru ecosistemul React și Next.js în momentul de față.
Voi ce folosiți acum pentru monorepouri? V-ați lovit de probleme de cache ciudate în Turborepo la deploy-urile pe Vercel sau Netlify?