pnpm ls only lists top-level dependencies by default but it should list all subdependencies as well #11162

[starkipraggy]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Issue version of [this]:(https://github.com/orgs/pnpm/discussions/11162#)
The docs say (emphasis mine):

This command will output all the versions of packages that are installed, as well as their dependencies, in a tree-structure.

But it doesn't actually do that unless you specify --depth=Infinity.
I use pnpm ls like npm ls expecting that the command will list all subdependencies. This is especially important in situations where you are looking for whether you have a specific package in your subdependencies for security checks. (pnpm audit isn't updated fast enough for situations like the recent axios debacle)

I understand that bigger repositories might have performance problems with having all dependencies recursively listed by default.
My stance is the big repository usecase should be the one where you have to specify --depth because it's different for everyone.
The failure case for performance problems is to simply Ctrl-C or at the very worst, turn the machine on and off again.
The failure case for not showing subdependencies when they're trusted to be shown is a security breach.

I accept that pnpm ls may in fact be the wrong tool for the job. However the expectation is that pnpm ls behaves like npm ls or even yarn list and creates a greppable package tree. In that case pnpm ls docs should point users to pnpm why for the purpose of finding if a package exists in the dependency tree.

Describe the solution you'd like

Update pnpm ls docs to point to pnpm why for the purpose of finding if a package exists in the dependency tree.

Describe the drawbacks of your solution

Requires reading comprehension on behalf of the user The core problem is retraining developers to not use <npm equivalent> ls and instinctively reach for pnpm why which this issue does not fundamentally solve (at least not immediately)

Describe alternatives you've considered

Make pnpm ls = pnpm ls --depth=Infinity by default.

• May break existing users workflows
• add to the problem where the package listing commands are not well-defined and step on each others toes (why use why when you have ls?)

[Mishra-coder]

Hi! I’d like to work on this issue. Could you please assign it to me? I’ll make sure to follow the contribution guidelines. Thanks!

[starkipraggy]

Don't think I have the authority, and also I think it's a good idea to wait for a maintainer to confirm this as work to be done.

[zkochan]

In the linked in discussion you already got an answer that with pnpm you can use pnpm why for this.

[starkipraggy]

Yes, but it's not obvious at all in the docs or manpage that npm why is the intended command for this. Users shouldn't have to find an obscure discussion thread for this, it should be front and center on the docs page.

As an aside, using npm why to perform the task of "do I have this package in my dependencies" doesn't make sense syntatically at all 😢

[starkipraggy]

Pinging because this is exactly what we need for the current tanstack mini-Shai-Hulud situation.

[robations]

My notes on confusion with this:

The help information (pnpm list -h) doesn't document the depth default as far as I can tell, and there's a mismatch between the description and behaviour:

When run as ll or la, it shows extended information by default. All dependencies are printed by default.

Me: "great, it lists everything"

Granted some ambiguity in "all dependencies" vs "all direct dependencies not including sub-dependencies" or "all dependencies including sub-dependencies".

But I agree with @starkipraggy on the semantics of list vs why. Vulnerability checking was my reason for digging into the exact behaviour.