Spec for .nvmrc files? about nvm HOT 8 OPEN

Why

Only because I did not know that was possible! 😄

The spec should be modified to allow that and any other intentionally allowed version specifiers.

from nvm.

My hunch as someone who's never contributed to this repository or thought deeply about the space (😄) is that something short and to the point would work, provided it explicitly calls out what areas aren't yet solidified.

Using RFC 2199's nomenclature:

• .nvmrc files MUST contain an npm-style semver version string, such as 1, 1.2, or 1.2.3. This version string MUST be the first set of characters in the file, excluding an optional v.
• .nvmrc files MAY prefix their version string with a v.
• .nvmrc files MAY include a blank line after the version string.
• .nvmrc files SHOULD NOT include trailing whitespace around the version string. Doing so is undefined behavior not covered by this specification.
• .nvmrc files SHOULD NOT include additional lines after the version string. Doing so is undefined behavior not covered by this specification.

...I've never written a technical spec for a file format or syntax before. 🙂

from nvm.

Makes sense. I'll give it a shot over the next week or two, and will probably also ship an npm package to validate the file.

from nvm.

No, there’s no spec (just current behavior) and writing one without extreme care would preclude future enhancements, so I’m hesitant.

The next version of nvm will ignore trailing lines (ie, only regard the first line) but I’d like to extend it in the future so it can contain additional information.

The first line can contain any “version-ish”, iow, anything nvm use or nvm install or nvm exec etc will accept, which is much wider than “node -v”.

from nvm.

I suppose it's worth writing something up just do nobody does it wrong :-) for example anything that claims to support nvmrc but only supports version numbers, doesn't support nvmrc.

I have no idea what that kind of spec would look like, though. Any thoughts?

from nvm.

My hunch as someone who's never contributed to this repository or thought deeply about the space (😄) is that something short and to the point would work, provided it explicitly calls out what areas aren't yet solidified.

Using RFC 2199's nomenclature:

* `.nvmrc` files _MUST_ contain an npm-style semver version string, such as `1`, `1.2`, or `1.2.3`. This version string _MUST_ be the first set of characters in the file, excluding an optional `v`.

* `.nvmrc` files _MAY_ prefix their version string with a `v`.

* `.nvmrc` files _MAY_ include a blank line after the version string.

* `.nvmrc` files _SHOULD NOT_ include trailing whitespace around the version string. Doing so is undefined behavior not covered by this specification.

* `.nvmrc` files _SHOULD NOT_ include additional lines after the version string. Doing so is undefined behavior not covered by this specification.

...I've never written a technical spec for a file format or syntax before. 🙂

Why would i be disallowed to use

lts/iron

in .nvmrc?

It is a valid version what nvm ls-remote gives me, and it works without pain.

from nvm.

That's great.

BTW my apologies for butting into this discussion.

I would suspect the code of nvm ls-remote and the code which reads out .nvmrc use the same tokenizer to enumerate the version already? At least that would be possible with this spec.

from nvm.

Yes, i would make sure anything nvm supports is allowed, which includes custom aliases.

from nvm.