下面的github回答使我对npm有了很多了解，我认为我必须在其他地方解决这个问题.但是，从浏览器的角度来看，串行端口似乎并不能很好地工作.它曾经工作是因为我用了两个月，但情况有所变化.当我大声说出来时，它听起来还是很愚蠢的.因此，请不要通过浏览器来实现串行端口.

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.

我在github上收到了答复，问题答复，以为我会与其他可能会想知道的人分享:

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

semver @ 4中处理预发行版本的更改是主要版本升级到npm @ 2的主要动机之一.此次更改会影响npm 2的所有版本，简要地说，这是确保在进行semver范围匹配时，忽略版本字符串中-右边的所有版本信息.从npm @ 1升级到npm @ 2时，通常会在运行npm -g ls时看到一些异常情况，并且由于某些软件包是通过使用bundledDependencies作为独立安装分发的，因此它们可能来自软件包的状态与npm @ 2的规则不一致.

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.

尽管这种方法并不总是有效，但大多数情况下，解决这些问题的最简单方法就是卸载并重新安装受影响的软件包.对于附带bundledDependencies的软件包，如果您真的想清理所有内容，则可以cd进入包含带有嘈杂的预发行版本的版本的软件包的node_modules文件夹，然后运行npm install problemDependency，它将使用最新版本与该特定程序包的semver范围相匹配的依赖项.

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.

回复:您的第二个问题，semver范围检查是从语义上而不是从词法上完成的，因此1.0.31应该与npm @ 2匹配:

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 我怀疑您看到的行为是由于压缩包tarball中包含的bundledDependency引起的.

% 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!