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)