Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
gronostaj204273dSymfony 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.
momad29573dI think they would be less common if git made submodules more explicit. It is a pain to explain them to every new contributor.
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
Marl3x259873dI 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.