Versioning van packages binnen een Mono Repo

[Tim91]

Wij hebben op dit moment een React app (App1) in een single repository zitten. Binnenkort moet er een tweede React app (App2) gebouwd worden waarbij we eigenlijk een hoop componenten en code willen hergebruiken van App1.

Ik heb gekeken naar diverse oplossingen hiervoor en daarbij leek het opzetten van een Mono Repo waarin we onze twee applicaties hebben zitten + een aantal gedeelde libraries het beste idee en het makkelijkst om op te zetten.

Nu ik me in mono repo's aan het verdiepen ben lijkt het er echter op dat als je een shared library versie update, je dit eigenlijk direct doorvoert in al je applicaties die je in deze monorepo hebt zitten. Dit is echter wel iets waar we zelf controle over willen hebben. Onze App1 is namelijk een applicatie de we vaker willen deployen dan onze App2. kunnen we bijvoorbeeld van 1 shared library in onze 2 applicaties vrij eenvoudig 2 verschillende versies van onze shared library gebruiken?

De tools waar ik nu voornamelijk naar gekeken heb zijn Nx en TurboRepo.

[ValHallASW]

Het voordeel van een monorepo is dat je een refactoring backwards-incompatible kunt doorvoeren omdat je meteen al je afnemers kunt aanpassen.

De andere kant van de medaille is dat je die refactoring vervolgens ook in al je afnemers moet aanpassen.

Als je dát niet wilt, dan is een monorepo waarschijnlijk niet de juiste oplossing voor je probleem.
Componenten los versionen = losgekoppeld branchen/taggen = losgekoppelde repositories

Last but not least, als je twee applicaties en een paar shared libraries hebt, dan heb je daar geen complexe build tooling voor nodig. Maak één build waar je álles (alle shared libraries en beide applicaties) bouwt. Als je op het punt komt waar dat niet meer schaalt dan wordt het tijd om naar complexere build systems te kijken.

[ Voor 5% gewijzigd door ValHallASW op 17-10-2022 20:44 ]

[Tim91]

Okee duidelijk. Wij moeten overigens wel heel veel uit App1 los gaan trekken en ervoor zorgen dat we deze zaken in App2 ook kunnen gebruiken. App2 moet nog nieuw ontwikkeld worden dus het lijkt mij wel handiger om deze allebei in eerste instantie in een monorepo te plaatsen en daar dan ook de gedeelde packages te ontwikkelen en de structuur hiervan te bepalen. Het lijkt mij dat het wel vrij eenvoudig is om die gedeelde packages (Of een deel ervan) alsnog los te trekken zodat we ze los kunnen versioneren?

[ValHallASW]

Zolang je uitkijkt met welke dependencies je legt is dat geen probleem. In andere woorden: niet per ongeluk een dependency tussen App1 en App2 aanleggen. Je begint dan met een enkel project met daarin beide apps en een of meerdere shared libraries. Op dat moment hoef je nog niet na te denken over versioning. Zogauw alles wat stabieler wordt kan je dan alles een zinnige versie geven, de repo opsplitsen en via npm de dependencies managen.