4 ms·

> The single version dependencies are asinine. We are migrating to > a monorepo at work, and someone bumped the version of an open > source JS package that

> The single version dependencies are asinine. We are migrating to > a monorepo at work, and someone bumped the version of an open > source JS package that introduced a regression. There's no requirement to have single versions of dependencies in a monorepo. Google allows[0] multiple versions of third-party dependencies such as jQuery or MySQL, and internal code is expected to specify which version it depends on. > It encourages poor API contracts because it lets anyone import any > code in any service arbitrarily. Not true at Google, and I would argue that if you have a repository that allows arbitrary cross-module dependencies then it's not really a monorepo. It's just an extremely large single-project repo with poor structure. The defining feature of a monorepo is that it contains multiple unrelated projects. At Google, this principle was so important that Blaze/Bazel has built-in support for controlling cross-package dependencies. > I see at least one PR every week [...] because some shared config > or code changed in another part of the repo and now the entire repo > needs to be migrated in lockstep for things to compile. That really doesn't sound like a monorepo to me. If all the code has to be migrated "in lockstep", then that implies a single PR might change code across different parts of the company. At which point it's not independent projects in a monorepo, it's (merely) a single giant project. [0] Or allowed -- I last worked there in 2017.

lopkeny12ko 4y ago
> There's no requirement to have single versions of dependencies in a monorepo. Google allows[0] multiple versions of third-party dependencies such as jQuery or MySQL, and internal code is expected to specify which version it depends on. Sure, but this is unsustainable. If service Foo depends on myjslib v3.0.0, but service Bar needs to pull in myjslib v3.1.0, in order to make sure Foo is entirely unchanged, you'd have to add a new dependency @myjslib_v3_1_0 used only by Bar. After two years you'd have 10 unique dependencies for 10 versions of myjslib in the monorepo. At this point you've basically replicated the dependency semantics of a multi-repo world to a monorepo, with extra cruft. This problem is already implicitly solved in a multi-repo world because each service simply declares its own dependencies.
- myko 4y ago
  > Sure, but this is unsustainable. Not exactly unsustainable considering Google has been very successful with this approach!
  - zelphirkalt 4y ago
    Is this a good comparison? Not everyone is Google-size. In fact, very few businesses are. What is managable for Google or a good practice for Google, might be unsustainable for another business.
    - saalweachter 4y ago
      I think the lesson to draw from bigorgs isn't what to as a smallorg, but what directions you can grow and what the pitfalls are on those roads. Any smallorg probably wants a bare monorepo, git or what have you. If you grow to the point that becomes unwieldy, you can either invest in tooling the way Google has, or be prepared to split the repo into library and project repos in a way that makes sense for what your mediumorg has grown into.
      - zelphirkalt 4y ago
        What is a "bare monorepo" in contrast to simply a "monorepo"?
        saalweachter 4y ago
        Google is a monorepo with sixteen layers of tooling to make it searchable, to not require you to spent 3 days making a local copy before editing, to manage permissions across orgs, etc etc etc. A small organization of 1-20 people should not emulate the layers of tooling; just have a single git repo somewhere and call it a day.
  - astrange 4y ago
    Google isn't successful because of their tech decisions. They just happen to make an infinite amount of ad money; everything else they do is mainly getting their engineers to play in sandboxes to distract them so they won't leave to start other ad markets. It works though, since everyone is in love with their complex makework ideas.
graveltongue 4y ago
https://opensource.google/documentation/reference https://opensource.google/documentation/reference The third party documentation is public, one-version policies exist but they are exemptions.
zelphirkalt 4y ago
I guess the question then becomes: Is it worth all the extra tooling required to manage a monorepo properly?
- smrtinsert 4y ago
  The answer of course is no, but since they have a stable search product that supplied unlimited money, they were able to stubbornly stick to that decision.
- KptMarchewa 4y ago
  There is a lot of extra tooling required to manage a large non-monorepo org too.
ASinclair 4y ago
There’s a policy against multiple versions of third party dependencies. Though there is a mechanism for exceptions.
- dx034 4y ago
  Sounds sane, usually you don't want multiple versions just because people were too lazy to keep code up to date. But in some instances it's probably worth supporting several major versions across the whole org.
throwaway2037 4y ago
I never worked at Google, but this post sums up everything I had to say about the matter. GP has a sh-tty monorepo experience at one company and decides to make a statement about another company where they never worked (so I presume). HN absurdism as its best! I second your point about monorepo versus ball of mud. They are so different. And managing all of this is about social/culture, less science-y. If you don't have good culture around maintenance, well then, yeah, duh, it will fall apart pretty quickly. It sounds like Google spends crazy money to develop tools to enforce the culture. Hats off.
- 8note 4y ago
  It generally gives the sense that mono-repo is actually irrelevant, and the more detailed processes across the whole experience are what matters.
- des429 4y ago
  Yep, the top comment in this thread is a fantastic example of typical HN comments. Naïveté masked as expertise.
