Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Symfony is using an interesting approach. They develop in a monorepo and have separate repos for each project that are automatically extracted from the monorepo.
As an end user you won't notice a difference, each project lives in a little repo of its own. As a developer as you said you can refactor easily and you know immediately how your changes affect other components.
Loose coupling is cool, but in practice stuff will always depend on other stuff. There are very few libraries that are useful on their own. -
Talking about Google?
I think if you have enough engineers that maintain such a system, it can work.
Also, for internal development you do not need a decentralized system, as you do not need forks or stuff like this.
Whether you have a single repository or multiple of them here is rather a semantic thing, which does not make a too huge difference (not talking about git here, but rather an arbitrary system)
If you would want to couple this with git, then yes, that would be a very bad idea, as git was never designed for this use case -
I use monorepos for all my projects. I'm using the same language for everything so making libraries out of everything just lets me easily resuse stuff.
Also because it makes it so easy to create new projects I pretty much always extract some more complex things into a seperate library which lets me reuse it easily in the future. Where in a normal project I would have to copy some folder/classes and integrate it anew.
So for my usecase it's really helpful and cool, but there are also ideas around that put this to the extreme.
TIL "monorepos" are a thing, where you just whack all your projects into one insanely large repo. And not just a niche thing either - used by some of the biggest tech companies.
I thought this was a code smell that everyone moved past when we abandoned subversion.
I understand the theoretical arguments around ensuring that everything can be compatible, can make large scale changes at once, etc. - but I don't really buy that in practice. Surely if you've got that many inter-dependencies going on that just points to the fact you've got crappy code with way too much internal coupling?!
Does anyone use this paradigm? To me it just sounds like, for the big companies, moving away from one huge repo was too much hassle. So they gave it a fancy new name and pretended it's the new "cool way to work" instead.
rant