My company uses a polyrepo setup. Each in-house project/library has its own repository.
However, we handle the external dependencies issue by having a single dedicated repository housing (most) of our third-party library dependencies — the statically linked ones, anyway.
This ensures the team (and the CI!) is always building against the same dependency versions. It also allows fixes to be pushed company-wide, whether it comes from the third-party library's maintainer or from us. Our default build systems and scripts look for this repository in a predictable relative location, but it is trivial to override it for any individual dependency. That way, if someone needs to pull in or use a different version of one library, they can do so.
The result is that builds are smooth as butter. :)
One might wonder why we wouldn't have a repository for each individual third-party dependency, but it works for the exact same reasons large corporations benefit from a monorepo, chief of which being simplicity. Each of those libraries are small, and a developer usually needs most or all of them. If one third-party library gets unruly, it's simple to move it out into its own repository. The team addresses that on a case-by-case basis.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My company uses a polyrepo setup. Each in-house project/library has its own repository.
However, we handle the external dependencies issue by having a single dedicated repository housing (most) of our third-party library dependencies — the statically linked ones, anyway.
This ensures the team (and the CI!) is always building against the same dependency versions. It also allows fixes to be pushed company-wide, whether it comes from the third-party library's maintainer or from us. Our default build systems and scripts look for this repository in a predictable relative location, but it is trivial to override it for any individual dependency. That way, if someone needs to pull in or use a different version of one library, they can do so.
The result is that builds are smooth as butter. :)
One might wonder why we wouldn't have a repository for each individual third-party dependency, but it works for the exact same reasons large corporations benefit from a monorepo, chief of which being simplicity. Each of those libraries are small, and a developer usually needs most or all of them. If one third-party library gets unruly, it's simple to move it out into its own repository. The team addresses that on a case-by-case basis.