search

JamieMason / shrinkpack

Fast, resilient, reproducible builds with npm install.
https://www.npmjs.com/package/shrinkpack
MIT License
793 stars 38 forks source link

Git dependencies with same version are not necessarily updated #72

Closed lime closed 8 years ago

lime commented 8 years ago

We had a couple of occurrences of strange behaviour after starting to use a git fork of a library. The fix (applied once per machine, then forgotten again) was to rm -rf node_modules/library-name and run npm install again. It let us get on with work, but I started to wonder whether it was a consistent issue that could be reproduced and fixed.

Consider the following scenario:

  1. You're using the potatoes library, version 3.5.0
    • Your shrinkwrap points to "./node_shrinkwrap/potatoes-3.5.0.tgz"
  2. There's a PR for a cool new feature that you absolutely need.
    • It's based off of the latest master, so its package.json has version set to 3.5.0.
  3. You install the bleeding edge PR directly through git:// and run shrinkwrap & shrinkpack
    • potatoes-3.5.0.tgz still has the same name, but different content
    • Not a problem, you have the correct version installed.
  4. Your co-coder checks out your changes and runs npm install
    • Since they already had potatoes installed at 3.5.0, npm does nothing
    • They are still running the old version, and are missing out on the cool new feature

It seems like npm doesn't get any indication that a new install would be needed. Without shrinkpack, I guess from / resolved would change to point to the git commit and version would stay the same. With shrinkpack, none of them change.

One solution could be to include the commit hash in the tarball name, e.g. node_shrinkwrap/potatoes-3.5.0-ab01cd2.tgz.

I hope to create reproducible step-by-step commands to verify that what I described above actually is what happens (I'm much less than 100% sure). I should also check whether a non-shrinkpacked project behaves differently. Still, I thought it could be useful to raise the issue. If nothing else, it should push me to get the debugging done. :)

I had the feeling that I had seen this discussed somewhere before, but didn't find it. If this is already known / fixed, sorry for the noise.

I'm on shrinkpack 0.12.2, npm 2.15.4 and node 4.4.0.

JamieMason commented 8 years ago

Thanks Emil, sounds good. Agree it would make sense in the case of from-Git repos that the commit SHA is incorporated somehow.

lime commented 8 years ago

This seems to be a relevant upstream issue: https://github.com/npm/npm/issues/4042

If I'm reading it correctly, it sounds like trying to work around it on the shrinkpack side might be an uphill battle...

JamieMason commented 8 years ago

thanks @lime, I will close this and mark as upstream. If anyone has any other ideas please feel free to comment.

nifgraup commented 8 years ago

I believe this is working fine with npm 3.x