RFC: Remove --depth from npm outdated

[claudiahdz]

cc. @isaacs

[isaacs]

This is good, and we can discuss a bit more in today's RFC call. I think one thing to clarify is what exactly would show in each column.

Presenting some kind of proposal to chew on would be useful. It's especially confusing that "location" here is "the path in the dependency graph to the thing that depends on the node" and not "the location of the node".

I'd suggest each line could be:

• Package Name of the node
• Current Node current version
• Wanted Most up to date version that satisfies each edgesIn Edge
• Latest Latest version in the packument
• Location The node.location of the node (not the dependent)

And then group by each combination of wanted+location. So, you might see something like this, which is a little weird, but shows that the deduped package may have to get un-deduped:

Package      Current  Wanted  Latest  Location
bar          1.0.0    1.4.0    2.0.0  node_modules/bar
bar          1.0.0    2.0.0    4.0.0  node_modules/bar

[isaacs]

Would be worth adding a not here that "depth" doesn't have a clear meaning in the context of a dependency graph over a deduplicated tree, since the same node will often be reachable via multiple different dependency paths. (Ie, the same issue brought up in https://github.com/npm/rfcs/blob/latest/accepted/0019-remove-update-depth-option.md)

[isaacs]

Doing npm outdated --depth 9999 displays all outdated packages that are direct children of the root package, missing out dependencies that are nested at other levels. This gives a wrong impression since we are not really displaying all outdated dependencies of the tree.

I don't think that's the case, unless I'm misreading this maybe? npm outdated --depth=9999 includes this output, for example:

log-update                  3.4.0    3.4.0    4.0.0  npm-audit-report > tap > ink
log-update                  3.4.0    3.4.0    4.0.0  npm-audit-report > tap > treport > ink

[claudiahdz]

I think in that case that particular dependency is being deduped and is indeed a direct child of your root package, dependencies that are not deduped and are nested within their own dependant, do not seem to show up when doing only npm oudated --depth 9999 but DO show up when you do npm oudated --depth 9999 <packageName>.

[isaacs]

Hm, it's not though. log-update is a dependency of ink, and my package depends on tap, which depends on ink.

$ find node_modules -name log-update
node_modules/tap/node_modules/log-update

It is a good example of the fact that --depth is pretty weird when talking about a dependency graph, though. It looks like I have two outdated versions of log-update, when really they're the same dep node.

[claudiahdz]

Yeah, correct. The thing is that log-update is a direct child of tap. So I misphrased that by saying the command shows only direct children of the root package when I meant to say that the v6 algorithm is iterating recursively over the node's direct children (on the file system) instead of over node.edgesOut.

Try doing npm outdated --depth 9999 ansi-escapes (basically any specific dep inside node_modules/tap/log-update/node_modules) and you'll see they are not displayed when calling outdated without a package-name.

Using tree.inventory and node.edgesIn on v7 will definitely solve this problem and properly give us a complete list of all outdated packages.

[wesleytodd]

The addition of --all, as discussed on the RFC call, means a new config option all, which presents a hazard because these are global and would apply to more than just this command. This also came up with the workspace filter flag. We just need to be clear what the goals are for config/flags.

[isaacs]

Update from RFC call: --long is not a suitable replacement for --all, because it's already used by npm outdated to provide additional information.

Worth considering if we could make npm update continue to only update root level deps, and then have the (current, as of this moment) npm update behavior be triggered by npm update --all. Would definitely justify having the flag on outdated, and provide some nice symmetry, though I think you're more likely to want to update everything that see outdated versions of everything. The fact that you don't have to care about nested deps means "just update it" is fine, and "show me what needs updating" is unnecessary noise most of the time.

[ljharb]

Definitely the ideal default for update is "everything", and for outdated is "my direct deps only".

[ruyadorno]

are there any breaking changes expected for the --json output?

[claudiahdz]

@ruyadorno No, the only thing to note is that the location info has changed and is now node.location (its position on the physical tree) instead of its position on the logical dependency tree

[wesleytodd]

Just to add here what I bought up on the call, could we display both the logical and physical path?

After continued discussion, removing this concern for now in lieu of better support for this via direct libraries.