Can all version managers be friends and support .node-version?

[orlando]

Related to nvm-sh/nvm#2096 (comment)

Currently, we add .nvmrc and .node-version files to our repositories. This is not an issue but I would love to see .node-version supported by others version managers. Personally, coming from Ruby, .node-version feels natural just like .ruby-version.

Feel free to close this issue if you are not ready (yet) to chat about this.

[nullivex]

I would be happy to add support in Nodist. I do not believe we currently have anything and I am brewing up a new version.

[ljharb]

The problem is that there's no common spec for .node-version files, and anything common across all the version managers would likely not be sufficient for all the features (aliases, LTS, release flavors like iojs vs node, etc).

The filename is ideal, but because some VMs have already started to use it, it's possible that even if we could come up with a common spec, that filename would be permanently tainted and we'd have to pick another name.

[nullivex]

@ljharb Thats a great concern. How about something like .nodev work a standard by finding common ground. Let the user-space remain in .node-version

Let me know.

[ljharb]

@nullivex i would absolutely encourage you - and every version manager - to not support .node-version, and to instead define its own custom file name and format. In parallel, we should all work together (in this working group, ideally) to document the intersection between all of the version managers' file formats, and try to encode those in .node-version, if possible.

[coreybutler]

Just wanted to post a reminder that some version managers do not support per-shell execution of Node (i.e. this file is unnecessary). Not opposed to documentation... seems like that would be a great first step.

[orlando]

Talking from a user perspective, I think is more than enough to just support what your version manager supports. Agreeing on a common spec seems harder to me and will require more conversations to have everyone agree.

Also, I'm not sure if it's worth it since the most common use case is to lock to a specific node version, like 12.10.0 for example, which all version managers currently support

I would like to see something like this and I don't think is hard to implement for everyone.

1. Prefer your specific custom file name over .node-version
2. Parse .node-version with the same logic as with your custom file name.

If later you all agree on a specific spec for parsing version files, it will still work for both custom and .node-version

[ljharb]

@orlando it would be trivial to add a script to keep multiple node version files in sync, and far safer for the ecosystem than just throwing up our hands and all interpreting .node-version differently.

If someone puts nvm-specific syntax in that file, then that effectively forces either that syntax not to be used there, or, it forces every other version manager to support that syntax. Unless every version manager who supports .node-version also is signing up to support the union of syntax that every other version manager supports, a common spec is the only path forward.

[orlando]

I think every version manager supports a subset of the features that are most commonly used. If I (as a user) need any other feature specific to a version manager, then I'll probably stick that version manager. Users can solve issues they have with .node-version on their end instead of passing that responsibility to the version manager. Also, is not that users have multiple version managers installed or are changing these all the time.

You are right that keeping the two files is trivial, I mentioned that when creating this issue, but I also feel we are overcomplicating things here. If y'all feel that is needed to create a spec on how version files are parsed before supporting other file names like .node-version, I respect that.

Thanks for taking the time, feel free to close this issue.

[ljharb]

I think this is basically a duplicate of #13 anyways, so I will close it now that it's been discussed :-)