Add name lookups to yarn ls

[lukeed]

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

Feature

What is the current behavior?

yarn ls takes no options or arguments.

What is the expected behavior?

NPM lets you list packages by name. Yarn can/should include this, but improve it 1 step further by matching name patterns (a la minimatch?).

This accompanies #726

# npm behavior
npm ls gulp
└── gulp@3.9.1

# yarn improvement
yarn ls gulp
└── gulp@3.9.1

yarn ls gulp*
└── gulp@3.9.1
└── gulp-rev@7.1.2
└── gulp-xo@0.14.0
└── etc...

[sebmck]

Created #1643 to fix this, pending approval.

[markstos]

I just tested this new commit, and it does not appear to be working correctly.

Before, the fix, if I tried yarn ls gulp, I would get an error that no arguments are expected. Now I no longer get that error, but yarn ls gulp returns exactly the same output as yarn gulp. Here you can see they return the same number of lines:

$ ./bin/yarn ls 2>&1 | wc -l
2415
$ ./bin/yarn ls gulp 2>&1 | wc -l
2415

[sebmck]

@markstos Fixed by 3d57f08.

[markstos]

I'm not seeing this issue as being fixed with the latest code-- this issue should be re-opened. The behavior I see is that yarn ls gulp returns the same output as yarn ls:

$ ./bin/yarn ls 2>&1 | wc -l
2415
$ ./bin/yarn ls gulp 2>&1 | wc -l
2415

@lukeed Can you test the latest code and see if it works for you?

[lukeed]

@kittens @markstos I can confirm the unwanted behavior. All dependencies are listed, regardless of what follows ./bin/yarn ls.

[wyze]

Going to reopen this as it is not implemented fully. I messed with it a bit and was able to get it to work and produce an output like the following:

$ yarn ls chalk
yarn ls v0.17.0-0
├─ babel-code-frame@6.16.0
│  └─ chalk@^1.1.0
├─ chalk@1.1.3
├─ eslint-config-kittens@2.0.1
│  └─ babel-core@5.8.38
│  │  └─ chalk@^1.0.0
├─ eslint@3.7.1
│  └─ chalk@^1.1.3
├─ fancy-log@1.2.0
│  └─ chalk@^1.1.1
├─ gulp-util@3.0.7
│  └─ chalk@^1.0.0
├─ gulp@3.9.1
│  └─ chalk@^1.0.0
├─ har-validator@2.0.6
│  └─ chalk@^1.1.1
├─ inquirer@0.12.0
│  └─ chalk@^1.0.0
├─ jest-cli@16.0.1
│  └─ chalk@^1.1.1
├─ jest-config@16.0.0
│  └─ chalk@^1.1.1
├─ jest-diff@16.0.0
│  └─ chalk@^1.1.3
├─ jest-matcher-utils@16.0.0
│  └─ chalk@^1.1.3
├─ jest-runtime@16.0.0
│  └─ chalk@^1.1.3
├─ jest-util@16.0.0
│  └─ chalk@^1.1.1
├─ marked-terminal@1.6.2
│  └─ chalk@^1.0.0
└─ table@3.8.0
│  └─ chalk@^1.1.1
✨  Done in 0.46s.

[lukeed]

👍 Closer. Looks like you just need to flatten all deps first, then filter for uniqueness.

[wyze]

@lukeed Given the above output, what would you expect it to look like instead with the flattening?

[lukeed]

Unfortunately I can't dig thru & play with Yarn source right now, but I'm a fan of flatten. Assuming you get the array of package names, you'd quickly filter them down with this:

all = all.filter((v, i, a) => a.indexOf(v) === i)

[lukeed]

@wyze The last bit of my opening statement makes the most sense to me as it's also the most concise.

If you want to see why a dep is there // what's including it, you'd use yarn why {name}

[wyze]

I guess I am not following, all the packages listed are unique. If you could just use my sample output and modify it to what you would expect to see, that would be helpful.

[lukeed]

@wyze Sure. Chalk may not be the best example, but if I want to see a list of all (resolved) versions of Chalk that were installed & nothing about which deps required them.

$ yarn ls chalk

yarn ls v0.17.0-0
└─ chalk@1.1.3
✨  Done in 0.46s.

Everything else in your example (^1.1.0, ^1.1.1, etc) was a semver rule that resolved to 1.1.3. So, since 1.1.3 is the only version of Chalk that is actually installed, that's all I want to see.

It's useful because if I see this:

$ yarn ls chalk

yarn ls v0.17.0-0
└─ chalk@1.1.3
└─ chalk@0.0.8
✨  Done in 0.46s.

Then it's instantaneously obvious that I have duplicate/old dependencies installed!

If, then, I need to find out what's requiring chalk@0.0.8, I should ask why:

$ yarn why chalk@0.0.8

yarn why v0.16.1
[1/4] 🤔  Why do we have the module "chalk@0.0.8"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
info This module exists because "inquirer" depends on it.
info Disk size without dependencies: "20kB"
info Disk size with unique dependencies: "20kB"
info Disk size with transitive dependencies: "20kB"
info Amount of shared dependencies: 0
✨  Done in 0.25s. 

