npm install based on node engine version

[trevnorris]

Tried posting this to the mailing list, but it was being a bastard.

Because of the complex changes to the v8 API recently I was thinking it would be nice to allow "npm install" to automatically install the latest version of the package based on the latest supported node engine.

This way I could maintain two branches of my project, One could have something like

{ "engines": { "node": ">= 0.10.0 <0.11.0" }}

and the other

{ "engines": { "node": ">= 0.11.0" }}

publish each of those to different minor versions, and npm could figure out which minor version to use automatically based on what version of node I'm using to get the package.

Feasibility for a feature like this?

[19h]

Sounds like a good feature regarding backwards-compatibility. However, as you proceed with development and don't keep that compatibility forever, you should consider publishing the < 0.11.0 code as distinctive version and tell your users from there on to install the module using a version identifier for the sake of compatibility (module@2.1.0). Every normal user who goes with time (standard $ npm install module) will get the latest version. Also, it's far more maintainable.

[trevnorris]

The development pattern I had in mind was to create minor versions of my own, and keep those compatible with specific minor versions of Node. (e.g. my 0.2 branch would be >= v0.10.1 <0.11.0, and my 0.3 branch would be >= 0.11.0). The point of the request is that if a user does an npm install using v0.10.x then it would automatically grab my 0.2 branch.

[19h]

Agreed, a selector-based approach would ease up the process a bit. Let's hear some different voices before it's implemented.

[luk-]

I think this is feature bloat

On Tuesday, July 16, 2013, Kenan Sulayman wrote:

Agreed, a selector-based approach would ease up the process a bit. Let's
hear some different voices before it's implemented.

—
Reply to this email directly or view it on GitHubhttps://github.com/isaacs/npm/issues/3662#issuecomment-21052342
.

[trevnorris]

On Jul 16, 2013 5:10 PM, "Luke Arduini" notifications@github.com wrote:

I think this is feature bloat

Could you elaborate why?

node-gyp already does something similar by detecting what version of Node
I'm using, then downloads the appropriate resources necessary to complete
the build. To me it'd make more sense they work in tandem to accomplish
this. Instead of grabbing the package, downloading all the build files then
having the build process blow up on me because I have the wrong version.

Also I'm seeing developers ifdef'ing their code up the yin yang to support
Node master and stable to get around the problem of users installing the
wrong version. As of 0.11.4 I'm not even sure how that would be possible
because of the latest round of v8 API changes, and there will be at least
one more round before 0.12 is released when they officially deprecate
Handle.

At the very least it'd help to have a quick way of finding out which
packages are compatible with specific versions of Node from npm, but as far
as I know there's no way to do this.

[isaacs]

This is already in npm, behind a flag: npm config set engines-strict true and it'll behave the way you're asking.

The reason that's false by default is that it made life unnecessarily difficult going from 0.6 to 0.8.

I think we can maybe get away with defaulting this to true for packages that have a node-gyp install script. That might be overly magical.

Another approach might be to say that it's strict by default, but only starting with Node 0.10. That is, if Node 0.6.0 would satisfy your requirement, then any version of Node <= 0.10 is accepted. Of course, then this is not only just magical, but a liar, which is pretty bad.

A third option is to make it strict by default, since no one uses this very much any more, as it's no longer the default in npm init.

What do you folks think?

[edef1c]

@isaacs making it strict would certainly necessitate a new major npm version, for one. I've seen people doing full x.y.z engines values, though. That's not a huge problem, but it's worth taking into account.

[isaacs]

Basically, I'd like to figure out a way that it prevents people trying to install binary addons that just won't work, but also doesn't encourage people saying that their little javascript lib only works with version 0.10.13-pre of Node.

[trevnorris]

On Jul 18, 2013 7:45 PM, "Isaac Z. Schlueter" notifications@github.com
wrote:

Basically, I'd like to figure out a way that it prevents people trying to install binary addons that just won't work, but also doesn't encourage people saying that their little javascript lib only works with version 0.10.13-pre of Node.

Well since native module developers are generally a small subset IMO we
could just be better about educating them on properly listing supported
engines and to use engineStrict. For support on master I've had to do this
since the API's changed so much between releases.

Since node-gyp does its little install magic building based on the version
of Node used to compile I thought it'd make sense npm would work similarly.
I'd love if when I typed npm install it would know to grab latest on my
repo's v0.2.x instead of latest v0.3.x since I'm installing with
v0.10-latest and not master.

I do understand the implications of developers not setting their engines
section correctly, but my thought was again if you're developing a native
module then you'll probably be more apt to pay attention to these things.

[aoberoi]

👍 for "engineStrict": true default.

my application specifies a dependency as "express": "^4.0.0". express' package.json has "engines": { "node": ">= 0.10.0" }, but doesn't have a value for "engineStrict". someone decided to run my application on node 0.8.x and has been successful for some time until just now when they finally used a feature of express that was not compatible with 0.8.x. if the default was true, this would have been picked up much earlier by us. i'm assuming this would have meant that since my package.json was not satisfiable npm would have yelled at us when the npm install was run.

[othiym23]

Since there was last serious discussion on this feature request, the CLI team has removed engineStrict from the CLI because it caused more problems than it solved. That said, this would still be a very useful feature for packages like the ones @trevnorris describes up top – packages that include native modules that are tied closely to the underlying V8 API, or that get out at the mutable edges of what nan provides.

To me, this feels like a problem that's external to npm itself, because it moves beyond the SemVer range-matching at the core of the install algorithm, and forces the installer to take into account other factors. The way this is done in practice right now is ad hoc scripts (like those used by the phantomjs installer) or using a tool like node-pre-gyp to get a prebuilt artifact for a give OS / architecture. This is even more general than that, because potentially you could get a completely different version of a package depending on what version of Node you're running.

I'm not opposed to integrating this functionality on principle, but it brings a set of concerns that are more familiar to me from OS distribution package managers than language-based package managers like npm, and the amount of complexity it adds is somewhat daunting, if you want to avoid engineStrict-style footguns / edge cases. Therefore, I've added needs-discussion to this, because I'm not sure how best to implement this, and I'm not ready to review changes to npm that do implement it until there's more of a consensus around how to do it. (An excellent way to drive to that consensus would be to write something that puts its data in package.json and run outside of npm.)

[trevnorris]

@othiym23 There are really only one of two ways I see it working exactly as I'd like. Either devs properly list supported module versions (which has shown not to be the case) or npm runs a giant test farm to test modules against all supported versions of node and catalogs which do/don't. Don't see either happening.

So how about a maybeEngineStrict that attempts to do the right thing and if it can't prints out a warning message like "no supported version found. either the module needs an update or the author doesn't know how to properly specify the supported range. please contact them." then installs package that it normally would.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.

[19h]

That is a very interesting way of increasing issue-resolve KPIs.