I'm trying to tackle the challenge of managing automatic versioning in a monorepo setup for our company's shared libraries. Our scenario involves having several packages, say A, B, and C, where A depends on B, and B, in turn, depends on C. A developer might directly use C in their project without referencing A or B, which creates a need for C to have its own version. I'm looking for tools or strategies that would allow me to update and publish all three packages in a single commit while ensuring that they are versioned in the correct order, meaning C should be updated and published before B. Am I on the right track thinking about monorepos this way?
1 Answer
One approach you could take is to use conventional commits for your versioning strategy and then handle the versioning automatically in your CI pipeline. This way, you can version the entire monorepo in one go, eliminating the need for manual updates for each package. The CI would read the commit log and determine the necessary version changes based on that. It's a more streamlined process that saves you from manually tracking version numbers for individual packages.
So, does that mean every time there's a commit to the main branch, all libraries get built and published? Or do you only handle the ones that changed and just tag the unchanged ones instead?