joshuamorton 4y ago
There's always been a very strong one version policy, multiple versions are usually only allowed to coexist for weeks or months, and are usually visibility restricted. This prevents situations where "Gmail" ends up bundling 4 different, mildly incompatible versions of MySQL or whatever, and the aggravation that would cause. Or worse, in c++ you get ODR violations due to a function being used from two versions of the same library.
taeric 4y ago
I think the catch, is that it isn't just third-party dependencies that are of concern. In particular, at a certain size, you are best off treating every project in the company as a third party item. But, that is typically not what you are wanting with source dependencies. You can see this some with how obnoxious Guava was, back in the day. It seems a sane strategy where you can deprecate things quickly by getting all callers to migrate. This is fantastic for the cases where it works. But, it is mind numbingly frustrating in the cases where it doesn't. Worse, it is the kind of work that burns out employees and causes them to not care about the product you are trying to make. "What did you do last month?" "I managed to roll out an upgrade that had no bearing on what we do."

lopkeny12ko 4y ago

> There's no requirement to have single versions of dependencies in a monorepo. Google allows[0] multiple versions of third-party dependencies such as jQuery or MySQL, and internal code is expected to specify which version it depends on. Sure, but this is unsustainable. If service Foo depends on myjslib v3.0.0, but service Bar needs to pull in myjslib v3.1.0, in order to make sure Foo is entirely unchanged, you'd have to add a new dependency @myjslib_v3_1_0 used only by Bar. After two years you'd have 10 unique dependencies for 10 versions of myjslib in the monorepo. At this point you've basically replicated the dependency semantics of a multi-repo world to a monorepo, with extra cruft. This problem is already implicitly solved in a multi-repo world because each service simply declares its own dependencies.

myko 4y ago
> Sure, but this is unsustainable. Not exactly unsustainable considering Google has been very successful with this approach!
- zelphirkalt 4y ago
  Is this a good comparison? Not everyone is Google-size. In fact, very few businesses are. What is managable for Google or a good practice for Google, might be unsustainable for another business.
  - saalweachter 4y ago
    I think the lesson to draw from bigorgs isn't what to as a smallorg, but what directions you can grow and what the pitfalls are on those roads. Any smallorg probably wants a bare monorepo, git or what have you. If you grow to the point that becomes unwieldy, you can either invest in tooling the way Google has, or be prepared to split the repo into library and project repos in a way that makes sense for what your mediumorg has grown into.
    - zelphirkalt 4y ago
      What is a "bare monorepo" in contrast to simply a "monorepo"?
      - saalweachter 4y ago
        Google is a monorepo with sixteen layers of tooling to make it searchable, to not require you to spent 3 days making a local copy before editing, to manage permissions across orgs, etc etc etc. A small organization of 1-20 people should not emulate the layers of tooling; just have a single git repo somewhere and call it a day.
- astrange 4y ago
  Google isn't successful because of their tech decisions. They just happen to make an infinite amount of ad money; everything else they do is mainly getting their engineers to play in sandboxes to distract them so they won't leave to start other ad markets. It works though, since everyone is in love with their complex makework ideas.

graveltongue 4y ago

https://opensource.google/documentation/reference https://opensource.google/documentation/reference The third party documentation is public, one-version policies exist but they are exemptions.

zelphirkalt 4y ago

I guess the question then becomes: Is it worth all the extra tooling required to manage a monorepo properly?

smrtinsert 4y ago
The answer of course is no, but since they have a stable search product that supplied unlimited money, they were able to stubbornly stick to that decision.
KptMarchewa 4y ago
There is a lot of extra tooling required to manage a large non-monorepo org too.

ASinclair 4y ago

There’s a policy against multiple versions of third party dependencies. Though there is a mechanism for exceptions.

dx034 4y ago
Sounds sane, usually you don't want multiple versions just because people were too lazy to keep code up to date. But in some instances it's probably worth supporting several major versions across the whole org.

throwaway2037 4y ago

I never worked at Google, but this post sums up everything I had to say about the matter. GP has a sh-tty monorepo experience at one company and decides to make a statement about another company where they never worked (so I presume). HN absurdism as its best! I second your point about monorepo versus ball of mud. They are so different. And managing all of this is about social/culture, less science-y. If you don't have good culture around maintenance, well then, yeah, duh, it will fall apart pretty quickly. It sounds like Google spends crazy money to develop tools to enforce the culture. Hats off.

8note 4y ago
It generally gives the sense that mono-repo is actually irrelevant, and the more detailed processes across the whole experience are what matters.
des429 4y ago
Yep, the top comment in this thread is a fantastic example of typical HN comments. Naïveté masked as expertise.

joshuamorton 4y ago

There's always been a very strong one version policy, multiple versions are usually only allowed to coexist for weeks or months, and are usually visibility restricted. This prevents situations where "Gmail" ends up bundling 4 different, mildly incompatible versions of MySQL or whatever, and the aggravation that would cause. Or worse, in c++ you get ODR violations due to a function being used from two versions of the same library.

taeric 4y ago

I think the catch, is that it isn't just third-party dependencies that are of concern. In particular, at a certain size, you are best off treating every project in the company as a third party item. But, that is typically not what you are wanting with source dependencies. You can see this some with how obnoxious Guava was, back in the day. It seems a sane strategy where you can deprecate things quickly by getting all callers to migrate. This is fantastic for the cases where it works. But, it is mind numbingly frustrating in the cases where it doesn't. Worse, it is the kind of work that burns out employees and causes them to not care about the product you are trying to make. "What did you do last month?" "I managed to roll out an upgrade that had no bearing on what we do."