Since the advent of the microservices concept, most people are fans of distributed architectures. You don't want to have single points of failure, have autonomy across teams, and want to customize tech stack by service.
This concept has propagated into domains other than services too.
At work, we had three different repos catering to one single application - two libraries, and one repo for the actual configuration which just mapped components from the libraries onto the actual Angular app.
The idea behind this was primarily, the separation of concerns. Repo A included fundamental components and styling, say, dialog boxes, text editors, toasts and their corresponding styles. Repo B included actual application components organized on the basis of business logic and their occurrence on the application. Both A and B were built, deployed and their prod build versions injected as npm packages into C.
Now, for an application as large and diverse as ours, it kinda made sense. If you just had to make a config change, we wouldn't really want to rebuild fundamental CSS all over again. Different teams could own these repos differently and you could get the latest working version of any of these repos by picking the last build version from the common artifactory.
Now, however, there come the pitfalls :
-
Cumbersome fixing and testing : If I have to make a fundamental CSS change, in repo A, I need to fix it in A, test it in B, and then finally in C. I essentially have to setup and run all three repos for a minor CSS change. Because the repos were owned separately, there's a fair chance they'd have their separate requirements in terms of setup, dependencies and run commands. How much of an overhead for such a little change? Wouldn't it be better to just have one repo, fix something, and voila, see the change?
-
Inconsistent design : If you want to make a CSS change to a component, do you make it in A or B? It's a subjective question and varies by use case, so most people just did what they felt was right, meaning half the changes were in one repo, half in another. One actual example - our dialog boxes were styled from Repo A in two of our application tabs and from Repo B in the remaining 3. Who'd remember where the styles are coming from then?
-
Versioning : Some change works on x.1 version of Repo A, y.2 version of B and z.3 version of C. Now, everytime, we have to check this version compatibility. Changing one of the versions could adversely impact the rest.
-- work in progress--