Skip to content

ADR-009: Support TypeScript/React-Frontend as the Generator's First Frontend Profile

Field Value
Date 2026-07-21
Status Accepted
Deciders Holger Zahnleiter
Supersedes —
Superseded by —

Context and Problem Statement

This generator only ever produced backend artifacts (CLI tools, libraries, services) for C++, Go, and Java. A web UI has different concerns entirely — a browser runtime, no server process for a static SPA, a different test pyramid (component tests, browser-driven E2E), and a different packaging story (static assets, not a binary or JAR). Should the generator add a frontend/web-UI project type at all, and if so, what language/framework/project-type shape should it take?

Decision Drivers

  • The capability-based registry (ADR-007-identity_vs_capability_based_generation.md) was explicitly designed so a new (Language, ProjectType) axis costs only new profile rows and capability actions — this is the first real test of that claim for an axis that isn't just "another backend language."
  • Avoid inventing a generic "frontend" abstraction before a second frontend type exists (YAGNI, per specs/guidelines/refactoring.md).
  • Reuse existing generic capabilities (guidelines, universal ADRs, Claude assets) wherever the concept is genuinely language/type-agnostic, rather than duplicating them.

Considered Options

  1. Do not support frontend project types — stay backend-only.
  2. Add a generic PROJECT_TYPE_FRONTEND now, anticipating future frameworks (Vue, Svelte, ...).
  3. Add one concrete LANGUAGE_TYPESCRIPT / PROJECT_TYPE_REACT_FRONTEND profile, matching the CLI naming a requester would actually type, and generalize later only if a second frontend type is actually requested.

Decision Outcome

Chosen option: Option 3. A concrete react-frontend profile, not a premature "frontend" abstraction. This mirrors how every other project type in this generator is concrete (cli_tool, library, service — never an abstract "backend" type), and the registry's own design already makes a second, later frontend type cheap to add (new profile row + capability actions) without touching registry.go or generator.go.

Positive Consequences

  • Proves the capability registry's core claim — a structurally different axis value (no server process, browser runtime, different test pyramid) required zero changes to Registry, generator.go, or any other language's package.
  • Reuses ui_architecture.md (already framework-agnostic, Presentation Model/View Model/View) and the universal ADRs/guidelines unmodified.
  • Keeps the door open for a second frontend project type without committing to an abstraction shape that might not fit whatever that type turns out to need.

Negative Consequences / Risks

  • If a second frontend type is added later, some guideline/ADR content currently registered react-frontend-specific may need to move to a shared, project-type-agnostic capability — accepted as the normal cost of generalizing from one real example rather than a guess.

Pros and Cons of the Options

Option 1 — Backend-only

  • Pro: No new scope.
  • Con: Leaves a real, common need (a web UI companion to a generated service) unaddressed.

Option 2 — Generic PROJECT_TYPE_FRONTEND now

  • Pro: Would not need renaming if a second frontend type appears.
  • Con: Speculative generality with only one concrete example to generalize from — exactly the premature abstraction refactoring.md warns against.

Option 3 — Concrete react-frontend profile (chosen)

  • Pro: Matches this generator's existing concrete-project-type convention.
  • Pro: Registry design already makes generalizing later cheap, if and when needed.
  • Con: A future rename/generalization step is possible, not free — accepted.
  • ADR-007-identity_vs_capability_based_generation.md — the registry design this decision exercises for the first non-backend axis value
  • internal/templating/typescript/capabilities.go — the resulting profile implementation
  • .claude/skills/new-project-type/SKILL.md — the mechanical procedure this profile followed