Problem
Each feature declares dependsOn/installsAfter relationships inside its own devcontainer-feature.json, but there's no single place to see the resulting graph across all 9 features. Today, common-utils is a foundation depended on (directly or transitively) by most other features:
common-utils (foundation)
└─ gitutils, gitversion, act, pecl, gateway, minikube
└─ githooks (depends on gitutils)
└─ larasets (depends on common-utils, docker-in-docker)
Without a visible graph, a contributor changing common-utils (or any shared dependency) has to manually trace every feature's manifest to understand the blast radius — which is part of why version-sync mistakes happen (see the separate version-sync issue).
Proposal
- Add a generated dependency graph (e.g. a small script that parses every
src/*/devcontainer-feature.json dependsOn/installsAfter and emits a Mermaid diagram or DOT graph) checked into the repo or rendered in the README.
- Regenerate it in CI (or as a pre-commit step) so it can't silently go stale as features are added/changed.
Where this lives / sync note
This is a root-level documentation/tooling addition (reads from all src/*/devcontainer-feature.json but doesn't modify feature source), so it doesn't need special handling for the split-repo sync — it's monorepo-only tooling.
Acceptance criteria
Problem
Each feature declares
dependsOn/installsAfterrelationships inside its owndevcontainer-feature.json, but there's no single place to see the resulting graph across all 9 features. Today,common-utilsis a foundation depended on (directly or transitively) by most other features:Without a visible graph, a contributor changing
common-utils(or any shared dependency) has to manually trace every feature's manifest to understand the blast radius — which is part of why version-sync mistakes happen (see the separate version-sync issue).Proposal
src/*/devcontainer-feature.jsondependsOn/installsAfterand emits a Mermaid diagram or DOT graph) checked into the repo or rendered in the README.Where this lives / sync note
This is a root-level documentation/tooling addition (reads from all
src/*/devcontainer-feature.jsonbut doesn't modify feature source), so it doesn't need special handling for the split-repo sync — it's monorepo-only tooling.Acceptance criteria