Node app fails to run because of prerelease

I get invalid packages installing, even if the installation is a success. Btw, this question is related to the answer - question about versioning

npm install serialport

These are packages which is stuck far in the dependency tree.

npm ERR! invalid: readable-stream@1.0.27-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream
npm ERR! invalid: string_decoder@0.10.25-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream/node_modules/string_decoder

This ends up causing this error in my browser:

Uncaught TypeError: Cannot read property '_ansicursor' of undefined

Is there any way to sort up in this npm problem? Can I avoid these prerelease packages?

The github answere below gave me a lot of insight into npm and I thought I had to dig somewhere else for the issue. But it acctually just seemed like serialport does not work very well, anymore, with browserify. It used to work because i used if for two months, but something changed. When im saying it out loud, it just sounds stupid anyway. So dont browserify serialport.

I recieved an answere on github, issue answere, thought i would share it with the rest who might wonder:

The change in handling prerelease versions in semver@4 is one of the primary motivators for the major version bump to npm@2. All versions of npm 2 are affected by this change, which, put briefly, ensures that all version information to the right of - in version strings is ignored when doing semver range matching. When you upgrade from npm@1 to npm@2, it's normal to see some irregularities show up when you run npm -g ls, and since some packages are distributed as self-contained installs via the use of bundledDependencies, they may come out of the package in a state that is inconsistent with npm@2's rules.

While this won't always work, most of the time the easiest way to fix these issues is simply to uninstall and reinstall the affected package. For packages that ship with bundledDependencies, if you really want to get everything cleaned up, you can cd into the node_modules folder containing the version of the package with the noisy prerelease dependency version and just run npm install problemDependency, and it will use the newest version of that dependency that matches the semver range for that particular package.

Re: your second question, semver range checking is done semantically, not lexically, so 1.0.31 should match with npm@2:

% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31 1.0.26 1.0.31 I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.

All of this is documented, so I'm going to close this issue. I hope this clears things up for you!