GeistHaus
log in · sign up

Go Monorepo Challenges

cedwards.xyz

Earlier this year at work we decided to consolidate our Go code into a monorepo. This was driven by some pain points: Poor code sharing between services Services had sections of code that were duplicates or very similar. The duplicate code could have been extracted into another repo. We had some libraries we already shared between services, but the duplicate snippets were too small to justify another repo. An additional library repo which must be linted, tested, built, and released is more overhead for developers and make shipping slower. A ‘kitchen sink’ repo that collects these snippets would have been another option (we kind of had one anyway) but this introduces other challenges, like versioning. How can you properly semantically version a module with many unrelated API surfaces?

0 pages link to this URL

No pages have linked to this URL yet.