The current evolution of the ModRepo is the "Collection." As mods became more complex, installing 200+ mods became a headache of version mismatches and crashes.
Platforms like Modrinth (for Minecraft) and Nexus Mods now offer "Collections" or "Packs." A veteran player curates a list of 100 mods, configures them perfectly, and uploads that list. A new player can download the entire list in one click, installing a completely overhauled game in minutes rather than days.
Create a MODREPO.md at the root of each repository explaining: modrepo
A modrepo is a repository management strategy that strikes a deliberate balance between a monorepo (one repository containing all code) and a multirepo (many repositories, each containing a single project or module). In a modrepo architecture, related modules that form a logical boundary—such as a microservice and its client libraries, or a plugin ecosystem—are stored together in a single repository, while unrelated systems remain in separate repositories.
Think of it as the "Goldilocks" approach: not too big, not too small, but just right. A modrepo typically contains: The current evolution of the ModRepo is the "Collection
Why choose modrepo over the competition? Here is a comparative analysis.
| Feature | Monorepo (e.g., Google’s Piper) | Multirepo (e.g., Standard GitHub) | Modrepo (The Hybrid) | | :--- | :--- | :--- | :--- | | Atomic Commits | Yes (single commit across projects) | No | Partial (via manifest updates) | | Scalability | Poor (1000+ developers causes Git performance hell) | Excellent | Excellent (modules are isolated) | | Code Reuse | Trivial (all code is local) | Difficult (requires publishing packages) | Moderate (via versioned modules) | | CI/CD Speed | Slow (must test everything or use complex hashing) | Fast (only test the changed repo) | Fast (only test changed modules + affected dependents) | | Disk Usage | Massive (entire history of everything) | Low | Low (clone only what you need) | | Tooling Complexity | Very high (needs custom build systems) | Low (standard tools per repo) | Medium (needs an orchestrator) | Create a MODREPO
The Verdict: If you are a startup with 5 developers, a monorepo works fine. If you are a giant like Google with custom version control, a monorepo works. For the other 99% of organizations—those with 10 to 1,000 developers working on interconnected services—modrepo is the optimal choice. It prevents the "repo hell" where every change requires touching 40 independent repositories, while also preventing the "build gridlock" of a lethargic monorepo.
To truly appreciate the modrepo, we must compare it to the two extremes:
| Feature | Monorepo | Modrepo | Multirepo | |---------|----------|-------------|-----------| | Scope | Entire company codebase | Single bounded context (e.g., team domain) | Per component/service | | Code sharing | Trivial (everything visible) | Controlled via internal packages | Requires package registry | | Build time | Often slow, requires caching | Fast, parallel by design | Usually fast but fragmented | | Access control | Coarse (folder-level) | Fine-grained (repo-level) | Perfect isolation | | Tooling complexity | High (Bazel, Nix, Turborepo) | Medium (standard tools suffice) | Low (but coordination is hard) | | Cross-repo changes | Atomic | Atomic within the modrepo | Requires multiple PRs |
The modrepo shines when your organization has clear domain boundaries but still needs coordinated development within those domains.