feat(config): add in-range

[wraithgar]

This adds a flag for npm outdated to use to limit output either to
packages that have updates in-range of the current package's
requirements, or those that have no updates in-range of the current
package's requirements.

It also adds to the normal (i.e. non JSON or parseable) output directing
folks to use npm explain for more info. This is because the output of
npm outdated is misleading, sometimes saying an available version is
present when there is another package in the tree responsible for
keeping the version where it is.

[isaacs]

So, iiuc, "in-range" means "only show where wanted is latest". My expectation was that it would be "only show where the wanted version is within my dep range". Maybe I'm misreading this?

[isaacs]

So, like, if the current is 1.0.0, wanted is 1.0.1, but latest is 2.0.0, I'd expect npm outdated --in-range to show that.

[isaacs]

Actually, in that case, I'd also expect it to show up for npm outdated --no-in-range, because there's an out-of-range version I could install.

[wraithgar]

I wanted a way to filter between the red and the yellow outputs in pretty print.

[wraithgar]

Ultimately "what could I fix with npm update and what would need a package.json change?"

[wraithgar]

My expectation was that it would be "only show where the wanted version is within my dep range

YES this is the intent. "What could I fix with npm update"
Also related: this is what I assume is being communicated by the red and yellow output colors here.

[ruyadorno]

LGTM 👍

[wraithgar]

@ruyadorno I think I'm actually gonna close this, or move it back to draft cause the discussion seems to be warranted here about what problem(s) we're actually solving.

[ljharb]

so with these options, how do i override NPM_CONFIG_IN_RANGE=false npm outdated (or true)? do i have to do --in-range=null?

Generally a boolean isn't a great choice when there's three options, so perhaps an enum would be clearer here?

[wraithgar]

@ljharb see the discussion on the if statements above, it is as you say checking for the default null vs an explicit true or false. I agree it's not ideal and that discussion is why this PR went back to draft status to be discussed and solved as part of a better solution that lets npm update --dry-run solve the "What can be updated problem" first.

[ljharb]

Per today's RFC call, here's my thoughts:

there's really two mental models - two use cases - that i think people are using npm outdated for.

1. "show me in-range updates" - this is the one it seems to be primarily designed for, which is basically "what npm update hopefully does". (npm update --dry-run and npm update foo --dry-run would be super useful on its own, precisely because i'm not actually sure what npm update does). This shows me things that are safe to update to.

2. "show me out-of-range updates" - this is where i'd be likely crossing semver-major lines, and things might break. This is the list of things I likely have to painstakingly and manually work through, looking at changelogs, and updating one at a time, to make sure nothing breaks.

It might be useful for the default view of npm outdated to remain the first case, but add a flag to optimize for the second case?

[wraithgar]

The tracking issue for 'make reify dry run things good' is here #1999

[darcyclarke]

Closing: we are going to queue up npm update --dry-run (ref. #1999)

[glen-84]

@darcyclarke Does that solve #3409, which was closed in favour of this PR?

[glen-84]

@wraithgar ?

[wraithgar]

Yes this will fall under that same umbrella. npm outdated will end up being a design layer over the underlying dry run of an update