This is a "best practices" question, motivated by the need to test against many versions of node.
For any given version of node, what's the best, most appropriate, and least likely to be problematic version of npm to use?
Node ships with npm, so I'm inclined to just use the version of npm which ships with the version of node that I'm testing against. But there are inevitably occasional breakages or security issues, so that means that if I use this approach, I probably need to keep track of those issues and tweak the npm version accordingly.
Another approach is to take the minor version which ships with a given node, and upgrade it to the highest patch release. That's probably going to take care of the instances I mentioned above, where there are bugs in particular versions of npm I would think.
Yet another approach is to just upgrade to the most recent version of npm. That seems a bit fraught, given that there are breaking changes in version 2.x.
My apologies if this is a FAQ. I will accept admonishment with appropriate humility; also gratitude, if it's accompanied by a reference, ideally in the form of a URL.
To answer quickly: the latest.
Take all advice for 'best practices' with a huge lump of salt because 'best' depends on the context. There is no one best.
> On 7 Dec 2014, at 01:06, J Irving <jonathan.irving@gmail.com> wrote:
> For any given version of node, what's the best, most appropriate, and least likely to be problematic version of npm to use?For v0.8: latest.
For v0.10: latest.
For v0.11: latest.
For v0.6: 1.4.28.
> Node ships with npm, so I'm inclined to just use the version of npm which ships with the version of node that I'm testing against. But there are inevitably occasional breakages or security issues, so that means that if I use this approach, I probably need to keep track of those issues and tweak the npm version accordingly.There are race conditions all over the place in 1.4.x. Plan accordingly. Things sometimes fail to unpack completely. Sometimes stuff is missing. Sometimes you just get errors for no reason that will vanish on a second run. (EEXIST in particular, or ENOENT -- things that exist when they shouldn't and don't when they should that other tasks depend on)
> Another approach is to take the minor version which ships with a given node, and upgrade it to the highest patch release. That's probably going to take care of the instances I mentioned above, where there are bugs in particular versions of npm I would think.
>
> Yet another approach is to just upgrade to the most recent version of npm. That seems a bit fraught, given that there are breaking changes in version 2.x.Know what the breaking changes are:
* -pre versions of packages aren't selected as candidates for installation unless mentioned specifically. This matches up with the community practice of introducing experimental interface changes that evolve until a final release. you don't want to be using those versions without intending to.
* The command-line of npm run has changed to be more useful, but not compatible.
See http://blog.npmjs.org/post/
smime.p7s
IMO, npm1 from node v0.10 works ok on linux/os x.
On Windows, though, I'd say npm2 is mandatory. I consistently see
Windows issues cleared away by updating to npm2, major bugs were
fixed.
Take all advice for 'best practices' with a huge lump of salt because 'best' depends on the context. There is no one best.
> On 7 Dec 2014, at 01:06, J Irving <jonathan.irving@gmail.com> wrote:
> For any given version of node, what's the best, most appropriate, and least likely to be problematic version of npm to use?For v0.8: latest.
For v0.10: latest.
For v0.11: latest.
For v0.6: 1.4.28.
> Node ships with npm, so I'm inclined to just use the version of npm which ships with the version of node that I'm testing against. But there are inevitably occasional breakages or security issues, so that means that if I use this approach, I probably need to keep track of those issues and tweak the npm version accordingly.There are race conditions all over the place in 1.4.x. Plan accordingly. Things sometimes fail to unpack completely. Sometimes stuff is missing. Sometimes you just get errors for no reason that will vanish on a second run. (EEXIST in particular, or ENOENT -- things that exist when they shouldn't and don't when they should that other tasks depend on)
> Another approach is to take the minor version which ships with a given node, and upgrade it to the highest patch release. That's probably going to take care of the instances I mentioned above, where there are bugs in particular versions of npm I would think.
>
> Yet another approach is to just upgrade to the most recent version of npm. That seems a bit fraught, given that there are breaking changes in version 2.x.Know what the breaking changes are:
* -pre versions of packages aren't selected as candidates for installation unless mentioned specifically. This matches up with the community practice of introducing experimental interface changes that evolve until a final release. you don't want to be using those versions without intending to.
* The command-line of npm run has changed to be more useful, but not compatible.
See http://blog.npmjs.org/post/
smime.p7s
IMO, npm1 from node v0.10 works ok on linux/os x.
On Windows, though, I'd say npm2 is mandatory. I consistently see
Windows issues cleared away by updating to npm2, major bugs were
fixed.
댓글 없음:
댓글 쓰기