ende why

The ende why command explains why a particular package is in your dependency tree by printing every path from your project's direct dependencies down to the queried package. It reads the lockfile, so it works without touching the network.

It pairs with ende add and ende remove: once you know why a transitive dependency is in your tree, you can decide whether to remove a direct dependency that's pulling it in.

Usage

ende why <package>

<package> is a JSR package name, optionally pinned with @<version>:

Examples

Multiple paths to a single package

$ ende why @ende/path
@ende/[email protected]
  jsr:@ende/fs@^2026.10.15 > @ende/[email protected]
  jsr:@ende/http@^2026.10.15 > @ende/[email protected]

When the same package appears at multiple versions, each is shown in its own block — handy for diagnosing duplicated dependencies.

Workspace members

In a workspace, each member's direct dependencies appear as roots in the output, so a transitive dep introduced by one package is clearly attributable to that package.

Exit codes

The non-zero exit is the easy way to gate CI on a package not being pulled in. For example, to assert that @acme/legacy never enters your tree:

# fails the build if @acme/legacy is reachable
! ende why @acme/legacy

Common pitfalls

• "Package not found" but you know it's used at runtime. ende why reports what's in the lockfile, not what's imported by your code. If you've added a jsr: specifier but haven't run ende install (or any subcommand that resolves), the package won't appear yet.
• Resolution depends on workspace mode. A package only consumed by one workspace member may not show up when run from a different member's directory if your workspace setup uses per-member lockfiles. Run ende why from the workspace root for the complete picture.

why