I’m curious with all the movement lately towards the mono-repos with all the specialized functionality being extracted out of Ghost, what led to this decision?
I’m debating something similar with a large internal work project and just curious the big reasons that led you to these choices.
For myself I see:
Pro
Each module can be individually tested and stabilized
Can re-used outside of project
Con
Difficult to build everything into an individual unit when naturally things on depend on eachother
Causes main trunk/repo to be just updating package commits
Puts dependency on a changing ecosystem (workspace vs lerna vs yarn)
You’ve nailed a couple of the Pro’s but missed a few:
Easier to define who is responsible for individual units of code
Stable mature code lives elsewhere & doesn’t have to be considered when making updates (much like we wouldn’t think about the code in e.g. lodash)
Separation enforces loose coupling
Actually that last one is one of the most critical because tight coupling is the biggest blocker to shipping new things and having code colocated as it is currently not only permits, but actually encourages tight coupling as the easiest way to architect the code.
All that being said, there were a few people who advocated for us building Ghost’s codebase in small modules from the get go, and at the size we were then I believe it would have been an impediment. Now that we’ve built a stable business & have more people working on the codebase, it’s the right time for us to start breaking it down into smaller more manageable chunks.
If you’re curious about this sort of decision making I highly recommend this book:
Thank you for the detailed response! I forgot about the aspect of maintainers of sections of the code, that is a very good point that makes it much easier when its a sub project vs a couple of spread around files in a larger project.
Looks like an interesting book for sure, will pick it up.