Semver range support

[alexkrolick]

I know the preferred way to reference ranges in nvm is with lts/name, but we've run into an issue when pkg.engines has to specify a minimum value for the minor version, ie >= 10.13.1. Without switching to an exact version, users who don't habitually update their nvm references will not get the memo to update to the minimum.

Allowing ^10.13.1 or something like that would allow a minimum version without capping the maximum version, which is desirable.

[ljharb]

pkg.engines is a range, altho it's often used in apps to target a single version.

nvm does not in fact support ranges - lts/ aliases target a single version out of a subset. lts/argon, for example, means v4.9.1, and only that version, full stop.

Is your use case for an app, or a package?

[alexkrolick]

The use case is for an app.

lts/argon, for example, means v4.9.1, and only that version, full stop.

Right, the problem is since it's a rolling pointer, if a dev doesn't update the reference using nvm install periodically, they can fall behind without knowing it. So if you rely on behavior from a minimal version in a release series specified in pkg.engines, and assume that lts/whatever will be the maximum of that release series, you can run into an issue when a local pointer is lagging. Hence the desire to increase specificity of the minimum version while still allowing a higher maximum version.

[ljharb]

I see - so if I understand correctly, you want a way in .nvmrc to say lts/argon but ALSO to say 4.9.1, so that if someone has a local lts/argon that's behind, they'll get a warning?

Note that any remote connection will update the local user - you could, for example, add to your app's preinstall script something like nvm version-remote node >/dev/null and it will silently update their local aliases, so that nvm use will report that the right node is not installed. Would that suffice?

[alexkrolick]

I see - so if I understand correctly, you want a way in .nvmrc to say lts/argon but ALSO to say 4.9.1, so that if someone has a local lts/argon that's behind, they'll get a warning?

Yes, but it seems fairly hard to express that with release codenames, so semver notation like ^4.9.1 or the equivalent >=4.9.1 < 5 would also work.

Note that any remote connection will update the local user

I suppose this works. It's not precise but I guess in combination with the engines field, the end result will be that devs roll forward whenever possible and can't install on less than the minimum version.

[ljharb]

Unfortunately to parse semver notation would require a very large and complex chunk of code in shell scripting, so that's not really feasible.

[alexkrolick]

I'll settle for documenting the workflow above, but I'll also propose this if it seems valuable to automate:

4.9.1 # installs just this

lts/argon # installs local pointer

min: 4.9.1 # same as just 4.9.1

max: 4.9.1 # same as just 4.9.1

max: lts/argon # same as lts/argon

min: 4.9.1
max: lts/argon # installs lts/argon unless it is behind min

min: 5
max: 4 # error

(I think the formal way is also better than automating the fetch using package scripts because some people may need to use the --reinstall-packages-from flag to properly update)

[ljharb]

We'd need to define semantics for min: 4.9, max: 4.9, etc; also, nvm doesn't track which versions used to be LTS - not sure if that'd be required.

[alexkrolick]

nvm doesn't track which versions used to be LTS - not sure if that'd be required.

I don't think it would be, you'd just turn the local lts pointer into a fully qualified version and see if it matches the constraint

[justsml]

What if the .nvmrc file specified a list of supported versions, and it used the first version to match locally installed versions:

14.12.*
14.19.*
16.*.*
12.17.*

If this is breaking change, then perhaps a .node-versions (plural) file would be appropriate?

[ljharb]

@justsml nvm doesn't understand stars like that, but 14.12, 14.19, etc would work. However, it would definitely be a breaking change.

Something with a non-nvm-specific name wouldn't be able to support nvm-specific ranges, like aliases, or 14.12 - it'd have to take full versions only.

[FranCarstens]

Using the following in .nvmrc works for us, but...

node-version = >=14.19.1||<15.0.0
engine-strict = true

We get a semver warning npm WARN invalid config node-version=">=14.19.1||<15.0.0". Any way to turn that off?

[ljharb]

@FranCarstens that's npmrc, not nvmrc, and that definitely will not work for nvm.

[ljharb]

(re engines.node, linking to #651)