241–250 of 270 posts
Earlier quoted context omitted.
Ah - that would explain why at my current job there was a node_modules directory in git with nearly 2 million lines of Javascript within. It is gone now.
Ugh The price of letting less experienced people "go crazy" in the repo
Earlier quoted context omitted.
Can't those xlf files be stored in a separate repo or in an object storage and let the build system fetch them from there?
That wouldn't be called a "monorepo" then :D Obviously, the problems they are solving (and admitting to solving) are due to their dedication to the monorepo. With all the effort spent on working around the drawbacks, I really wonder what advantages they are seeing that make it worth their while?
Earlier quoted context omitted.
The perceived ease of that operation in a monorepo is what makes it dangerous. Unless these changes all map to a single monolith service, then even though you have updated all call sites, these callers will not be deployed all at the same time, meaning as the change rolls out you may see random breakage. By using polyrepo, the deployment boundary can align with the code boundary, making the rollout problem obvious.
People point this out often, but in practice I have never seen this cause issues. Remove callers first, then remove endpoint... its pretty obvious the order in which things need to be done. What I have seen as a real problem, time and time again, is having trouble locating all usages of an API in a multi-repo scenario. Anyone who fucks this up in a monoreppo will probably fuck it up worse with multiple repos.
I get a headache imagining everything Google in a monorepo. So how do you reconcile this single GIT repository approach with Infoworld's "The case against monorepos"? [1]: Reason #1. Monorepos go against single-team ownership principles Reason #2. Monorepos encourage bad practices involving massive refactoring Reason #3: Small repositories are better than large ones [1] https://www.infoworld.com/article/3638860/the-c…
I think the biggest problem here is that git (out of the box) is not well suited to a monorepo. But in terms of the reasons in "The case against monorepos": > Reason #1. Monorepos go against single-team ownership principles I think it's up for debate about whether or not single-team ownership is desirable. But even if it is, I don't see the difference. Just have teams own their directories within the monorepo. If you…
> This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, ...
Even a forest of repos has tooling issues: your build, code review, and code indexing tools will need to support the forest, and that's a lot of work. It's probably comparable to the work needed to make a monorepo work.
The alternative to the monorepo isn't all rosy.
They made a bad design decision 10 years ago, have been fighting the fallout for years, and will be doing so forever and ever because things will only ever grow. They wrote a blog post on how clever they think all their workarounds are, at least one of which involves sparse-checkout -- which is perilously close to chopping up your monorepo into several, while still pretending monorepo is fine. I feel like somebody's…
Earlier quoted context omitted.
Ugh The price of letting less experienced people "go crazy" in the repo
Npm didn't support lockfiles until version 5, released in 2017, Yarn had them at launch in 2016. Before that committing node_modules was often used as a form of vendoring, to get reproducible builds. If a new project these days commits node_modules to git, it's likely a mistake, but for legacy projects started before 2017 it was the lesser of two evils. Edit: spelling.
Earlier quoted context omitted.
People point this out often, but in practice I have never seen this cause issues. Remove callers first, then remove endpoint... its pretty obvious the order in which things need to be done. What I have seen as a real problem, time and time again, is having trouble locating all usages of an API in a multi-repo scenario. Anyone who fucks this up in a monoreppo will probably fuck it up worse with multiple repos.
I think the tricky issue is updating the structure or semantics of an existent call across services. A monorepo makes it easy to make these kinds of changes in code, while making it non-obvious that it is dangerous to deploy; it is a giant foot-gun. Examples along this line include updating the name of an RPC, or endpoint, or changing the request/response structure, and so on. Of course you could argue that "you just…
We have escape hatches, which I mainly use when deleting code.
Earlier quoted context omitted.
Right, it's "I have to send 5 PRs to 5 different repos, get them all cross merged, and then at the end it's wrong anyways so I have to start all over". Multirepo management is extremely frustrating compared to "it's all in the same folder".
But in the monorepo you almost never can do the change in a single commit as it will cause incompatibilities during gradual deployment
Pretty interesting.... I don't know that much about git, but still fun to read. I guess the main takeaway is don't put all your eggs in one basket? Although it kinda seems like they are going to stick with the monorepo, ("Here’s how we solve them at Canva") Also, I looked up .xlf files and I still don't understand. It's xml, that part makes sense, but it's basically a config file? To tell what process to read which f…
.xlf isn't a config file format here. It refers to XLIFF, a standard for translation files. https://en.wikipedia.org/wiki/XLIFF
The comments in this thread from the devs have been informative as well.
Earlier quoted context omitted.
Right, it's "I have to send 5 PRs to 5 different repos, get them all cross merged, and then at the end it's wrong anyways so I have to start all over". Multirepo management is extremely frustrating compared to "it's all in the same folder".
Monorepo is not necessarily synced deployment, and even if it was, each deployment of a single component is usually racy with itself (as long as you're deploying to at least two nodes). Which means that you've got to do independent backwards-compatible changes anyway, and that for anything remotely complex, you are better off with separate branches (and PR/MRs) anyway. Monorepos mostly have a benefit for trivial chan…
Sometimes you have to ship a feature. Shipping that requires changing 3 parts of your app. A lot of times that _entire_ set of changes is less than 100 lines of code.
Having a full vision of what is being accomplished across your system in one go is very helpful for reviewing code! It justifies the need for changes, makes it easier to propose alternatives, and makes the go/no-go operation much more straightforward.
At a smaller scale, you often see the idea of splitting frontend and backend into separate repos. Of course you can ship an API and then ship the changes to the frontend. But for a lot of trivial stuff, just having both lets you actually see API usage in practice.
I think this is much more applicable for companies under 100 people though. When you get super large you're going to put into place a superstructure that will cause these splits anyways.