Context
Today the Resolver inherits the parent's Scope (group/host/env) onto every transitive declaration as one unit. That is the right default for the current shallow walks (ficsit mod requires ficsit mod), but it is an unexamined choice, not a designed one.
Ecosystem prior art disagrees with itself:
- Cargo/Bundler: dependency kinds (dev/test) do not propagate — your dep's dev-deps are not your deps. Scope collapses at the first edge.
- npm: devDependencies of a dependency are not installed, but the top-level scope does gate the whole subtree it introduced.
- Bazel: visibility/configuration propagates explicitly per edge.
Questions to answer when real transitivity lands:
- Does
group propagate (our current behavior) or collapse to the declaring project's group at the first edge?
- Does a host/env-gated parent gate its whole subtree, and what happens on diamond edges reached from two different scopes (today: first-wins via the resolved-set key, silently)?
- Should a transitive edge be allowed to narrow scope (platform-specific sub-deps)?
Acceptance
- A documented stance in docs/deps-architecture.md (transitive regimes section)
- Resolver behavior matches the stance, with tests for the diamond-two-scopes case
Context
Today the Resolver inherits the parent's
Scope(group/host/env) onto every transitive declaration as one unit. That is the right default for the current shallow walks (ficsit mod requires ficsit mod), but it is an unexamined choice, not a designed one.Ecosystem prior art disagrees with itself:
Questions to answer when real transitivity lands:
grouppropagate (our current behavior) or collapse to the declaring project's group at the first edge?Acceptance