Open stelcheck opened 10 years ago
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.
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
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
Ah, okay. well, you can try it with 0.8, will probably work :)
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.
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
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
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.