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

[starkipraggy]

Posting here as I am also looking for help to raise an issue. Is this a feature request or a bug?

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 current 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.

pnpm ls should be pnpm ls --depth=Infinity by default.

[andre-ribeiro-almeida-alb]

Check pnpm-why, I think it's closer to npm ls than pnpm ls is

[starkipraggy]

Thank you for pointing me to pnpm-why. Functionality-wise, it does cover my use-case. However,

1. pnpm is often advertised as a drop-in replacement for npm. I am not certain if pnpm actually aims to be a drop-in placement, but if it does then pnpm ls deviating from npm ls is a bug. -> bug report
2. pnpm ls may be meant for a different use-case. 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. -> feature/docs request