npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

_resolved fallback in npm-logical-tree

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?


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.


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”.


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


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.


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.


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.


Thank you!! :green_heart:


Belated Happy birthday @zkat

Btw, have we identified this as a bug and going to fix it (npm prune --production runs postinstall and breaks jenkins ci build)?