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!

👍

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 nodejs/version-management#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?

Here you go! #1625

Snark or no it's a fair point. It seems pretty clear .node-version is now a de-facto standard, if not a formal one, and NVM is the only notable holdout I can think of. @shadowspawn's node-version-usage repo linked above in several places lays out the case very comprehensively. There are plenty of actual W3C standards out there with far worse adoption than that.

All this has already been said before though; there's little point in repeating it ad infinitum. Upvote and move on.

Can anyone write a shell script to automatically load a.node-version file like a.nvmrc file in nvm readme？

Somehow both n and fnm are able to support both .nvmrc and .node-version files. I would love to not need to create both files, when using any of the many other tools that recognize .node-version. This seems like such an inconsequential thing, and absolutely improves the nvm user's experience, that it's pretty surprising to me that this discussion has been ongoing for almost 9 years. Whether there are ongoing discussions around what standards .node-version should take or not, it's already become a defacto standard for many libraries.

Add this to your .bashrc after your nvm configuration, and then run nvm-use when there's a '.node-version' file in your folder:

nvm-use() {
  # Print usage on -h or --help
  if [[ "$#" -eq 1 && ("$1" == "-h" || "$1" == "--help") ]]; then
    echo "Usage: nvm-use [nvm use options]"
    echo ""
    echo "- This function will look for a .node-version file in the current directory,"
    echo "  and run 'nvm use' with the version specified in that file."
    echo "- If no .node-version file is found, it will run 'nvm use' with"
    echo "  the arguments passed to this function."
    echo "- Note: This function might no longer be needed when this issue is solved:"
    echo "        https://github.com/nvm-sh/nvm/issues/794"
    echo ""
    echo "Options:"
    echo "  -h, --help    Show this help message and exit."
    return 0
  fi

  # Check for .node-version file and use its version if available
  if [[ $# -eq 0 && -f .node-version ]]; then
    local node_version
    node_version=$(<.node-version)
    node_version="${node_version//v/}" # Optionally remove 'v' prefix
    nvm use "$node_version"
  else
    echo "No .node-version file found. Falling back to 'nvm use' with default arguments."
    nvm use "$@"
  fi
}

Looks like every other tool supports simple .node-version except nvm
https://github.com/shadowspawn/node-version-usage?tab=readme-ov-file#compatibility-testing
Is the lack of specification the only reason?
There were good examples like JSON or markdown mentioned. Typescript also doesn't have active specification and still, it's wildly used
If everyone else agrees to the format, who is NVM waiting for?