Protos have some relatively unique characteristics and pathologies that push me to recommend this pattern, where I wouldn’t necessarily do so for other “shared dependencies” (though I think I probably still favor a monorepo in most situations).
They’re fairly distinct as far as build targets go, since you often end up generating packages in multiple languages, and the relevant versioning strategy is per-build-target, not per-source-file. It is important to avoid the issues with inappropriate shared dependencies across protos that I mentioned in the article because that is one way you run into trouble with versioning, but imo the solution to that is “programmatically enforce proper separation of concerns within the monorepo”.
Protos have some relatively unique characteristics and pathologies that push me to recommend this pattern, where I wouldn’t necessarily do so for other “shared dependencies” (though I think I probably still favor a monorepo in most situations).
They’re fairly distinct as far as build targets go, since you often end up generating packages in multiple languages, and the relevant versioning strategy is per-build-target, not per-source-file. It is important to avoid the issues with inappropriate shared dependencies across protos that I mentioned in the article because that is one way you run into trouble with versioning, but imo the solution to that is “programmatically enforce proper separation of concerns within the monorepo”.