cli commands/why

11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

deno why command basic usage

The deno 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 regardless of which node_modules / npm resolver mode you use and without touching the network.

deno why command syntax

The syntax for deno why is: deno why <package>, where <package> is an npm or JSR package name, optionally pinned with @<version>.

deno why package name forms

deno why accepts the following package name forms: 'ms' for every version of ms in the tree, 'ms@2.0.0' for only the 2.0.0 version, '@std/path' for a JSR package by its bare name, 'jsr:@std/path' for a JSR package by its full specifier, and 'npm:express' to force npm lookup (useful when names collide).

deno why exit codes

Exit code 0 means the package was found in the resolved tree and at least one dependency path was printed. Non-zero exit code means the package is not in the resolved tree, or the argument is malformed.

deno why example with multiple paths

Example output when a package appears at multiple versions: ``` $ deno why ms ms@2.0.0 npm:express@^4.18.0 > debug@2.6.9 > ms@2.0.0 npm:express@^4.18.0 > body-parser@1.20.4 > debug@2.6.9 > ms@2.0.0 npm:express@^4.18.0 > finalhandler@1.3.2 > debug@2.6.9 > ms@2.0.0 ms@2.1.3 npm:express@^4.18.0 > send@0.19.2 > ms@2.1.3 ``` When the same package appears at multiple versions, each is shown in its own block.

deno why example with pinned version

Example output when pinned to a single version: ``` $ deno why ms@2.1.3 ms@2.1.3 npm:express@^4.18.0 > send@0.19.2 > ms@2.1.3 ```

deno why example with JSR packages

Example output for JSR packages: ``` $ deno why @std/path @std/path@1.0.6 @scope/my-lib@^1.0.0 > @std/path@1.0.6 @std/fs@^1.0.16 > @std/path@1.0.6 ``` JSR packages added in Deno 2.8+ resolve the same way npm packages do — you can pass either the bare name (@std/path) or the full specifier (jsr:@std/path).

deno why workspace behavior

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.

deno why pitfall: package not in lockfile

If deno why reports 'Package not found' but you know it's used at runtime, it means deno why reports what's in the lockfile, not what's imported by your code. If you've added a npm: or jsr: specifier but haven't run deno install (or any subcommand that resolves), the package won't appear yet.

deno why pitfall: workspace lockfile resolution

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 deno why from the workspace root for the complete picture.

deno why CI usage example

deno why can be used to gate CI on a package not being pulled in. For example, to assert that left-pad never enters your tree, use: ! deno why left-pad (the command fails the build if left-pad is reachable).

Give your agent this brain