Added latest.json file that contains the latest versions

[martinheidegger]

I didn't find a good way to figure out programmatically what the latest version of node.js is. So it thought it might be good to be able to have it directly on the nodejs homepage as a json file that people can parse to see what the latest versions/lts versions are. In case some writes a nice cli tool like n or nvm

[phillipj]

Have you seen the node-version-data package we depend on to load the latest versions?

[martinheidegger]

I have not seen it but: https://nodejs.org/download/release/index.json does not contain (precomputed) the latest tagged versions which makes it hard for bash scripts and other non-node code

[martinheidegger]

I changed the PR to underline my point better: The latest.json now only contains the latest stable & lts versions. This should reduce the amout of data read from nodejs.org and increase both the speed when downloading (and processing) the data as well as making it easier to read the data.

[phillipj]

Could we extract the logic related to latest versions into its own npm package? Or maybe a new method on node-version-data @rvagg?

I'm really hesitant turning our internal data model, used by our templates, into a .json file that others around the world could depend on. We should be able to completely refactor our internal data model whenever we want, without worrying about breaking things for other users and projects.

[fhemberger]

@phillipj 👍

[martinheidegger]

It is important to me that the nodejs homepage (and community) decides what constitutes "stable" and "lts". The way - the authority - on how it is decided atm is specified in the latestversion.js. If node-version-data were to offer a getLatest functionality I would still base that method on data provided by the nodejs.org homepage.

[phillipj]

Absolutely agree with you! Sorry for not being explicit earlier, but we would ofc throw our latestversion.js in favor of the extracted npm module / getLatest() in node-version-data.

nodejs.org dont benefit from having custom logic related to resolving LTS and Stable, we just haven't seen the need to publicly expose it, until now with this PR. On the other hand we have our internal data model in the source object which are, and should still be, custom tailored to our website templates. If we want to redesign or change that data model in any way, we shouldn't have to worry about external usage of that

[thefourtheye]

does not contain (precomputed) the latest tagged versions

Can you please point out what is actually missing there?

[martinheidegger]

@thefourtheye https://nodejs.org/download/release/index.json does not contain a clear flag or identifier for the latest stable or lts version.

Just to clarify again: It can be "computed" quite easily but at the moment A) it has to be computed, which takes time and coding effort and B) it doesn't allow us to freely specify what we think is the latest lts or stable release. Also: The release/index.json is quite large (and will presumably grow in future) which costs bandwidth and download speed

[phillipj]

@martinheidegger would extracting the logic into a new or existing npm package as I have described, suffice at first?

[martinheidegger]

There are plenty of ways that would "suffice" but none of them is even closely as straight-forward as this one.

[phillipj]

There are plenty of ways that would "suffice" but none of them is even closely as straight-forward as this one.

Alright... I do appreciate you raising this issue, I'm sure there are lost of other devs that would appreciate an easy way to resolve current LTS/Stable versions. On the other side I would appreciate if we could keep this constructive to find the best solution for all of us.

What if latest.json existed on https://nodejs.org/dist/ as index.json does?

[martinheidegger]

Would be fine to me.

[rvagg]

-1 from me here and in the related issue in build:

1. The data is redundant, it exists in index.json and can be computed from that. Let's add something to node-version-data if this shorthand really is required
2. nvm et. al. have not expressed concerns about index.json, it seems to be serving their needs, particularly since we added the lts property.
3. There will be overlapping LTS versions, in a couple of years we'll have 3 of them, each valid as production targets, we can't be 1:1 about this.
4. This introduces new API that we will be stuck with supporting forever, we already have enough legacy API to support on nodejs.org and I'm not a fan of adding new surface area that we have to consider every time we want to revamp.

[martinheidegger]

@rvagg I respect your opinion a lot (my first instinct was to just close this PR), but let me address your arguments one by one:

1. In the current PR the data would indeed be partially redundant but If it were to look like this:

   {stable: '5.0.0', lts: '4.2.1'}
   

   it would only contain the exact information of which release is officially the latest stable and latest lts release minimal and additionally to the existing information.

2. Not sure where this relates to nvm (afaik it doesn't support latest) but n has a custom implementation that also looks to be not in-line with the nodejs.org homepage. Maybe the first case of needing to fix?

3. The file in this PR is called latest.json indicating that it contains only the latest stable and lts version. Even when there is more than one lts version at some point it will still just contain the latest lts version.

4. Maintaining a file with two variables over maintaining a package in npm? I would always choose the file.

Background: I made this pull request as preparation for a tool that checks whether-or-not the latest version of node is installed on computers. If such a tool becomes main-stream this API very possibly might be called a lot more often than currently the index.json. Possibly resulting in heavy bandwidth use and to reduce the global need of computation speed.

[thefourtheye]

@martinheidegger I edited the text to include bullets. Hope that is okay :-)

[martinheidegger]

@thefourtheye thx

[jbergstroem]

For me this boils down to:

• missing functionality but (quote) It can be "computed" quite easily versus
• maintaining a new api, probably forever

Adding new api's should be done with care. Am also -1 (if this is a vote).

[rvagg]

also fwiw @martinheidegger there is an index.tab as well, I use that exclusively for non-Node code that needs to fetch this, e.g. I get the latest version with:

latest=$(curl -sL https://nodejs.org/download/release/index.tab | \
  awk '{ if (!f && NR > 1) { print $1; f = 1 } }')

you could do the same but for only LTS since it's a column in there

latestLTS=$(curl -sL https://nodejs.org/download/release/index.tab | \
  awk '{ if (!f && NR > 1 && $10 != "-") { print $1; f = 1 } }')

When there are multiple LTS' then you could just check for the version by name, e.g. Argon

latestArgon=$(curl -sL https://nodejs.org/download/release/index.tab | \
  awk '{ if (!f && NR > 1 && $10 == "Argon") { print $1; f = 1 } }')

[phillipj]

As exposing latest.json has been down voted one way or the other, adding a method in node-version-data or extract it into its own module, seems like the only options left. Would that be helpful for you @martinheidegger or is it latest.json or nothing?

[fhemberger]

@martinheidegger What about @phillipj's suggestion? Would that be helpful? Is the change still needed or can we close this PR?

[martinheidegger]

Sorry for not having answered to to that issue. node-version-data works but is pretty slow here and not really much fun. I wouldn't use or trust a module that does it and just rely one one-data-source of truth. As such I will have to learn to live with node-version-data.

Note: I closed the issue because I don't have the time or energy to invest in this. Feel free to reopen