Error: No compatible version found: semver@'^2.2.1'

[stelcheck]

6587 error Error: No compatible version found: semver@'^2.2.1'
6587 error Valid install targets:
6587 error ["1.0.0","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6","1.0.7","1.0.8","1.0.9","1.0.10","1.0.11","1.0.12","1.0.13","1.0.14","1.1.0","1.1.1","1.1.2","1.1.3","1.1.4","2.0.0-alpha","2.0.0-beta","2.0.1","2.0.2","2.0.3","2.0.4","2.0.5","2.0.6","2.0.7","2.0.8","2.0.9","2.0.10","2.0.11","2.1.0","2.2.0","2.2.1"]
6587 error     at installTargetsError (/opt/nvm/v0.8.26/lib/node_modules/npm/lib/cache.js:719:10)
6587 error     at /opt/nvm/v0.8.26/lib/node_modules/npm/lib/cache.js:641:10
6587 error     at saved (/opt/nvm/v0.8.26/lib/node_modules/npm/node_modules/npm-registry-client/lib/get.js:138:7)
6587 error     at Object.oncomplete (fs.js:297:15)
6588 error If you need help, you may report this log at:
6588 error     <http://github.com/isaacs/npm/issues>
6588 error or email it to:
6588 error     <npm-@googlegroups.com>
6589 error System Linux 2.6.32-358.23.2.el6.x86_64
6590 error command "/opt/nvm/v0.8.26/bin/node" "/opt/nvm/v0.8.26/bin/npm" "install" "npmd" "-g"
6591 error cwd /home/vagrant/something
6592 error node -v v0.8.26
6593 error npm -v 1.2.30

[dominictarr]

the ^ is a new thing added in semver 2. I notice that your node version and npm version are both quite old, but here my hunch is your npm version...

using npmd resolve, I can see what version of semver an old npmd version will use.

>npmd resolve npm@1.2.30
{
  "name": "npm",
  "version": "1.2.30",
  "shasum": "354797b97644935a4d017698c5a395142ab71f1c",
  "dependencies": {
    "semver": {
      "name": "semver",
      "version": "1.1.4",
      "shasum": "2e5a4e72bab03472cc97f72753b4508912ef5540",
      "from": "~1.1.2",
      "dependencies": {}
    },
    "ini": {
      "name": "ini",
      "version": "1.1.0",
      "shasum": "4e808c2ce144c6c1788918e034d6797bc6cf6281",
      "from": "~1.1.0",
      "dependencies": {}
    },
   ...
}

you need semver@2 to be able to parse ^2.2.1 versions, so I think installing the latest npm version may solve this.

I'd also like to encourage you to update to node 0.10, node is pretty stable these days, so it makes it much easier if we all run the same version.

[stelcheck]

Understood, thank you for your quick response. I have nvm locally, so I could always have npmd running on 0.10 in separate...

That being said, we probably want to have an engine.node entry in the package.json then...

On Tue, Dec 3, 2013 at 2:01 PM, Dominic Tarr notifications@github.comwrote:

the ^ is a new thing added in semver 2. I notice that your node version and npm version are both quite old, but here my hunch is your npm version...

using npmd resolve, I can see what version of semver an old npmd version will use.

npmd resolve npm@1.2.30{ "name": "npm", "version": "1.2.30", "shasum": "354797b97644935a4d017698c5a395142ab71f1c", "dependencies": { "semver": { "name": "semver", "version": "1.1.4", "shasum": "2e5a4e72bab03472cc97f72753b4508912ef5540", "from": "~1.1.2", "dependencies": {} }, "ini": { "name": "ini", "version": "1.1.0", "shasum": "4e808c2ce144c6c1788918e034d6797bc6cf6281", "from": "~1.1.0", "dependencies": {} }, ...}

you need semver@2 to be able to parse ^2.2.1 versions, so I think installing the latest npm version may solve this.

I'd also like to encourage you to update to node 0.10, node is pretty stable these days, so it makes it much easier if we all run the same version.

— Reply to this email directly or view it on GitHubhttps://github.com/dominictarr/npmd/issues/43#issuecomment-29683882 .

http://www.wizcorp.jp/Marc Trudel-Belisle

Chief Technology Officer | Wizcorp Inc. http://www.wizcorp.jp/

TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 3-4550-1448|Websitehttp://www.wizcorp.jp/ |Twitter https://twitter.com/Wizcorp|Facebookhttp://www.facebook.com/Wizcorp |LinkedIn http://www.linkedin.com/company/wizcorp

[dominictarr]

Ah, okay. well, you can try it with 0.8, will probably work :)

[dominictarr]

I thought that npm ignores the engines.node field now? it was tried for a while, but turned out to be more harm than good.

[stelcheck]

As in? this was on 0.8.26, after all.

On Tue, Dec 3, 2013 at 2:14 PM, Dominic Tarr notifications@github.comwrote:

Ah, okay. well, you can try it with 0.8, will probably work :)

— Reply to this email directly or view it on GitHubhttps://github.com/dominictarr/npmd/issues/43#issuecomment-29684231 .

http://www.wizcorp.jp/Marc Trudel-Belisle

Chief Technology Officer | Wizcorp Inc. http://www.wizcorp.jp/

TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 3-4550-1448|Websitehttp://www.wizcorp.jp/ |Twitter https://twitter.com/Wizcorp|Facebookhttp://www.facebook.com/Wizcorp |LinkedIn http://www.linkedin.com/company/wizcorp

[dominictarr]

So, I think updating npm to the latest will fix this issue, but I think only updating node would be a "good idea"...

Aha! so I was wrong, npm still has engines but it's disabled by default.

I remember when it was first introduced, and enabled by default, and a engines.node was added for every module, and it was very annoying, with ranges that were far too narrow.

from the npm help package.json

engines
       You can specify the version of node that your stuff works on:

           { "engines" : { "node" : ">=0.10.3 <0.12" } }

       And,  like  with dependencies, if you don't specify the version (or if you specify "*" as the version),
       then any version of node will do.

       If you specify an "engines" field, then npm will require that "node" be  somewhere  on  that  list.  If
       "engines" is omitted, then npm will just assume that it works on node.

       You  can  also  use  the  "engines"  field  to  specify  which  versions of npm are capable of properly
       installing your program.  For example:

           { "engines" : { "npm" : "~1.0.20" } }

       Note that, unless the user has set the engine-strict config flag, this field is advisory only.

engineStrict
       If you are sure that your module will definitely not run properly on versions of  Node/npm  other  than
       those  specified  in the engines hash, then you can set "engineStrict": true in your package.json file.
       This will override the user's engine-strict config setting.

       Please do not do this unless you are really very very sure.  If your engines hash is  something  overly
       restrictive, you can quite easily and inadvertently lock yourself into obscurity and prevent your users
       from updating to new versions of Node.  Consider this choice carefully.  If people abuse it, it will be
       removed in a future version of npm.

hmm, I guess I could set

"engineStrict": true with an open ended range, "npm" >= "1.3"

I'm gonna hold off on this for now, but I will be considering this.