2 ms·
Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace
by derefr 5y ago
Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo.
These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?
- chiefalchemist 5y agoI've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.
- justaguy88 5y agoGit submodules have an annoying attribute: double commit First you commit/push to one repository Then you update the submodule pointer in the parent repository
- zerkten 5y ago>> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.