3 ms·

Could you elaborate? I use a monorepo at work and if anything dealing with 3rd party dependencies is easier because you don't have to coordinate upgrading versi

Could you elaborate? I use a monorepo at work and if anything dealing with 3rd party dependencies is easier because you don't have to coordinate upgrading versions across teams. For 1st party stuff in the repo we don't have a need to version libraries at all, if it all builds and passes all the tests everything is good. The whole point is to use the whole tree from a consistent snapshot as a release, so you never worry about using a new first party library with an old first party binary.

jsnell 5y ago
If you're able to release everything as a consistent snapshot, it probably is not a monorepo. Instead it is just a normal repo containing a single big project. Here's an example: let's say that is you've got a single product with a backend server, database, web frontend, and a iOS app. How would you release all those projects as an atomic unit? If there's a new field in this release, the database schema needs to be changed on the servers before the backend is released. The backend needs to change before the frontends do. You have no control over the deployment speed of some of those components, so releasing them all at the same time is impossible. Similar issues would happen if you update 3rd party library, and software using the new Vs. old versions of the library are incompatible. So the value of this monorepo isn't that you could cut a release for all of the components at once. It is that everyone doing development has a shared view of the current state of the system.
- dataangel 5y ago
  We deal with that too, but only for network/file format compatibility. We don't ship libraries used by an external group.
rfoo 5y ago
Yeah, that's what I meant by "morphing dependency management problem to a source control problem". With a monorepo dependency management is way easier! But, sometimes: - git on large repo 100% pain 0% fun. hg is slightly better, but not much. - No version means no prebuilt libraries, which translates to "you need a great build cache to keep build time reasonable". - "passes all the tests everything is good" if only we can run all the tests on such changes. - People hate coordinating on imported/pinned third-party dependency versions, sometimes you need tools for large-scale automated changes to make progress, but :( - Similarly, not all places make all their codes accessible to all engineers. i.e. source control problem is, sometimes, harder.

jsnell 5y ago

If you're able to release everything as a consistent snapshot, it probably is not a monorepo. Instead it is just a normal repo containing a single big project. Here's an example: let's say that is you've got a single product with a backend server, database, web frontend, and a iOS app. How would you release all those projects as an atomic unit? If there's a new field in this release, the database schema needs to be changed on the servers before the backend is released. The backend needs to change before the frontends do. You have no control over the deployment speed of some of those components, so releasing them all at the same time is impossible. Similar issues would happen if you update 3rd party library, and software using the new Vs. old versions of the library are incompatible. So the value of this monorepo isn't that you could cut a release for all of the components at once. It is that everyone doing development has a shared view of the current state of the system.

dataangel 5y ago
We deal with that too, but only for network/file format compatibility. We don't ship libraries used by an external group.

rfoo 5y ago

Yeah, that's what I meant by "morphing dependency management problem to a source control problem". With a monorepo dependency management is way easier! But, sometimes: - git on large repo 100% pain 0% fun. hg is slightly better, but not much. - No version means no prebuilt libraries, which translates to "you need a great build cache to keep build time reasonable". - "passes all the tests everything is good" if only we can run all the tests on such changes. - People hate coordinating on imported/pinned third-party dependency versions, sometimes you need tools for large-scale automated changes to make progress, but :( - Similarly, not all places make all their codes accessible to all engineers. i.e. source control problem is, sometimes, harder.