nvm icon indicating copy to clipboard operation
nvm copied to clipboard

Feature Request: Unofficial builds

Open martin-braun opened this issue 2 years ago • 4 comments

@ljharb We recently talked about how it makes no sense to have a POSIX compliant installer, since on embedded systems you most likely need to compile node yourself, so the benefit of not installing bash is neglectable.

The reason why nvm doesn't work on Alpine Linux, is because the official builds are compiled against glibc, but there are unofficial builds for musl that should work.

It would be beneficial to have a way to define a different source for node versions, so that I can use nvm on Alpine in the first place.

node releases on the Alpine package manager are tied to repository branches, meaning accessing an older node version means to run an ancient OS as well. I'd love if you could look into it.

Related: https://github.com/nodejs/build/issues/1140

martin-braun avatar Feb 24 '23 04:02 martin-braun

Note: I put "PR wanted" on this, but I'm still very unclear about whether this can be added cleanly. I'd love to see a suggested implementation.

ljharb avatar Jun 02 '23 17:06 ljharb

That would be also very useful for RISC-V machines, I see that files like node-v20.5.1-linux-riscv64.tar.xz are available for download, but nvm still compiles everything from sources, which takes quite a lot of time.

Is there anything that can be done to speed up installs on RISC-V machines?

ilg-ul avatar Aug 21 '23 21:08 ilg-ul

FWIW, the override in https://github.com/nvm-sh/nvm/pull/3251 (which we're applying to our local install of nvm as a patch) is working well for us on CentOS 7, allowing us to install unofficial builds, check for updates etc. Without being able to add the linux-x64-glibc-217 suffix, it would not work at all.

Obviously this (being stuck on CentOS 7) is not a situation we want to be in long term, but for now this solution is preventing major dependency update headaches.

ehoogeveen-medweb avatar Jan 17 '24 07:01 ehoogeveen-medweb