nikku / karma-browserify

A fast Browserify integration for Karma that handles large projects with ease
MIT License
321 stars 49 forks source link

Peer dependency failure? #164

Closed tandrewnichols closed 8 years ago

tandrewnichols commented 8 years ago

This is . . . weird, and not my understanding of how peer dependencies should work, but I'm getting a peer dependency failure for this module (for browserify), even though I have browserify@13.0.0 installed. I see the peer dependency should include this (the range >=10 <=13 should include 13.0.0 and on semver calculator it does). Any idea why this would be happening?

It's worth noting that I only get this failure on node 0.10.x with npm 1.x (on travis - but reproducible if I switch to node 0.10 locally), so it's certainly surmountable (although I like to include support for 0.10). I just found it strange and wondered if you'd seen this before.

Screen shots:

screen shot 2016-01-26 at 9 19 59 am screen shot 2016-01-26 at 9 20 32 am
nikku commented 8 years ago

npm v1.x would automatically install peerDependencies while npm v3.x does no more.

Which version of browserify is actually installed to node_modules?

You may revert back to karma-browserify v4.x if you cannot get it to work. Upgrading npm to a recent version (npm v2.x and higher) may fix the issue, too.

tandrewnichols commented 8 years ago

Yeah, I mean, I could also just drop support for node 0.10. My current solution was to install browserify@<13 and that works fine. Might trying updating npm on travis when running in 0.10, but then I also have to add an engines declaration with npm: >= 2 so that others don't run into this problem when installing my thing.

Version 13.0.0 is the one actually installed (second image above). But I don't know what npm does if the dependency is already installed (as a part of normal dependency resolution), and it then encounters a peer dependency for that same module with a slightly different range declaration (it should resolve to the same version though).

At any rate, sounds like I'll just have to work around it. Thanks for the feedback. Feel free to close (as this isn't really an issue of this module).