Files

T

ehoandClaude Sonnet 5 7b6cabfc4a feat(dx): gen:context generator (WP-44)

npm run gen:context scaffolds a bounded context: folders + starter page, the @<ctx>/*
tsconfig alias, a dependency-cruiser boundary entry, and a lazy authGuard route.

Refactors .dependency-cruiser.js's per-context contextRule calls into a single
CONTEXT_ALLOWED map that every rule derives from, so adding a context is really one
config entry (verified behavior-preserving: same dep:check counts, same graph output).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-27 14:18:43 +02:00

2.7 KiB

Raw Blame History

WP-44 — `gen:context` generator

Status: done Phase: 8 — platform/DX/showcase Priority: P3 Depends on: WP-38, WP-43

Outcome

npm run gen:context (plop, extends WP-43's plopfile.mjs) prompts for a lowercase context name and emits: src/app/<ctx>/{domain,application,infrastructure,contracts}/.gitkeep + a starter ui/<ctx>.page.ts (a PageShellComponent wrapper — replace with the real first feature slice); the @<ctx>/* tsconfig alias; one new key in .dependency-cruiser.js's CONTEXT_ALLOWED map; and a lazy, authGuard-gated route in app.routes.ts inserted before the catch-all.

Refactored .dependency-cruiser.js to make "one config entry" literally true. The pre-WP file hand-duplicated each context's forbidden-imports list as a separate contextRule(name, from, forbidden) call — adding a context meant editing N existing calls to add it to their forbidden list, not adding one entry. Replaced with a single CONTEXT_ALLOWED map (context → contexts it may additionally import) that every rule + the FEATURES string is derived from; showcase maps to null (unrestricted — the one exempt case) and is skipped when generating rules. Verified behavior-preserving: npm run dep:check reports the same module/dependency counts before and after, npm run dep:graph's committed output is byte-identical, and a planted cross-context violation (auth importing @herregistratie, type-only) is still caught under the new auth-scope rule name.

Smoke-tested by generating a real vergunning context end-to-end (dep:check, lint, build all green, including the new lazy chunk), then removed the demo output. .claude/skills/new-context/ SKILL.md now points at the generator as step 1.

Why

Adding a bounded context is currently a manual multi-file edit (folders + tsconfig alias + copied ESLint boundary block + lazy route) — the new-context skill's most error-prone steps. Mechanise it.

Decisions

gen:context (same tool as WP-43) emits {domain,application,infrastructure,ui,contracts} folders + the @ctx/* tsconfig path alias + a lazy route + the boundary entry.
Simpler because of WP-38: boundaries are declarative by then, so the generator adds one config entry instead of hand-copying ESLint blocks.
Replaces the manual portion of the new-context skill.

Files

Extend the WP-43 generator setup with a context generator + templates.
Wire tsconfig alias + boundary config + route insertion (idempotent edits).
Update .claude/skills/new-context/SKILL.md.

Acceptance criteria

npm run gen:context <name> produces a context that lints clean (boundaries recognised) and routes lazily.
Boundary tool (WP-38) validates the new context's allowed edges.
npm run ci green.

2.7 KiB Raw Blame History

WP-44 — gen:context generator