4 ms·

> Doesn't google have a lot of internal tooling to make that monorepo actually work for them? probably tests coverage and workflow matters: you can work with m

• wongarsu 3y ago
  At its core, with separate repositories it's generally fine to pretend that any commit effects all code within that repo. So for example you might run all unit tests for every new commit in a PR, or run all deploy scripts when something is committed to master. Dependencies are usually set up one-way, so code pulls it its dependencies (by referencing specific git commits or released packages). So a change in one repository might mean that it pulls in new or updated dependencies, but software depending on you should only see changes once a change is made to its repository. For a monorepo those assumption don't hold, any given commit likely only affects a tiny fraction of the content of the monorepo. But a change in a library might also immediately radiate outward to anything in that repo that uses the library, so you can't do a naive check based on the directory tree. So you end up with a build system like bazel that can evaluate the entire dependency graph to know what to run. And you have to do that for pretty much all tooling you want to be triggered by code changes. Add on top of that the scaling issues you have with git as your repository grows
• deleted 3y ago
  [deleted]