Yarn: Yarn ls <pkg> not providing dep tree

[SimenB]

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

$ yarn ls package-json
yarn ls v0.17.0
├─ [email protected]
│  └─ [email protected]
└─ [email protected]
✨  Done in 0.42s.

If the current behavior is a bug, please provide the steps to reproduce.
yarn add del-cli nodemon && yarn ls package-json

What is the expected behavior?
To match npm behavior, and actually print where the dep comes from

$ npm ls package-json
[email protected] /Users/simbekkh/repos/frontpage
├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]
└─┬ [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └── [email protected]

Please mention your node.js, yarn and operating system version.
Node 6.9.1, Yarn 0.17.0, macOS Sierra

[SimenB]

As a bonus, what I was really interested in was why I had package-json@1, but yarn doesn't seem to support version in the ls command

$ yarn ls package-json@1
yarn ls v0.17.0
✨  Done in 0.40s.

Again, npm does

$ npm ls package-json@1
[email protected] /Users/simbekkh/repos/frontpage
└─┬ [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └── [email protected]

[olingern]

@bestander @wyze I became well acquainted with the ls command working on the tree output, I'd be interested in taking this one up, too.

[bestander]

@olingern, go for it.
cc me when PR is ready

[olingern]

@bestander
npm has an interesting set of rules around this, apparently.

If you do as @SimenB notes above, npm will show all _unique_ version of a package; however, if you install a package to be a "root" dependency, i.e. "yarn add [email protected]" that matches any child - you will loose all subsequent child listings of that package, only showing one dependency ( npm ls package-json ) .

I assume we should show all versions of a package no matter _where_ it lives in the project when running yarn ls <package name>

One other thing with the current yarn functionality - a package's specified version will appear in the tree as a dependency and on the root level as the _actual_ installed package. For example, below del@^2.2.0 and the installed version on the root of the tree: [email protected]

[olingern]

One other thought is that, the current structure of ls throws all of the root packages into a hash and then goes and searches for children. This is fast, but it causes a couple of problems we're seeing.

Another approach would be to iterate through all root dependencies and children to create a tree and track all existing listed dependencies via a hash ( super similar to current approach ). My idea would differ in that, when a hashed dependency is encountered that exists in the hash- it attempts to recursively / iteratively continue adding to that dependency tree.

The concerns I have with this are:

• somewhat large rewrite
• default depth of tree / restricting output level
• What is there currently _works_ for the most part. It's just a little ambiguous

[SimenB]

I assume we should show all versions of a package no matter where it lives in the project when running yarn ls <package name>

Yes please!

[SimenB]

@olingern Any news? 😄 Using npm ls still works fine a on a yarn install, so no huge issue, but it's still annoying

[olingern]

@SimenB Hey, the past couple of weeks I've been 'adulting' (holidays, interviews, etc.). I should be able to wrap this up over the next week :)

[SimenB]

@olingern sup? 😀

[SimenB]

npm has updated its output to say what stuff is deduped, looks pretty good

$ yarn list object-assign
yarn list v0.22.0
├─ [email protected]
└─ [email protected]
│  └─ [email protected]
✨  Done in 0.66s.

$ npm ls object-assign
[email protected] /Users/simbekkh/repos/mfinn
├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]  deduped
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]  deduped
│ └── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]  deduped
│ ├─┬ [email protected]
│ │ └── [email protected]  deduped
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]  deduped
├─┬ [email protected]
│ └─┬ [email protected]
│   └── [email protected]  deduped
├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]  deduped
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └─┬ [email protected]
│ │     └─┬ [email protected]
│ │       └─┬ [email protected]
│ │         └── [email protected]
│ └─┬ [email protected]
│   └── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]  deduped
│ └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected]  deduped
├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected]  deduped
├─┬ [email protected]
│ └─┬ [email protected]
│   ├─┬ [email protected]
│   │ └── [email protected]  deduped
│   └── [email protected]  deduped
└─┬ [email protected]
  └─┬ [email protected]
    └── [email protected]  deduped

[olingern]

@SimenB That is super clean, but I'm not a huge fan of "deduped" being placed alongside the package. It creates a lot of noise in the output and a little more difficult to visually parse

[SimenB]

It's dimmed out in the terminal, so no real issue in practice to read it 😄

[olingern]

Looked at this tonight. A couple of problems. The main one being that yarn flattens the dep tree for output.

This may be a different command or need a flag to invoke the npm style tree output structure, as I see building the dependency tree for this to be somewhat different than what yarn list currently does

[shaodahong]

any news?