_resolved fallback in npm-logical-tree

(Lars Willighagen) #1

Git dependencies don’t have a resolved field in the package lock. This causes some problems with npm ci installs resulting in npm install not recognizing installed git dependencies. Should npm-logical-tree fall back to using the version in those cases, or should the problem be solved somewhere else?

(Kat Marchán) #2

I’m not sure npm-logical-tree is the right place. And I’m not sure why cipm wouldn’t recognize git dependencies:

extractTree actually resolves using the version and then hands that over to pacote.

(Lars Willighagen) #3

But the resolved that extract passes to pacote to annotate the on-disk manifests in node_modules comes directly from the package lock (in my experience). When that’s empty (for git deps) the package.jsons in node_modules/ don’t have a _resolved field, which is used for comparison of git deps in pkgAreEquiv in diff-trees.

(I see I skipped quite a few steps of the problem in the first post, sorry for that)

Agreed, there are a lot of places that can be improved but this seemed like the earliest “failure”.

(Kat Marchán) #4

The fix would need to be in pacote, in that case, since that’s the one that writes out that metadata.

(Lars Willighagen) #5

It tries to, but finds opts.resolved empty. pacote could still create a fallback for that of course, but I thought it’d be… more “proper” or something, to deal with it earlier.

(Kat Marchán) #6

I’d rather not lie to pacote, if that makes sense. I think the more of this logic that lives inside it, the better. It should be writing metadata correctly with minimal modification.

(Lars Willighagen) #7

Okay, I think I see how it’s supposed to work in pacote (missed that earlier), and I’m trying to figure out why it doesn’t.

But: Happy birthday! :birthday: so I’ll leave you alone now.

(Kat Marchán) #8

Thank you!! :green_heart: