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
├─ del-cli@0.2.0
│  └─ package-json@2.4.0
└─ package-json@1.2.0
✨  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
frontpage@1.0.0 /Users/simbekkh/repos/frontpage
├─┬ del-cli@0.2.0
│ └─┬ update-notifier@0.6.3
│   └─┬ latest-version@2.0.0
│     └── package-json@2.4.0
└─┬ nodemon@1.11.0
  └─┬ update-notifier@0.5.0
    └─┬ latest-version@1.0.1
      └── package-json@1.2.0

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
frontpage@1.0.0 /Users/simbekkh/repos/frontpage
└─┬ nodemon@1.11.0
  └─┬ update-notifier@0.5.0
    └─┬ latest-version@1.0.1
      └── package-json@1.2.0

[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 package-json@x.x.x" 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: del@2.2.2

[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
├─ object-assign@4.1.1
└─ socket.io@1.7.3
│  └─ object-assign@4.1.0
✨  Done in 0.66s.

$ npm ls object-assign
www.finn.no@0.0.0 /Users/simbekkh/repos/mfinn
├─┬ babel-jest@19.0.0
│ └─┬ babel-plugin-istanbul@4.0.0
│   └─┬ test-exclude@4.0.0
│     └── object-assign@4.1.1  deduped
├─┬ babel-loader@6.4.1
│ ├─┬ loader-utils@0.2.17
│ │ └── object-assign@4.1.1  deduped
│ └── object-assign@4.1.1
├─┬ eslint@3.19.0
│ ├─┬ escope@3.6.0
│ │ └─┬ esrecurse@4.1.0
│ │   └── object-assign@4.1.1  deduped
│ ├─┬ file-entry-cache@2.0.0
│ │ └── object-assign@4.1.1  deduped
│ └─┬ inquirer@0.12.0
│   └─┬ figures@1.7.0
│     └── object-assign@4.1.1  deduped
├─┬ eslint-plugin-react@6.10.3
│ └─┬ jsx-ast-utils@1.4.0
│   └── object-assign@4.1.1  deduped
├─┬ grunt@1.0.1
│ └─┬ dateformat@1.0.12
│   └─┬ meow@3.7.0
│     └── object-assign@4.1.1  deduped
├─┬ karma@1.6.0
│ ├─┬ chokidar@1.6.1
│ │ └─┬ fsevents@1.1.1
│ │   └─┬ node-pre-gyp@0.6.33
│ │     └─┬ npmlog@4.0.2
│ │       └─┬ gauge@2.7.3
│ │         └── object-assign@4.1.1
│ └─┬ socket.io@1.7.3
│   └── object-assign@4.1.0
├─┬ react@15.4.2
│ ├─┬ fbjs@0.8.9
│ │ └── object-assign@4.1.1  deduped
│ └── object-assign@4.1.1  deduped
├─┬ react-addons-css-transition-group@15.4.2
│ └── object-assign@4.1.1  deduped
├─┬ react-addons-test-utils@15.4.2
│ └── object-assign@4.1.1  deduped
├─┬ react-dom@15.4.2
│ └── object-assign@4.1.1  deduped
├─┬ react-router@3.0.2
│ └─┬ history@3.3.0
│   └─┬ query-string@4.3.2
│     └── object-assign@4.1.1  deduped
├─┬ react-test-renderer@15.4.2
│ └── object-assign@4.1.1  deduped
├─┬ recursive-copy@2.0.6
│ └─┬ del@2.2.2
│   ├─┬ globby@5.0.0
│   │ └── object-assign@4.1.1  deduped
│   └── object-assign@4.1.1  deduped
└─┬ webpack@2.3.3
  └─┬ enhanced-resolve@3.1.0
    └── object-assign@4.1.1  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?

[sachin-sundial]

any update on this ?