N: Use .nvmrc with n

[spences10]

Hi,

Is there a way to use an .nvmrc file with n?

@gussyboy touched on it in another issue #423 but @JohnRGee seemed to be confused by the comment.

So, so there is no confusion around what I am requesting, I would like to know if it is possible to configure a project that uses node, to use a specific version of node. This sort of behaviour is possible *(as I understand it) with a .nvmrc file.

Is there a way to do this if I'm an n user and the rest of my team are nvm users.

Thanks

[shadowspawn]

I can see a limited but simple way to use .nvmrc with n, assuming version number specified in compatible way::

alias ni='n $(cat .nvmrc)'
alias nu='n use $(cat .nvmrc)'

[shadowspawn]

Configuring a project that uses node, to use a specific version of node, is complex. One option more in that spirit is: https://www.npmjs.com/package/node

[spences10]

Thanks, I'll try, closing this for now.

[shadowspawn]

On a related note, I have added support for reading a .node-version file in n 6.5.0.

616

Edit: changed to .n-node-version file in n 6.5.1

[adrianmcli]

@shadowspawn I appreciate the new feature, but there are many existing projects with .nvmrc files. I know that a non-tool specific dotfile would be more ideal. But to make it easy for people to transition from NVM to n, do you think maybe we can add the ability for n to be configured to read from .nvmrc as well?

Another convention I would like n to support is engines.node. It's just so commonly used that I feel like n is missing out by not supporting it (even if it has to be behind a feature-flag).

[shadowspawn]

1) .nvmrc is a propriatory configuration file for a specific node version manager. I don't think many people are going to transition from nvm to n, but a situation I am interested in is teams which may be using both and possibly other tools too. What I would rather support for cross-tool compatibility is .node-version, but I got some pushback on adopting that before it was a _standard_ (not from a user).

https://github.com/nodejs/version-management/issues/13

2) engines.node is a challenge because n is implemented as a shell script, and parsing json is non-trivial (I assume you are referring to the engines field in package.json). However, I am open to the idea. I suggest you open new issues for the ideas you care about to see if there is support for them from other users.

[adrianmcli]

@shadowspawn Thanks for the reply.

1. I understand the push for .node-version, but the fact is that .nvmrc is vastly more popular and as an avid n user, I (and many others) have run into problems when getting onboarded to projects with .nvmrc. Of course it's not something I couldn't deal with manually, but it's a huge hassle especially if you are switching in and out of projects on a daily basis.

   I understand the proprietary nature of .nvmrc might make it sound odd to support, but I don't see a downside to supporting something proprietary. For example, Google Docs support exporting of Microsoft Word files even as a direct competitor. And numerous non-Adobe graphic design software support reading and writing Adobe Photoshop and Illustrator files.

2. Understood, I will create a new issue for this specifically.

[shadowspawn]

1) To be clear, I am not completely against limited support for .nvmrc if there is demand for it. Since auto is an explicit opt-in target, I am ok with looking in multiple locations for the desired version and even "having a go".

[MarkLyck]

Please add support for .nvmrc 🙏

[shadowspawn]

New issues have been opened for:

• node.engines #618
• .nvmrc #625