Hapi: potential 🧀 moving in shrinkwrap behavior in npm@4

[othiym23]

Hello, Hapi friends and fellow open source maintainers!

As some of you probably know, I'm the lead maintainer for the npm CLI. We're getting ready to release npm@4 in the near future. Unlike npm@3, it's kind of a catch-all release to push out a bunch of smaller breaking changes (some of which are a bit overdue), and we don't expect it to have a large impact on most developers.

However, also unlike npm@3, npm@4 will potentially have a significant impact on Hapi. This is because one of the other purposes of npm@4 is to set us up for npm@5, which is provisionally entitled "The One Where We Make Shrinkwrap Useful For Everybody". As part of this, in npm@4 we intend to close a loophole that Hapi's been using pretty much since the beginning, and make it so that _only packages included in npm-shrinkwrap.json will be installed, even if other dependencies are enumerated in package.json_.

Pretty much the only reason we didn't close this loophole in npm@3 was because we knew Hapi was relying on it. npm's dependency locking has historically been underdocumented, so it seemed like fair game to let Hapi use that as a way of fixing specific transitive dependencies without pinning all of them. It still seems like a use case that we should support. It happens, though, that there are a number of painful architectural consequences of supporting this behavior that interfere with us both making installs faster and getting shrinkwrapping to where we think it should be.

Because this is fairly late in the release process for npm@4 (for which I give my apologies; this has been on my to-do list for a while), if this is going to present significant problems for y'all, let me know and we can work something out. My concern is that pushing _all_ of the shrinkwrap changes off to npm@5 is going to make it even more disruptive change than it would be otherwise, and also eliminating the behavior Hapi's shrinkwrap relies upon also removes a large source of edge cases for the installer, so it's a big step forward for overall quality of the CLI.

Thanks for your time, and let me know if this is a showstopper for you, or (with luck!) no big deal.

[AdriVanHoudt]

As far as I can tell from https://github.com/hapijs/hapi/issues/3338 there is no real reason that hapi's shrinkwrap is the way it is apart from historical reasons.
To 'fix' this @hueniverse would need to run npm shrinkwrap with npm@3 for every release?

[othiym23]

I'd suggest using npm@4 once it's released, and yes, that would do it. The important part is that the shrinkwrap file be sufficient as a single source of truth with respect to what's installed on disk. As @iarna says in #3338, it's fine to remove fields like resolved from the published shrinkwrap, but all the dependencies need to be there.

[hueniverse]

Just go ahead and do what's right for npm and I'll adapt accordingly.

[cjihrig]

@hueniverse Node core is considering shipping an updated npm with breaking changes in v7. Is this something that hapi is prepared to deal with in the middle of a release line?

cc: @thealphanerd

[MylesBorins]

specficaly it would be node v4.0.5 in a future version of v7 (semver minor).

The specific change that would be breaking would be

Partial shrinkwraps are no longer supported. npm-shrinkwrap.json is considered a complete installation manifest except for devDependencies. This will affect certain projects that relied heavily on this feature, most notably hapi.

[iarna]

The Hapi npm-shrinkwrap.json was made npm v4 compatible with https://github.com/hapijs/hapi/commit/0ca8cea7898dcbc41d59778f0bb4b9d0985d7123 which was included in v16.0.0.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.