Spec for .nvmrc files?

[JoshuaKGoldberg]

Coming over from prettier/prettier#15898 -> un-ts/prettier#340: I'd like to auto-format .nvmrc files (i.e. just remove trailing whitespace). It'd be helpful for any Prettier plugin that does this to be able to refer to a spec for .nvmrc files. Is there anything like a specification that can be stated?

For now, I'm just going with "it's the same output as node -v" which ... is a little informal.

[ljharb]

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”.

[ljharb]

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?

[JoshuaKGoldberg]

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. 🙂

[ljharb]

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.

[RoestVrijStaal]

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.

[JoshuaKGoldberg]

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.

[RoestVrijStaal]

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.

[ljharb]

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