Repository navigation
Include missing information to have feature parity with /dist/index.json #19
Description
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
releaseDateproperty that shows when the version was released (maps to date on the website) - include a
platformsorfilesproperty that is an array of the platforms there are builds for (maps to files on the website) - include a
dependenciesproperty 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
modulesproperty that is a string with the module version (maps to the modules property on the website) - include a
securityproperty 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
previousproperty 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
Activity
wesleytodd commentedon Oct 17, 2023
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 commentedon Oct 19, 2023
@bnb I have a few questions:
AFAIK the
moduleskey 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?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.
I implemented the first option, but I think maybe upon revisiting this I missed it in the spirit you wanted. So the alias
lts_latestis 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_latestalias?