Template

Files

Danijel Martinek f77e6ea881 chore(template): clean-slate template snapshot from bb4a0c7

Curated, product-agnostic snapshot of the post-story-04 tree: demo
content deleted, auth-only reference feature, web-next shell, all gates
green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor
library traces, and product naming are curated out; generic template
repairs (coverage provider devDeps, root test:coverage script, live
lint fixes, root-only release-please) are kept. See TEMPLATE.md for
provenance, curation list, and usage.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK

2026-07-12 20:40:54 +02:00

1.3 KiB

Raw Blame History

ADR-007: Drop the Dual-Mode CMS Client Wrapper

Status: Accepted Date: 2026-05-04

Context

ADR-004 introduced @repo/cms-client as a standalone wrapper supporting both Local API and HTTP modes. It was never used in production after Payload 3.x solidified its Local API as the primary pattern.

Decision

Delete the wrapper. Feature payload-backed repositories call getPayload({ config }) directly. The config is injected via constructor, avoiding hard coupling to @repo/cms-core at import time.

Example:

export class PayloadArticlesRepository implements IArticlesRepository {
  constructor(private config: Config) {}

  async getById(id: string) {
    const payload = await getPayload({ config: this.config });
    return payload.findByID({ collection: "articles", id });
  }
}

Consequences

One fewer abstraction layer — repositories work directly with Payload's typed API
No "modes" — always use Local API from server code
Package graph stays acyclic: feature packages never import @repo/cms-client
apps/cms can directly boot Payload with the assembled config

Alternatives Considered

Keep the wrapper for "future-proofing": Payload 3.x is stable; wrapper was never activated in practice
Add HTTP mode later if needed: Simple to implement when actually required

1.3 KiB Raw Blame History