Skip to content

feat(generate): target the shared {app}_ui package as canonical home for shared widgets#3

Open
lapc506 wants to merge 1 commit into
mainfrom
feat/generate-shared-ui-package
Open

feat(generate): target the shared {app}_ui package as canonical home for shared widgets#3
lapc506 wants to merge 1 commit into
mainfrom
feat/generate-shared-ui-package

Conversation

@lapc506

@lapc506 lapc506 commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

⚠️ MERGE-CONFLICT WARNING — UNCOMMITTED LOCAL WIP ON THIS SAME FILE ⚠️

The repo owner has large uncommitted WIP on commands/generate.md in the local working tree (~186 insertions / 35 deletions) that restructures the command into stack-detection + a Flutter Path (Steps F4–F6) and a Vite Path (Steps V4–V7). This PR is a surgical change against committed main, so reconciliation is required when that WIP lands:

  • This PR rewrites main's Step 4 (widget file targets) and Step 5 (Widgetbook entries), and adds one anti-pattern bullet.
  • In the WIP those sections became Step F4 / Step F5 and Flutter Anti-Patterns inside the Flutter Path. Porting = move this PR's Step 4/5 content into F4/F5 verbatim; the Vite Path is untouched by this decision.

What

Codifies the user's architecture decision for the five Flutter monorepos (keiko, altrupets, vertivo, aduanext, habitanexus): the canonical approach is a shared packages/{app}_ui package (e.g. keiko_ui, altrupets_ui), with the app and apps/widgetbook as consumers via path dependencies.

Semantics change in /generate

Before After
Shared widgets → core/widgets/{atoms|molecules|organisms}/ (inside the app) Shared widgets → {app}_ui/lib/src/{atoms|molecules|organisms}/, re-exported from the package barrel
No UI-package awareness Detects packages/*_ui / libs/*_ui; no package → offers to scaffold one by default; legacy in-app layout only as explicit fallback, flagged in the summary
Widgetbook entry *.widgetbook.dart alongside the widget apps/widgetbook catalog present → use case generated at apps/widgetbook/lib/use_cases/{level}/ importing from the UI package (aligns with /widgetbook-setup); colocated file only when no catalog exists

Feature widgets (templates/pages) stay in the app — they bind state and routes.

New anti-pattern: Never generate a shared widget into the app when a shared UI package exists — the package is the canonical home; the app and the widgetbook are consumers.

Coherence

/widgetbook-setup and references/widgetbook-flutter-monorepo.md (merged in #2) already mandate "depend on the UI package, never the app" at catalog level — this PR makes /generate produce that structure by default instead of merely auditing for it.

Scope

  • One file: commands/generate.md (+14/−3). No other WIP files touched (plugin.json, marketplace.json, README.md, audit.md untouched; version bump left to the owner).

🤖 Generated with Claude Code

…ome for shared widgets

Architecture decision: in the apps/* + packages/* monorepo layout, shared
widgets (atoms/molecules/organisms) are generated into packages/{app}_ui
(or libs/{app}_ui), with the app and the apps/widgetbook catalog as
consumers via path dependencies. When no UI package exists, /generate
offers to scaffold one by default; the legacy in-app core/widgets/ layout
becomes the explicit fallback. Widgetbook entries go to the apps/widgetbook
catalog when present, aligning /generate with /widgetbook-setup, which
already mandates depending on the UI package, never the app.

Co-Authored-By: Claude (Fable) <noreply@anthropic.com>

@dojo-code-reviewer dojo-code-reviewer Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Approved

Approved — no findings. Confidence: 5.00/5.00.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant