Monorepo med Turborepo: Dela kod mellan Next.js och React Native

När ett bolag har både en webbapp i Next.js och en mobilapp i React Native uppstår snabbt en irritation: samma typer, samma valideringsregler och samma affärslogik skrivs två gånger, och förr eller senare glider de isär. En monorepo löser det genom att lägga allt i samma kodbas och dela kod via interna paket. Men en naiv monorepo blir snabbt outhärdligt långsam att bygga - och det är där Turborepo kommer in. Den här guiden handlar om att göra det rätt.

Vad en monorepo löser - och vad den inte gör

En monorepo är inte magi. Den löser koddelning och gör det möjligt att ändra ett delat kontrakt och alla dess användare i en enda commit. Men den skapar inte automatiskt bra gränser - lägger ni bara allt i en mapp utan struktur får ni en stor röra istället för flera små. Disciplinen kring vad som är ett delat paket och vad som hör hemma i en app är minst lika viktig som verktyget, och något jag ofta hjälper team att sätta upp inom fullstack-arkitektur.

Strukturen: appar och paket

Den beprövade strukturen delar upp koden i två kategorier: appar (den körbara webbappen, mobilappen, eventuella tjänster) och paket (delad kod som flera appar använder). Ett typiskt delat paket innehåller domäntyper, valideringsscheman, affärslogik och ibland delade UI-primitiver. Apparna importerar från paketen, aldrig tvärtom. Den enkelriktade beroenderiktningen är vad som håller det begripligt när det växer.

Vad som faktiskt går att dela mellan webb och mobil

Här gäller det att vara realistisk. Typer, valideringslogik, API-klienter och ren affärslogik delas utmärkt mellan Next.js och React Native - det är ju vanlig TypeScript. UI är en annan sak. Webb och mobil renderar olika, så att dela visuella komponenter rakt av fungerar sällan. Det som lönar sig mest att dela är det icke-visuella: dataformerna och reglerna. Försök inte tvinga fram delade komponenter där plattformarna i grunden skiljer sig.

Turborepo: varför bygget inte blir långsamt

Det stora problemet med en växande monorepo är byggtid - om varje ändring bygger om allt blir det ohållbart. Turborepo löser det med två saker: det förstår beroendegrafen och bygger bara om det som faktiskt påverkats, och det cachar resultat så att oförändrade delar inte byggs om alls. Har du redan byggt ett paket och inte rört det, hämtas resultatet ur cachen istället för att räknas om. Det är skillnaden mellan en CI som tar minuter och en som tar sekunder.

Den delade cachen kan dessutom delas mellan utvecklare och CI, så att om en kollega redan byggt något behöver du inte bygga om det. För ett team är det en av de mest påtagliga tidsbesparingarna.

Fallgroparna att känna till

Monorepos har sina egna problem. Versionshantering av interna paket, att hålla beroenden konsekventa mellan appar, och att React Native har en historiskt kinkig relation till symlänkar och monorepo-strukturer. Det sista är värt att verifiera tidigt - mobilbygget är ofta det som krånglar mest i en monorepo. Planera för det istället för att upptäcka det sent.

När det lönar sig

En monorepo med Turborepo lönar sig när ni faktiskt har kod som ska delas mellan flera appar - särskilt webb och mobil med gemensam domän. För ett enda projekt är det överarbete. Men för ett bolag med både webb och app, eller flera relaterade tjänster, är vinsten i konsistens och utvecklingshastighet verklig. Hur ett sådant upplägg ser ut i praktiken visar jag i kundcase.

Relaterat

• TypeScript-arkitektur för team på 3-30 utvecklare
• AI SDK från Vercel: Bygg copilot-features i din Next.js-app
• Postgres för SaaS-bolag: Partitioning, indexing och read replicas

Vill du ta det vidare?

Jag hjälper team att sätta upp en monorepo med Turborepo som delar rätt kod mellan webb och mobil - med ett bygge som håller sig snabbt. Boka ett samtal så går vi igenom er situation.