peerDependency problems

[klokoy]

When I try to install hapi 8.0.0-rc3 I get a problem with peerDependencies not satisfied:

npm ERR! peerinvalid The package hapi does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer hapi-auth-cookie@1.4.1 wants hapi@>=2.x.x
npm ERR! peerinvalid Peer yar@2.1.0 wants hapi@>=2.x.x

It seems a bit strange that 8.0.0-rc3 !>= 2.x.x.
Is there a way I can get around this?

[potrata]

Same with 8.0.0-rc2

[gergoerdosi]

It seems strange, but it is the expected behavior. See npm documentation:

If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.

For example, the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.

So we should add an OR statement to fix this dependency issue:

> semver.satisfies('8.0.0', '>=2.x.x')
true
> semver.satisfies('8.0.0-rc3', '>=2.x.x')
false
> semver.satisfies('8.0.0-rc3', '>=2.x.x || >=8.0.0-rc1')
true

[csrl]

This 8.0.0-rcX series has been very frustrating to get into with given the dependency problems. If $ npm update breaks, what confidence is there with the rest of it to even bother with migrating over.

Certainly it was a barrier to entry that delayed me until now before I had the patience and time to work through them. Probably others still aren't bothering with 8.0.x until the dependency issues are worked out.

The dependencies could have been managed once for everyone, instead of everyone having to individually work through them every time a rcX release is made. If you want more validation of the 8.0.0 release candidates, probably this aspect of the release process should be fixed.

See also #2183 and #2161

[hueniverse]

What version of npm are you on?

[csrl]

$ npm --version
2.1.9

The work around I used was to have a local hapi repository, and delete hapi/shrinkwrap.json, and remove h2o2, inert, statehood and vision from hapi/package.json

I then also had to have local repositories of glue, h2o2, inert, vision and several other hapi-xxx plugins I am using, removing all dependencies in them to hapi or any of the above named packages. Then in my own application repository, I added each of the above to my package.json as local file versions - eg "h2o2":"file:../../temp/h2o2".

At which point, npm quit complaining, and I was able to run the server and work through the porting issues. Maybe there was an easer way, but this is the path I was able to discover through trail and error.

Thanks.

[hueniverse]

Yeah... it's a problem with npm 2. They no longer match dash versions to a non-dash requirement. I rather not deal with it for the few days left before we just move to the official release.