Remove npm-shrinkwrap

[hueniverse]

npm 5 completely broke the solution we were using until now. It forces changes on the existing file so no manual management is possible. The new format then breaks older versions of npm. I am not sure what's the full replacement but for now I'll just lock the package.json versions for the direct dependencies which is not perfect but better than nothing.

If anyone has suggestions, let me know.

[devinivy]

Anyone know more about this? You can't author/manage shrinkwraps manually anymore?

[corbinu]

@devinivy No the new behavior is designed to be much more like yarns work flow.

Docs are here: https://docs.npmjs.com/files/package-locks

@zkat would be the source of truth for all things npm@5

[zkat]

So, a couple of things:

1. The new format should be backwards-compatible. Is there something that's breaking? D:
2. we've been moving away from a "pick your own shrinkwrap" model for a while. One of those changes was adding devDeps. Another was no longer allowing partial shrinkwraps. I'm not sure what else would be breaking you here, aside from moving to the new format: the only difference besides the overall format change is that we --save by default, which has been updating shrinkwraps already since npm@3.

[devinivy]

@zkat thank you very much for the speedy response!

I imagine part of our problem is that we use a partial shrinkwrap (if I remember correctly). But I'm not sure that's necessary for us. I still don't fully understand the issue @hueniverse is keying-in on here. I'd guess that the "forced changes" to the shrinkwrap could be ignored using a git checkout after an npm install.

[zkat]

to be clear: unless you're installing new modules or removing them, npm-shrinkwrap.json should not change, unless something weird's going on. In which case we should fix it. /cc @iarna to make sure I got this right.

We really haven't supported partial shrinkwraps for a while, and last time I asked, I thought hapi had stopped doing that (it was one of the reasons we weren't making the change yet!)

[iarna]

I concur with everything @zkat said here. I'm pretty sure we patched the partial shrinkwrap out of hapi before the npm@4 launch (I opened in issue here in advance of that, since we knew that change was going to break you all.)

We definitely aren't going to be supporting manually editing your shrinkwraps going forward, but if you want to mutate it in a consistent way the postshrinkwrap lifecycle exists to support that.

But that being said, it's possible that the package-lock.json will meet your needs fine (it's the same file but with a different name).

I'd like to know though: What problem were you all solving with your npm-shrinkwrap.json? We'd like ensure that you can solve it in a satisfactory way.

[iarna]

@hueniverse If you'd like, I'd be happy to PR a postshrinkwrap that gives makes all npm's give you shrinkwraps comparable to your old one.

[hueniverse]

My goal is to have full control over every dependency hapi uses all the way down. I also want to be able top block one module (isemail) from being installed. Before npm 5 I was able to do just that with a manually created shrinkwrap file. It was working perfectly with npm 4. I am not picky about the solution as long as it allows me to do what we used to.

The reason, btw, is security. When someone installs my package, I want them to know with 100% certainty that I approved, reviewed, and tested every dependency my module brings with it. Just because some author down the line decided to publish a new version should not pop up on my machine unless I explicitly asked for it.

The normal shrinkwrap process for production code doesn't really prevent developers using my code to understand which deep dependency they should grab and allow in their local deployment and which they should not. I provide a fully tested package.

@zkat @iarna Would this still be possible with the new setup? Thanks for the help!

[zkat]

@hueniverse So, one thing that this new shrinkwrap format can do is make it easier to review diffs by minimizing churn. I think what you could try is to just throw away diffs you don't want for transitive dependencies as long as the required semver ranges match. So if you see something you don't like, just don't commit it.

[iarna]

@hueniverse

My goal is to have full control over every dependency hapi uses all the way down.

That is exactly what it's for.

I also want to be able top block one module (isemail) from being installed. Before npm 5 I was able to do just that with a manually created shrinkwrap file. It was working perfectly with npm 4. I am not picky about the solution as long as it allows me to do what we used to.

If you remove a module by hand then npm@5 will maintain that. This is a little weird and in any version of npm will result in npm ls reporting missing dependencies, but it will work.

Would this still be possible with the new setup? Thanks for the help!

Yup, there's really nothing special to it.

The only other special thing that you were doing previously was stripping the shrinkwrap down to just be version specifiers (no from, no resolved). Was there a technical reason for this, or was it just that it was easier to maintain by hand?

We don't generate from any more, but we do generate resolved. If you do need resolved removed, that can be arranged.