platform-main — module dependency graph

13 modules, 3 real dependency tiers — read from every peerDependencies field, not guessed.

Every module was ported in dependency order, tier by tier, because getting the order wrong breaks the build: a module can't compile against an @ngrx/* peer dependency that hasn't been added to the workspace yet. The tiers below are exactly what yarn nx graph and each module's own package.json say — verified again while building this diagram, not carried over from an old note.

Dependency Diagram

Tier 0 — no @ngrx/store, effects or entity peer dependency store operators component-store signals component eslint-plugin
↑ peer-depends on @ngrx/store
Tier 1 — depends on store entity effects router-store store-devtools
↑ peer-depends on store + effects + entity
Tier 2 — depends on store, effects, and entity together data
Cross-cutting infra — outside the tiers: schematics-core via relative import, schematics as a peer of every module schematics-core schematics

What Each Tier Actually Is

6 modules

Tier 0 — standalone

  • Only peer-depend on @angular/core/rxjs (plus @ngrx/schematics, like every module — see the note below)
  • Ported first — nothing else in the workspace has to exist yet
  • component-store/signals/component were the first modules built "the corrected way" — ng-add went straight into the shared schematics package, no per-module copy to migrate later
4 modules

Tier 1 — single dependency on store

  • Each declares @ngrx/store as a peer dependency
  • Every one of these surfaced the same "composition-redesign ripple" — a consumer relying on Store/ActionsSubject's old inherited RxJS surface, caught by the build, not by inspection
  • Reviewed in the code-review audit right after store, while the bug pattern was still fresh context
1 module

Tier 2 — the only 3-way dependency

  • data is the single module needing store + effects + entity at once
  • Added last among the functional modules, once all three of its dependencies existed and were stable
  • Surfaced the same ripple bug a third time, in a third shape — ScannedActionsSubject mistyped as a plain Observable
Why schematics-core/schematics aren't in the tier graph: neither declares an @ngrx/* peer dependency — schematics-core is pulled in via a relative import every module's ng-add schematic needs (consolidated from 4 duplicated copies into one, −12,453 lines), and schematics is the single package holding every module's actual ng-add implementation — each module's own package.json once again resolves its own real ng add @ngrx/<name> too, via a thin wrapper delegating to that shared implementation rather than a second copy of it. That wrapper is why all 11 other modules list @ngrx/schematics as a peer dependency (added in #283–#298); the edge is the same for every module, so it doesn't change the tiers. Both still get their own full code-review pass under the same 13-module audit (schematics-core is issue #34) — they're infrastructure, not exceptions to the review scope.