4 ms·

I thought the monorepo setup made cross-project dependency changes easy?

Moto7451 7y ago
Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice. Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need. The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.
skybrian 7y ago
Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back. Often it's better to introduce a new function and migrate usages to it across multiple commits. Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.
- mav3rick 7y ago
  In Chrome, more often than not it happens in one big commit.
  - skybrian 7y ago
    That's a single project (though a large one). I'm thinking of lower layers where there are many downstream projects.
hoophoop 7y ago
Not at all. Monorepo is merely a detail around VCS and it does not remove complexity and the need for versioning.
- tedmiston 7y ago
  Yes, and because you can atomically update an internally breaking API change across all consumer projects in the same commit as the change itself, the monorepo setup is touted as reducing complexity where this change would otherwise be non-atomic across many repos. https://danluu.com/monorepo/ https://danluu.com/monorepo/

Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice. Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need. The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.

skybrian 7y ago

Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back. Often it's better to introduce a new function and migrate usages to it across multiple commits. Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.

mav3rick 7y ago
In Chrome, more often than not it happens in one big commit.
- skybrian 7y ago
  That's a single project (though a large one). I'm thinking of lower layers where there are many downstream projects.

hoophoop 7y ago

Not at all. Monorepo is merely a detail around VCS and it does not remove complexity and the need for versioning.

tedmiston 7y ago
Yes, and because you can atomically update an internally breaking API change across all consumer projects in the same commit as the change itself, the monorepo setup is touted as reducing complexity where this change would otherwise be non-atomic across many repos. https://danluu.com/monorepo/ https://danluu.com/monorepo/