Does a monorepo where every service is built and deployed from HEAD violate the Reuse/Release Equivalence Principle (REP)? How should REP be applied when producers and consumers share one repository?

## Restating REP precisely **REP**: *the granule of reuse is the granule of release.* The intent is that reuse happens through a **defined, identifiable, communicated unit** — you can say exactly what you depend on, exactly which state of it, and you learn when that state changes. Version numbers in a package registry are the *usual* implementation of that intent, not the intent itself. ## Two coherent models **Model A — independently versioned artifacts (multirepo, or monorepo publishing packages).** Each component is built and published with its own semver line. Consumers pin versions and upgrade deliberately. - Consumers control timing; can stay on an old version. - Producers can change without immediately fixing every caller (breaking changes are shipped as MAJOR and migrated over time). - Costs: **version skew** (many consumers on many versions of you), **diamond conflicts** (two paths need incompatible versions of a shared dependency), backported fixes, long tail of stale consumers, and slow propagation of security fixes. **Model B — single-version monorepo built at HEAD.** All code lives in one repository; consumers depend on the component at HEAD; a commit is the unit of release. - The **commit SHA is the version** — a real, immutable identifier for the whole world. - Changes are **atomic**: a producer change and all consumer updates land in one commit, so there is no intermediate broken state, no skew, and no diamond problem (there is exactly one version of everything). - Fixes propagate instantly to everyone. - Costs: producers bear migration cost ("you break it, you fix it" across all call sites), CI must build/test the affected slice of a huge graph, large-scale refactoring tooling is mandatory, and *nobody can opt out* of a change — a bad change hits everyone at once. Model B does not abandon REP; it collapses many release granules into one global granule. The Google-style single-version policy is the canonical example. What it *does* abandon is per-component independent versioning — deliberately, in exchange for eliminating skew. ## When a monorepo genuinely violates REP The repository layout is not what matters; the **boundary and the process** are. Red flags: - **No declared public API.** Consumers import internal classes/files directly, so the producer cannot change anything safely and there is no surface to promise stability on. Fix: visibility rules, module/export declarations, enforced dependency rules (architecture tests, build-visibility lists, dependency-cruiser-style checks). - **No ownership.** Nobody is accountable for the shared code, so nobody can approve changes or run a migration. Fix: code-owner files and a component charter. - **No change communication.** Even with atomic commits, consumers need to learn about behaviour changes, deprecations and new capabilities. Fix: changelog per component, deprecation annotations with removal dates, announcements for behavioural changes. - **Ad-hoc reach-in reuse across team boundaries**, e.g. Team A's build compiles Team B's source directory with no declared dependency edge. This is a REP violation in *any* repo layout: reuse with no identified granule. ## Hybrid: monorepo that publishes Many organisations run a monorepo internally *and* publish some components externally. Then you get both models at once: internal consumers on HEAD, external consumers on semver artifacts. Consequences to plan for: - The **public API surface must be explicitly delimited** — what's covered by the compatibility promise versus internal (visible internally, unstable). - **Release cutting** becomes a separate act from committing: tag, build, publish, changelog. - You now support **old versions** for external consumers — backports and support windows — even though internal consumers never see them. - "Works at HEAD" is no longer proof for external consumers; you need compatibility testing against supported released versions. ## Applying REP's *contents* rule inside a monorepo Even at HEAD, the theme/cohesion argument survives in modified form. Without version churn, the pressure changes shape: - **Build and test blast radius** replaces version churn: a themeless mega-component means every change rebuilds and retests everything that touches it, and every consumer's CI is affected. - **Dependency footprint** still matters: depending on a fat target pulls its whole transitive closure into your binary/build. - **Ownership and review load** still argue for coherent, owned components. So you still split by theme and by consumer usage clusters (Common Reuse Principle) and by co-change (Common Closure Principle) — you just do it with build targets and visibility rules rather than published versions. ## Decision guide | Situation | Lean toward | |---|---| | All consumers inside one org, one repo, unified CI, strong refactoring tooling | Single-version HEAD (Model B) | | Consumers outside the org, or independent deployment schedules you don't control | Versioned artifacts (Model A) | | Regulated consumers needing pinned, auditable dependency versions | Versioned artifacts | | Many teams, weak CI capacity, cannot rebuild the world per change | Versioned artifacts, or monorepo publishing packages | | Both internal and external consumers | Hybrid, with an explicit public-API surface | ## Bottom line REP is not "use a package registry". It is: *reuse must go through a bounded, identified, owned, change-communicated unit.* A monorepo can satisfy that with commits, build targets and ownership rules; a multirepo can violate it with copy-paste and floating versions. Judge the process, not the folder structure.