feature:impact

Show the full dependency impact of adding or removing a feature.

Table of contents

1. Usage
2. What it shows
3. Examples
   1. A core feature with many dependents
   2. A leaf feature safe to remove
   3. A feature with transitive dependencies
4. Direct vs transitive
5. Environment-aware
6. When to use it

---

Usage

splent feature:impact <feature>

Accepts a short name (auth) or full package name (splent_feature_auth).

---

What it shows

The command reads the product’s UVL constraints and builds a bidirectional dependency graph:

1. Depends on — features this one requires to work (direct and transitive)
2. Depended on by — features that would break if this one were removed (direct and transitive)
3. Summary — safe to remove, or how many features would be affected

---

Examples

A core feature with many dependents

splent feature:impact auth

  feature:impact — auth
  Product: my_first_app
  UVL:     sample_splent_spl.uvl

  Depends on
    (none) — this feature is independent

  Depended on by
    ← confirmemail  (direct)
    ← notes  (direct)
      ← notes_tags  (transitive)
    ← profile  (direct)
    ← reset  (direct)

  Removing auth would break 5 feature(s).

Auth has no dependencies of its own, but five features depend on it. Removing it would cascade.

A leaf feature safe to remove

splent feature:impact profile

  feature:impact — profile
  Product: my_first_app
  UVL:     sample_splent_spl.uvl

  Depends on
    → auth  (direct)

  Depended on by
    (none) — safe to remove

  Removing profile has no impact on other features.

Profile depends on auth but nothing depends on profile.

A feature with transitive dependencies

splent feature:impact notes_tags

  feature:impact — notes_tags
  Product: my_first_app
  UVL:     sample_splent_spl.uvl

  Depends on
      → auth  (transitive)
    → notes  (direct)

  Depended on by
    (none) — safe to remove

  Removing notes_tags has no impact on other features.

notes_tags directly depends on notes, which in turn depends on auth (transitive).

---

Direct vs transitive

• Direct: the dependency is declared explicitly in the UVL constraints (e.g., admin => auth)
• Transitive: the dependency is inherited through the graph (e.g., notes_tags => notes => auth makes auth a transitive dependency of notes_tags)

---

Environment-aware

The command reads SPLENT_ENV and includes features from features_dev or features_prod accordingly. A feature declared only in features_dev will appear in the graph when SPLENT_ENV=dev.

---

When to use it

• Before removing a feature: check if anything depends on it
• Before adding a feature: see what it will pull in as dependencies
• During product planning: understand the dependency structure of your configuration
• During SPL design: identify core features (many dependents) vs leaf features (safe to swap)