eduardweb.
Ajutor & ÎntrebăriIntermediar#nextjs#react#monorepo#turborepo#pnpm

Monorepo cu 3 app-uri Next.js și 80% componente shared: Turborepo, Nx sau simple workspaces?

De Bogdan Răducanu, 14 iun. 2026 · 15 vizualizări · 2 like-uri

Postat 14 iun. 2026
json
{
  "$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 și packages/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?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.