ehoandClaude Sonnet 5
7b6cabfc4a
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>
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
# 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
|
|
|
|
- [x] `npm run gen:context <name>` produces a context that lints clean (boundaries recognised) and
|
|
routes lazily.
|
|
- [x] Boundary tool (WP-38) validates the new context's allowed edges.
|
|
- [x] `npm run ci` green.
|