3 ms·

I think the big issue around monorepo is when a company puts completely different projects together inside a single repo. In this article almost everything mak

by h1fra 2y ago

I think the big issue around monorepo is when a company puts completely different projects together inside a single repo. In this article almost everything makes sense to me (because that's what I have been doing most of my career) but they put their OTP app inside which suddenly makes no sense. And you can see the problem in the CI they have dedicated files just for this App and probably very few common code with the rest. IMO you should have one monorepo per project (api, frontend, backend, mobile, etc. as long as it's the same project) and if needed a dedicated repo for a shared library.

fragmede 2y ago
> you should have one monorepo per project (api, frontend, backend, mobile, etc. as long as it's the same project) that's not a monorepo! Unless the singular "project" is stuff our company ships, the problem you have is of impedance mismatch between the projects, which is the problem that an actual monorepo solves. for swe's on individual projects who will never have the problem of having to ship a commit on all the repos at the "same" time, yeah that seems fine, and for them it is. the problem comes as a distributed systems engineer where, for whatever reason, many or all the repos need to be shipped at the ~same time. or worse - A needs to ship before B which needs ship before C but that needs to ship before A, and you have to unwind that before actually being able to ship the change.
- hk1337 2y ago
  > that's not a monorepo! Sure it is! It's just not the ideal use case for a monorepo which is why people say they don't like monorepos.
  - vander_elst 2y ago
    "one monorepo per project (api, frontend, backend, mobile, etc. as long as it's the same project) and if needed a dedicated repo for a shared library." They are literally saying that multiple repos should be used, also for sharing the code, this is not monorepo, these are different repos.
- h1fra 2y ago
  my implicit point was that most people don't want monorepo; when they talk about monorepo they talk about consolidating a project together, that can span many different repos and technology. I'm not convinced that making completely different teams work on the same repo is making things better. In the case of cascading dependencies what usually works better than a convoluted technical solution is communication.
klabb3 2y ago
> when a company puts completely different projects together inside a single repo. This is google3. It was absolutely loved by the majority of devs. If you change a line of code, all dependencies are type checked and tested and also a bunch of other things. It keeps so many versioning issues out. One of the big reasons why the JS ecosystem is so fragmented compared to Go or even Rust is the leftpad-sized packages with 10 config files that are out of date. Not to mention our friend peerDependencies, who needs no introduction.

by h1fra 2y ago

fragmede 2y ago

> you should have one monorepo per project (api, frontend, backend, mobile, etc. as long as it's the same project) that's not a monorepo! Unless the singular "project" is stuff our company ships, the problem you have is of impedance mismatch between the projects, which is the problem that an actual monorepo solves. for swe's on individual projects who will never have the problem of having to ship a commit on all the repos at the "same" time, yeah that seems fine, and for them it is. the problem comes as a distributed systems engineer where, for whatever reason, many or all the repos need to be shipped at the ~same time. or worse - A needs to ship before B which needs ship before C but that needs to ship before A, and you have to unwind that before actually being able to ship the change.

hk1337 2y ago
> that's not a monorepo! Sure it is! It's just not the ideal use case for a monorepo which is why people say they don't like monorepos.
- vander_elst 2y ago
  "one monorepo per project (api, frontend, backend, mobile, etc. as long as it's the same project) and if needed a dedicated repo for a shared library." They are literally saying that multiple repos should be used, also for sharing the code, this is not monorepo, these are different repos.
h1fra 2y ago
my implicit point was that most people don't want monorepo; when they talk about monorepo they talk about consolidating a project together, that can span many different repos and technology. I'm not convinced that making completely different teams work on the same repo is making things better. In the case of cascading dependencies what usually works better than a convoluted technical solution is communication.

klabb3 2y ago

> when a company puts completely different projects together inside a single repo. This is google3. It was absolutely loved by the majority of devs. If you change a line of code, all dependencies are type checked and tested and also a bunch of other things. It keeps so many versioning issues out. One of the big reasons why the JS ecosystem is so fragmented compared to Go or even Rust is the leftpad-sized packages with 10 config files that are out of date. Not to mention our friend peerDependencies, who needs no introduction.