{
"$schema": "https://turbo.build/schema.json",
"globalDependencies": ["**/.env.*local"],
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": [".next/**", "!.next/cache/**"]
},
"dev": {
"cache": false,
"persistent": true
}
}
}Salutare comunitate. Zilele astea m-am lovit de o dilemă destul de spinoasă pe un proiect cu 3 aplicații Next.js care împart peste 80% din componentele de UI. Vreau să vă povestesc cum am abordat problema și unde am dat cu capul de pragul de sus, poate vă scutesc de câteva zile de research inutil.
Problema de la care am plecat
Avem un dashboard de client, o platformă de admin și un site public de prezentare. Toate scrise în Next.js cu App Router. Din start, designul e identic: aceleași butoane, aceleași tabele, aceleași modale și, cel mai important, aceiași helperi de TypeScript pentru API-ul nostru.
La început, băieții din echipă au vrut să facem copy-paste la componente. Am zis exclus. Am trecut de faza asta acum 8 ani și încă am coșmaruri cu bug-uri reparate într-un loc și uitate în alte două. Aveam nevoie de un monorepo curat, dar fără să ne complicăm viața inutil.
Opțiunea 1: Simple npm workspaces (Fără tool-uri în plus)
Am zis să începem simplu, direct din Node. Am configurat un package.json în root cu workspaces: ["apps/*", "packages/*"] și am pus componentele comune într-un pachet local numit @repo/ui.
Merge ok la început, dar devine rapid un calvar la build-uri. Dacă modificam o singură linie într-un utilitar din pachetul comun, trebuia să reconstruiesc manual totul ca să văd schimbările în aplicația principală. Zero caching inteligent. În pipeline-ul de CI/CD, timpul de build a sărit rapid la 14 minute pentru toate cele trei aplicații. Enorm.
Opțiunea 2: Nx (Uzina grea)
Nx e un instrument extraordinar, l-am folosit în trecut la un proiect enterprise cu peste 15 aplicații Angular și NestJS. Dar pentru cele 3 aplicații ale noastre Next.js, mi s-a părut că tragem cu tunul în vrăbii.
Configurația e imensă. Generatoare peste generatoare, fișiere project.json în fiecare folder și o curbă de învățare destul de abruptă pentru colegii mai juniori. Dacă se strică ceva în pipeline-ul de build, pierzi jumătate de zi căutând prin documentația lor stufoasă. Pentru noi, trade-off-ul pur și simplu nu a meritat.
Opțiunea 3: Turborepo (Alegerea câștigătoare)
Am zis să testăm Turborepo, mai ales că e dezvoltat tot de cei de la Vercel. Integrarea ne-a luat fix 20 de minute. Am definit un fișier turbo.json simplu în root și gata.
Caching-ul local și remote ne-a salvat viața. Când rulez turbo build local, dacă nu am schimbat nimic în codul comun, build-ul durează 2 secunde pentru că își ia totul din cache. În CI, am conectat cache-ul la Vercel și am scăzut timpul total de build de la 14 minute la doar 3 minute și jumătate. Am economisit peste 70% la build time și, implicit, am redus costurile cu serverele de CI.
Trade-off-urile de care trebuie să știi
Nu e totul roz în tabăra Turborepo. Când folosești componente comune în Next.js, te lovești rapid de problema directivelor "use client". Dacă o componentă din @repo/ui are state sau efecte de React, trebuie neapărat să pui directiva direct în pachetul comun, altfel Next.js crapă la build-ul aplicației gazdă.
Un alt hop a fost configurarea Tailwind CSS. Trebuie să te asiguri că fișierele tailwind.config.js din fiecare aplicație scanează și folderul de componente comune (ex: ../../packages/ui/**/*.{js,ts,jsx,tsx}). Altfel, te trezești cu stiluri lipsă în producție și nu înțelegi de ce.
Voi cum v-ați structurat monorepo-urile de genul ăsta? Ați rămas pe simple workspaces sau ați trecut toți la Turbo/Nx?