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:
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
node_modules/ don’t have a
_resolved field, which is used for comparison of git deps in
(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
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! so I’ll leave you alone now.
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)?