Modrepo

"name": "@mycompany/billing-modrepo", "workspaces": ["packages/*", "services/*"]

| Feature | Monorepo | | 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 | modrepo

# .github/workflows/ci.yml on: [push] jobs: test-changed-modules: runs-on: ubuntu-latest steps: - uses: dorny/paths-filter@v3 id: filter with: filters: | invoice-service: - 'services/invoice-service/**' billing-models: - 'packages/billing-models/**' - name: Test Invoice Service if: steps.filter.outputs.invoice-service == 'true' run: cd services/invoice-service && npm test Decide on versioning independent or unified. Then automate publishing. For independent versioning using Changesets: When a module becomes too independent or stable,

: Define strict size limits. When a module becomes too independent or stable, spin it off into its own modrepo. Pitfall 2: Circular Dependencies Across Modrepos If modrepo A depends on a package from modrepo B , and modrepo B also depends on a package from modrepo A , you’ve created a cycle that forces simultaneous releases—defeating the purpose of modularity. requires caching | Fast