Add unprefixed downloads for LTS lines?

[courajs]

It would be great to be able to download the proper platform binary for the latest of an LTS release.

At the moment, most release files are prefixed with the exact version number.

• https://nodejs.org/dist/latest-carbon/node-v8.9.0-linux-x64.tar.xz exists
• https://nodejs.org/dist/latest-carbon/node-linux-x64.tar.xz does not

So, I can't download the latest of the carbon LTS line for my platform, without already knowing that it's v8.9.0. This adds some extra steps to automated scripts trying to install an LTS version.

[fhemberger]

/cc @nodejs/build

[rvagg]

This has come up before and we agreed that it would be too messy and not add enough value to justify it. I wish I had an issue to link you to for discussion but I don't know where that happened.

The latest-* directories are symlinks, if we add additional files then we'll end up polluting the directory and then if we delete them when the next version comes we'll end up with broken links for people using the direct paths.

The index.json and index.tab files exist for you to determine exactly which files exist and which to grab. nvm and other version managers use it and it's not difficult to built your own script to use it. I have this in my ~/bin to do exactly this: https://gist.github.com/rvagg/742f811be491a49ba0b9

I'd recommend that this be closed unless you feel really strongly about it and want to make a case why it should exist and why our existing mechanisms don't suffice. In that case you should probably make an issue over in nodejs/build and the build team can discuss it as a group and perhaps come to a different conclusion to that which we've come to before.

[courajs]

@rvagg thanks for the explanation.
It is a little more awkward to use such a script via a Dockerfile, but still doable.
Perhaps this can just be kept in mind if things are ever being moved to a new system.

[gibfahn]

It is a little more awkward to use such a script via a Dockerfile, but still doable.

I find https://github.com/creationix/nvm quite useful for those situations.

[benjimin]

What is the recommended way of installing node for something like a CI/CD build script?

I think it would be extremely convenient if something like this worked:

wget -q0- https://node.js/current/lts/linux-x64.tar.gz | tar xz -C /usr/local/lib/nodejs --strip-components=1
export PATH=/usr/local/lib/nodejs/bin:$PATH

It's comparatively inconvenient to have to first install older (distro default) versions of node and npm, just to use those to reinstall node. Similarly, it's inconvenient to require a script to parse nodejs.org just to be able to ensure that the node version (either stable or LTS) installed by an automatic build script is always up to date with security/bug-fixes. (It would also look a lot simpler than the current linked instructions.)

I don't think it is very difficult to automate a few symlinks like this - it's probably a good task for a new contributor even, if this issue could be reopened? Otherwise, it would still be great if the site could document what the recommended instructions for noninteractive installs are? (That is, from scratch without manually enumerating latest version number.)

[rvagg]

https://nodejs.org/download/release/index.json and https://nodejs.org/download/release/index.tab are two formats that make it very easy to parse in bash or your language of choice.

You will also see symlinks at the top of https://nodejs.org/download/release/ for your favourite release line and named LTS lines.

Additional symlinks inside each release directory is going to increase the number of assets listed for download (we have lots of architectures, and gz + xz for each) - and mirrors aren't going to know the difference, so we have an explosion of downloadable resources. Doing this so that some people can trim a CI script down by a HTTP request is not really a good justification.

Grab index.json or index.tab and figure out what version you want to use, be intentional about upgrades between release lines, don't rely on auto-magic for version picking. If you need help scripting up parsers for these then just let us know and folks will help.

Here's a single line demo for one way of grabbing the current v14.x and unpacking it as per your example above, if it helps:

curl -sL https://nodejs.org/download/release/latest-v14.x/node-$(curl -s https://nodejs.org/download/release/index.tab | grep ^v14\. | head -1 | cut -d$'\t' -f1)-linux-x64.tar.xz | tar xJ -C /usr/local/lib/nodejs --strip-components=1

[benjimin]

@rvagg if you recommend that approach it would be great if that was documented, in the wiki page (linked as "install via binary archive")?

For my use case, my application is in a totally different language (python) and just one of the dependencies uses a node library. (My build script broke recently because that library started requiring a more recent version of node than what the most recent ubuntu LTS distributes, and npm ignored the engine requirement with barely a warning.) I'd like to update my automatic build script to just grab either the latest node LTS or even the latest stable node release, so I at least can be assured my security fixes are up to date, even when I'm not personally monitoring what major release number node is up to.

It seems a little excessively complex to need to maintain effectively a reimplementation of nvm, or install two versions of node, or any other bespoke piece of software just to install the current version of node. Complications or perceived inefficiency/difficulty discourage using node in projects that can avoid it.

/download/release/x.x/x.x.arch.format
/symlinks/current/latest/arch.format
/symlinks/current/lts/arch.format

What if we symlinked from inside the latest directory rather than symlinking that directory itself? The number of assets seen by mirrors would hardly change (since both the number of directories and the number of entries within are unchanged), and you could even change the top-level location (so that mirrors that don't support symlinks aren't pointed at it in the first place). The only difference is that half a dozen (rather than one) symlinks be updated upon major version increments. It would then also simplify the install instructions, if you expect most users to download the current version (they don't need to look up and specify the version number explicitly unless they want to pin to a specific version)?

curl -fsSL https://deb.nodesource.com/setup_lts.x | bash -
apt-get install -y nodejs

FWIW, I eventually found this method (linked a few levels under "install via package manager" in the docs).

Another option would be (and again, many may baulk executing downloaded third-party scripts):

curl -L https://github.com/raw/tj/n/master/bin/n -o n
bash n lts