vercel / resolve-node

API endpoint to resolve an arbitrary Node.js version with semver support

resolve-node.vercel.app

API endpoint to resolve an arbitrary Node.js version with semver support. Useful for shell scripting.

# Resolves the latest Node.js version by default
$ curl https://resolve-node.vercel.app
v13.0.1

# The special `lts` path resolves latest Long Term Support (LTS) version
$ curl https://resolve-node.vercel.app/lts
v12.13.0

# LTS version resolution by code name via `lts/:codename` is also supported
$ curl https://resolve-node.vercel.app/lts/dubnium
v10.17.0

# Semver is also supported
$ curl https://resolve-node.vercel.app/8.x
v8.16.2

# Restricting to security-only releases is also supported
$ curl https://resolve-node.vercel.app/lts/dubnium?security=true
v10.16.3

resolve-node's Issues

proposal: support limiting results to security releases

Back in May, the node.js Releases team added a new security property to the index (nodejs/nodejs-dist-indexer#9).

The property is a boolean that indicates if the release is a security release, which is useful for a few reasons (many described in nodejs/Release#437 (comment)); the one that I believe justifies adding functionality to resolve-node is this one (emphasis mine):

Theoretically, developers (us included!) could use this in a few ways:
...

• loop over every release in a release line until they encounter true – when they encounter true for the first time, they know that version is the minimum secure version

The proposal is to add support for a security query param on all endpoints that causes the eligible list of versions to be filtered by security === true before applying the maxSatisfying() query.

eg:

$ curl https://resolve-node.now.sh/lts/dubnium
v10.17.0

$ curl https://resolve-node.now.sh/lts/dubnium?security=true
v10.16.3

This tells us that, at the time of the query, anyone running Dubnium < 10.16.3 is on a known, potentially insecure version.

what do y'all think? should I whip together a PR?

proposal: support LTS codename resolution

One of the reasons I first reached out re: this project was to investigate the feasibility of supporting LTS codename resolution --this is something that comes up every now and then and there are various ad-hoc / bespoke packages that attempt to provide this functionality --usually in a manual / poorly-maintained manner.

The proposal is to implement /lts/:codename and /?tag=lts/:codename such that all backwards compatibility is completely preserved and arbitrary LTS release versions can be resolved by codename; eg, as of this moment:

/lts/dubnium  === /?tag=lts/dubnium  ==> v10.13.0
/lts/carbon   === /?tag=lts/carbon   ==> v8.12.0
/lts/boron    === /?tag=lts/boron    ==> v6.14.4
/lts/argon    === /?tag=lts/argon    ==> v4.9.1 

I think resolve-node.now.sh is an excellent candidate for supporting codename resolution; it already does the right thing by using the official dist manifest as the source of truth and is deployed on a highly available CDN.

What do y'all think? Alright if I PoC this and submit for code review?

Thanks again for the great community support on this, for willingly open sourcing the project, and, obviously, for hosting such a useful utility for free on the now CDN. 😃