Skip to content

Conversation

@JappeHallunken
Copy link
Collaborator

I'm currently implementing https://github.com/louislam/uptime-kuma (I don't know if Stephan already asked you about it, I just started doing it) which depends on node.js.
For testing I did a lot of installing and reinstalling and every time I did this node.js was pulled and installed again, despite the fact that the current version is already present. So I added just some lines to do quick check to prevent this behaviour.

New behaviour:
If the currently installed version matches the newest node.js version the installation process is skipped.

@MichaIng
Copy link
Owner

MichaIng commented Jan 7, 2026

I am not 100% sure whether we should add this. For testing, of course the re-download of Node.js each iteration is unnecessary, but end users won't do it that often, so that the chance for a new Node.js release isn't low either. And the way it is now, a reinstall also repairs Node.js, if anything about the instance is broken, though node -v at least guarantees that node itself works to a certain degree.

In any case, the installer has a version-listing as well, which could be used:

./node-install.sh -l

This lists official as well as unofficial builds, which are currently needed for ARMv6 and RISC-V: https://unofficial-builds.nodejs.org/download/release/index.tab

And both would require a logic to obtain or filter the versions by official/unofficial builds based on arch. This would be actually easier to implement at the installer itself (which I maintain anyway): https://github.com/MichaIng/nodejs-linux-installer
Adding a node -v check to skip download&install if it equals the obtained latest version from official or unofficial builds based on input, is even less additional code than here. I could add a -f/--force or -r/--repair option for those who need it.

@JappeHallunken
Copy link
Collaborator Author

Agreed.
Not sure if a version check or a force/repair option is really necessary. Since it's rarely reinstalled in practice, adding those options might be more annoying than helpful during frequent testing. I think it’s fine as it is then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants