Nvm: Honor .node-version file

Created on 4 Aug 2015  路  27Comments  路  Source: nvm-sh/nvm

Forgive me if this has been discussed before, but I didn't find anything beyond https://github.com/creationix/nvm/issues/110#issuecomment-40525629.

It would be really nice to see the various Node version managing tools coalesce around a common "version config file", analogous to Ruby's .ruby-version for RVM and rbenv - .node-version. This would basically just be an alias for .nvmrc, since that functionality's already been added. Since n already supports .node-version, this would make it so that regardless of the Node version manager used, there could be some degree of guarantee that the correct version will be used.

feature requests

Most helpful comment

All 27 comments

When did n add support for node-version?

Which would win if you had both files present?

What about the different version formats that nvm supports - ie, iojs, stable, node, or 0.10, etc - and how do other version managers interact with those? What special formats do they offer that nvm might be forced to interact with?

When did n add support for node-version?

Ah sorry, my mistake, it wasn't n - it's avn and nodenv. I actually asked the Stack Overflow question about this awhile back.

Which would win if you had both files present?

I think I'd expect .nvmrc to win if both files were present, but I don't really have strong feelings about this.

What about the different version formats that nvm supports - ie, iojs, stable, node, or 0.10, etc - and how do other version managers interact with those? What special formats do they offer that nvm might be forced to interact with?

That's a good question - I'll have to research this a bit.

I'd never heard of nodenv, but avn alone isn't enough for it to be a "common" version file. Do note my answer on that question which I think is a bit better than the accepted one http://stackoverflow.com/a/29545541 :-)

+1

Rapid, per-project .ruby-version switching with rvm is too useful _not_ to have this for Node.js!

:+1:

I think the idea here is that even though .nvmrc already provides this functionality, having a more generic cross-implementation .node-version file would be beneficial.

As @ljharb pointed out though, interoperability here would require more than just a common filename. iojs, stable, node are also valid version numbers for nvm, but not necessarily for other implementations. I'm honestly not sure how that should be handled. Maybe some discussion with the maintainers of other node versioning-type projects is in order...

If all of nave, n, avn, and whoever else all wants to cleave to nvms "version-ish" format, or, at least is prepared to accept or reject it gracefully (for example, supporting a version number but not a generic tag), that's great. Note that soon I'll have release candidate support for io.js and node, and these will have a different prefix as well, and who knows what the future will bring?

Just for .nvmrc files - https://github.com/lalitkapoor/nvm-auto-switch - I appreciate any feedback. Thanks!

Please use github reactions on the original post rather than posting "+1". Fair warning, I'll clean up existing and future comments that simply say that.

If all of nave, n, avn, and whoever else all wants to cleave to nvms "version-ish" format, or, at least is prepared to accept or reject it gracefully (for example, supporting a version number but not a generic tag), that's great.

That's not a problem, at all...

nvm could use .node-version as an alternative, but still giving preference to .nvmrc.

Project owners could decide to use a wider syntax on .node-version (just the version number, which, I think, it's most of cases) to allow use of any version manager OR use a specialized syntax and prefix on .nvmrc.

I don't even think nvm should care about which file is in use, but just parse .nvmrc or .node-version (in this order).

I'm not sure if I even like this idea, but a generic approach to "supporting" node-version directly might be to support a syntax in nvmrc that allows people to read the version string from any other file.

// .nvmrc
file:.node-version

// .node-version
6.3.1

This approach does have some pleasant side effects:

  1. No chasing additional version "standards" once the precedent has been set by supporting .node-version
  2. No questions of precedence
  3. No need to hardcode any subtle differences in support between the two standards since you're essentially making the assumption that the other file is compatible with nvm rather than the other way around.

That's not a half-bad idea. However, file:.node-version is a valid alias name, so it'd probably have to be something with a slash in it.

I'll think about that one more.

.node-version is a much more sane name than .nvmrc

furthermore, I don't see why it shouldn't support both

@TylerBre please don't use ableist terms like "sane".

node-version would work if it was a universal version identifier. However, nvm supports io.js, and aliases, neither of which are necessarily "node" or "universal".

Even though nvm support io.js, .node-version would still be relevant. And to be fair, nvm stands for "node version manager", and io.js isn't node, it's node compatible. That being said, I think it should be possible to honour .node-version for node versions, and maybe then also support .iojs-version, if that's still relevant for someone.

io.js is node, versions 1-3, after the fact.

You're also missing the most important part, which is "aliases".

The purpose of .node-version is that you want a static, consistent version. Specifying an alias would defy that purpose.

I agree - which would mean that nvm respecting node-version would have to be limited to static versions only.

What do avn and nodenv support in node-version files? If it's just "a static version, with or without a leading v" then the possibility still remains open that nvm could support that too.

nodenv differentiates between node and iojs with definitions like 0.10.36 and iojs-1.0.0 (as seen in their README). And it requires that exact version to be installed.
Installing of that version can be done by running nodenv install (with the node-build plugin added).

Does nodenv work if you do have a v prefix? (does rvm support the v in .ruby-version?)

My assumption was it wouldn't work with the v prefix, but it does:

$ cat .node-version
v5.12.0
$ nodenv version
5.12.0 (set by /Users/koenpunt/.../.node-version)

rvm I don't know, but rbenv does, as is about the same as nodenv (nodenv is a port of rbenv)

That's encouraging - it means we could support v1.2.3 or 1.2.3. I'm hesitant to include the "iojs-" prefix, though, since there's no overlap with node - unless every other node version management tool supported it too.

Either way I've filed https://github.com/nodejs/version-management/issues/13, and I think this issue should be blocked on that.

I just swung by to leave an issue and see if there was any interest in this, but looks like there is!

RVM and rbenv both have their own files and formats but both agree on .ruby-version, and it would be lovely if nvm and nodenv could agree on a common file too, even if nothing changes by default.

Here's how RVM load the file:

.rvmrc - shell script allowing full customization of the environment,
.versions.conf - key=value configuration file
.ruby-version - single line ruby-version only
Gemfile - comment: #ruby=1.9.3 and directive: ruby "1.9.3"

So, we could very easily add another function to check for .node-version if there is no .nvmrc, agreed?

I'd never heard of nodenv, but avn alone isn't enough for it to be a "common" version file.

fnm also supports .node-version

https://github.com/fisherman/fnm/blob/503b07d3b419908409373699c227c4baf32b4b7b/functions/__fnm_read_fnmrc.fish#L4

+1 would love this, colleagues and I use different version managers - the support will help keep us in sync.

.node-version is also supported by the nodejs plugin for ASDF, a universal version manager (nodejs, ruby, etc etc)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

danielepolencic picture danielepolencic  路  4Comments

swateek picture swateek  路  3Comments

goalidea picture goalidea  路  3Comments

ksmithut picture ksmithut  路  3Comments

gsklee picture gsklee  路  4Comments