36 lines
1.3 KiB
Markdown
36 lines
1.3 KiB
Markdown
# ADR-003: CMS Core + CMS Client Separation
|
|
|
|
## Status: Accepted
|
|
|
|
## Context
|
|
|
|
Payload CMS needs to integrate with clean architecture without creating circular dependencies.
|
|
|
|
## Decision
|
|
|
|
Three packages: `@repo/cms-core` (config + collections), `@repo/cms-client` (standalone typed client), `apps/cms` (thin shell).
|
|
|
|
## Rationale
|
|
|
|
- `cms-core` is testable independently — collections are just config objects
|
|
- `cms-client` is standalone (no internal imports) — prevents circular deps
|
|
- `apps/cms` is almost empty — just boots Next.js with cms-core's config
|
|
- Payload instance injected into cms-client, not imported — app startup code wires them
|
|
|
|
## Circular Dependency Prevention
|
|
|
|
```
|
|
apps/cms → @repo/cms-core → @repo/core/application (hooks)
|
|
@repo/core/infrastructure → @repo/cms-client (standalone)
|
|
```
|
|
|
|
No cycles because cms-client never imports from cms-core or core.
|
|
|
|
## Status: Partially superseded by v2 (2026-05-04)
|
|
|
|
v1 advocated `@repo/cms-core` as a single CMS package. v2 splits this into:
|
|
- `@repo/core-cms` — composition only (assembles feature CMS schemas)
|
|
- Each feature owns its own collections/globals under `packages/<feature>/src/integrations/cms/`
|
|
|
|
Rationale: vertical-feature ownership scales better; CMS schema lives with the business code that needs it. See ADR-006.
|