Include missing information to have feature parity with /dist/index.json

[bnb]

currently, https://nodejs.org/dist/index.json has slightly more information than nv does. I'd like to replace using that API directly with using nv, but lacking that information is preventing me from doing that.

At present, the following are missing:

• date (release date)
• files (supported platforms/build output)
• modules version
• security (indicates if it is a security release)
• lts boolean ('is this a lts release')
• npm version
• v8 version
• libuv version
• zlib version
• openssl version

right now, only the lts boolean can be figured out by checking if "codename" is a version number or a string. this is... way more work than we should make people do.

my recommendation would be the following:

• include a releaseDate property that shows when the version was released (maps to date on the website)
• include a platforms or files property that is an array of the platforms there are builds for (maps to files on the website)
• include a dependencies property that is an object with properties that are names of dependencies and values that are version strings (maps to multiple dependency properties from the website)
• include a modules property that is a string with the module version (maps to the modules property on the website)
• include a security property that is either:
  • a boolean that tells you whether or not a release is a security release
  • is an object with multiple properties, including a boolean that says whether or not a release is a security release, a previous property that tells you what the last security release was, and so on.
• include an lts property that's either:
  • a boolean that tells you whether or not a release is an LTS release
  • is an object with multiple properties, including a boolean that tells you whether or not a release is an LTS release, lts codename if applicable, and maybe any other LTS information

[wesleytodd]

knocked a few of these out:

#28
#29
#30

Stacked the PR's because it was easier, but let me know if you disagree with any of these implementation wise. I will see about merging them later this week if you don't oppose them.

I can probably knock out the rest later but this is all I had time for today.

[wesleytodd]

@bnb I have a few questions:

include a modules property that is a string with the module version (maps to the modules property on the website)

AFAIK the modules key is the native module compatibility number or something like that. And I dont see a reference to that on the website, but maybe I am just looking in the wrong place?

is an object with multiple properties, including a boolean that says whether or not a release is a security release, a previous property that tells you what the last security release was, and so on.

I am not sure I understand the use case here. I can add it as you write it, but I would like to understand why first.

a boolean that tells you whether or not a release is an LTS release
is an object with multiple properties, including a boolean that tells you whether or not a release is an LTS release, lts codename if applicable, and maybe any other LTS information

I implemented the first option, but I think maybe upon revisiting this I missed it in the spirit you wanted. So the alias lts_latest is already the "current lts at this (or another) point in time". Now that I am re-reading this I think maybe you wanted if it was an lts at the time of release (subtly different).

Can you tell me what the use case is here other than the one we solve already with the lts_latest alias?