Deno is so nice for infrastructure scripting in projects. I tried to convince my company to use it but apparently one `curl` line to install it was too much to ask so now I spend half my time fighting Python, setting up venvs, working around pip bugs, etc. Yeay.
Agreed... I use deno a lot for my ~/bin directory scripts, being able to rely on direct references and just run stuff, without the npm install step is just handy in practice. That node_modules doesn't work the same as well. There are things that are somewhat annoying in practice, but shell scripting with Deno has been beyond nice to say the least.
Not to mention the performance / async / memory usage benefits you would have gotten on Node/Deno (not to mention lower cloud bills). I do not know why teams doing this.
I'm currently working in a pnpm monorepo and it really seems like a potential double edged sword. On the one hand I have longed for better support for local packages in the ecosystem (which pnpm does provide, and I'm happy for it). But some weird edge cases seem to arise. Like serverless functions not being supported[1]. I suppose that's just a matter of feature maturity.
The more design-level hazard of this might be that it's easier to build monorepos where everything is tightly coupled. And you end up with something that is like a single package with extra abstraction layers.
It tries to solve it but doesn't seem to get all the way there. Symlinks are still very much present for example. But I'm still a bit confused what exactly is causing the azure function to fail so I can't say more.
In my last job, I tried using a monorepo approach, merging about 50 microservices into a single repository. After several months of growth, the size of the entire git repository reached over 100GB. We had to create monthly checkpoints (.tar.gz) to facilitate faster time traveling or quick cloning for new team members. This experience taught me that perhaps git is not the best tool for managing a monorepo.
With that much generation that im assuming changes regularly you almost want a seperate solution or to gitignore them and generate the files at build time...
What were you checking in? I've worked in monorepos with a lot of generated code (millions of lines) and 10 years of commits and the total repo size never went over a few gb.
That's billions of lines of code if it's just Golang. I would imagine most of that was autogenerated code that no one was reviewing. This is not a problem with monorepos.
How would that differ from having the 50 microservices cloned separately? Maybe you want to say that perhaps some of the microservices were not that useful and didn't need to be versioned as well? If that is the case I think you could benefit from Scalar [1]. Microsoft created it because of similar problems with size and binaries
> How would that differ from having the 50 microservices cloned separately?
Usually, not everyone needs every single microservice, so they only checkout the handful they need, instead of the full monster. And usually one will accumulate repos over time, instead of getting them all at once. Similar, you will also only pull updates for the repo necessary for your work today, instead of getting the full update the whole company creates every day.
Yes, Scalar would be helpful. The problem is that not every developer needs all the code in the repository for their daily work. However, Git makes it difficult to do partial checkouts.
There's some truth to this. I'd say that perhaps Git is unsuitable above certain thresholds on numbers of files, numbers of commits, and size of data, but, that the size of data (and the fact that for certain file types this gets blown out on edits) is probably the one most people hit first – it sounds like you may have.
I've heard of git monorepos with >1k microservices, and it sounded like it wasn't a huge problem, but I think it likely had significantly less than 100GB. In fact I feel like you need to be committing large binary files to get towards that size.
> I'd say that perhaps Git is unsuitable above certain thresholds on numbers of files
Scott Chacon in a recent talk about git[0] said that Microsoft uses git to version control Windows. They have ~3.5 million files in the repo, which is about 300 gigabytes in size. There are some tweaks to improve git performance in those scenarios; but still, I'd say it's a pretty impressive threshold.
I wonder how this works with things like dependency management; for example, Nx lets you build all affected projects when you change one dependency's files in a monorepo. Does this do something similar?
