[RRFC] include context that a module is overridden in npm ls

[bnb]

Motivation ("The Why")

I recently spoke with someone who was trying out overrides for the first time in their product and didn't have any signal as to whether or not an override was being applied.

In them showing me, it was explained that npm ls didn't tell them anything about overrides and that feels like a large missed opportunity.

Example

• git clone https://github.com/bnb/repro-overrides-output
• npm install
• npm ls --depth=3
• find "@types/prettier" which will show 2.6.0 without any indication that it was overridden.

How

Current Behaviour

When you npm ls, no overrides contextual information is shown.

Desired Behaviour

When you npm ls, note which modules were overridden as npm currently does with dedupes. Potentially also worth noting direct overrides vs. indirect overrides.

References

• N/A

[ljharb]

Does npm explain provide this context, at least?

[bnb]

as far as I can tell it doesn't. Here's a gist: https://gist.github.com/bnb/109d0429dd33824415e0671679ff46fb

[ljharb]

While it seems like npm ls could be an RFC (a very necessary one that probably should have been part of overrides from the start), npm explain not showing that seems like a bug.

[ruyadorno]

+1 to have some sort of info added to npm ls

not even sure if it needs a full RFC, probably useful to have a light RFC since it would be nice to have a few examples and set expectations on how things are supposed to look like / work (particularly the other visualization modes: parseable and json)

[bnb]

@darcyclarke any shot we can get this included in the next meeting?

[nlf]

this work has been done here: npm/cli#5306

[bnb]

sick, tysm @nlf <3

I'm not sure if you're waiting to close this until it ships, but that does solve my request. I'll close this now but feel free to reopen if that's part of your workflow.