I know why doesn't accept versions yet, but I'll probably open a ticket for this too.

[lukeed]

@wyze Back to original example, if I were to run

$ yarn ls gulp*

Your current output would give something like:

yarn ls v0.17.0-0
├─ gulp@3.9.1
├─ gulp-util@3.0.7
│  └─ gulp@^3.9.0
├─ gulp-rev@7.9.1
│  └─ gulp@^3.9.0
├─ gulp-xo@0.14.0
│  └─ gulp@^3.9.0

Which is a lot of repetition, when all that's useful to me is:

├─ gulp@3.9.1
├─ gulp-util@3.0.7
├─ gulp-rev@7.9.1
├─ gulp-xo@0.14.0

[wyze]

Given previous output with once:

$ yarn ls once
yarn ls v0.17.0-0
├─ commoner@0.10.4
│  └─ glob@5.0.15
│  │  └─ once@^1.3.0
├─ end-of-stream@1.1.0
│  ├─ once@~1.3.0
│  └─ once@1.3.3
├─ fileset@0.2.1
│  └─ glob@5.0.15
│  │  └─ once@^1.3.0
├─ glob-stream@3.1.18
│  └─ glob@4.5.3
│  │  └─ once@^1.3.0
├─ glob@7.1.1
│  └─ once@^1.3.0
├─ inflight@1.0.5
│  └─ once@^1.3.0
├─ istanbul-api@1.0.0-aplha.10
│  └─ once@1.x
├─ istanbul@0.4.5
│  ├─ glob@5.0.15
│  │  └─ once@^1.3.0
│  └─ once@1.x
├─ once@1.4.0
├─ orchestrator@0.3.7
│  ├─ end-of-stream@0.1.5
│  │  └─ once@~1.3.0
│  └─ once@1.3.3
├─ run-async@0.1.0
│  └─ once@^1.3.0
└─ tar-pack@3.1.4
│  ├─ once@~1.3.3
│  └─ once@1.3.3
✨  Done in 0.46s.

In the terminal it seems to have logic to dim (src/cli/commands/ls.js#L88) some dependencies. Well with a filter applied, it is going to just hide those. Output above becomes:

$ yarn ls once
yarn ls v0.17.0-0
├─ end-of-stream@1.1.0
│  └─ once@1.3.3
├─ once@1.4.0
├─ orchestrator@0.3.7
│  └─ once@1.3.3
└─ tar-pack@3.1.4
│  └─ once@1.3.3
✨  Done in 0.45s.

Compared to npm:

❯ npm ls once
yarn@0.17.0-0
├─┬ eslint@3.8.1
│ └─┬ glob@7.1.1
│   └── once@1.4.0
├─┬ gulp@3.9.1
│ └─┬ orchestrator@0.3.7
│   └─┬ end-of-stream@0.1.5
│     └── once@1.3.3
├─┬ gulp-watch@4.3.10
│ └─┬ chokidar@1.6.1
│   └─┬ fsevents@1.0.14
│     └─┬ node-pre-gyp@0.6.29
│       └─┬ tar-pack@3.1.4
│         └── once@1.3.3
└─┬ tar-stream@1.5.2
  └─┬ end-of-stream@1.1.0
    └── once@1.3.3

Also, not sure anyone would do this as it is confusing, but it does support multiple arguments:

$ yarn ls vinyl once
yarn ls v0.17.0-0
├─ end-of-stream@1.1.0
│  └─ once@1.3.3
├─ gulp-watch@4.3.10
│  └─ vinyl@1.2.0
├─ once@1.4.0
├─ orchestrator@0.3.7
│  └─ once@1.3.3
├─ tar-pack@3.1.4
│  └─ once@1.3.3
├─ vinyl-file@2.0.0
│  └─ vinyl@1.2.0
├─ vinyl-fs@0.3.14
│  └─ vinyl@0.4.6
└─ vinyl@0.5.3
✨  Done in 0.46s.

I'll look into minmatch and see how easy that would be to work in as well.

[lukeed]

@wyze Yup. I do prefer your shortened output more than the first. Yet, maybe I'm alone on this, but I still only care about:

$ yarn ls once
yarn ls v0.17.0-0
├─ once@1.3.3
├─ once@1.4.0
✨  Done in 0.45s.

IMO, it is why's responsibility to tell me that end-of-stream, tar-pack, and orchestrator are using once@1.3.3. What do you think?

[lukeed]

I mean, I can get exactly what I want right now if/when I pipe yarn ls to grep.

yarn ls | grep fly
├─ fly-browserify@1.0.0
├─ fly-sass@2.0.0
├─ fly-uglify@2.0.0
├─ fly@2.0.5-beta

It just seems unintuitive to me that yarn ls {name} doesn't just do this naturally.

[wyze]

This is now available on master and will be in the next release.

@lukeed If you want the glob pattern matching functionality, please open a separate issue describing it, thanks!