It looks like the docker official images already builds this out for us https://hub.docker.com/layers/node/library/node/current-alpine3.15/images/sha256-b023d2de41e78d9665ab51fd378250fa2901e7ad321871a54ab60ed347389f0e?context=explore

Would @nodejs/docker images consume these binaries if we produced them here?

And, is there much of an audience for this? I already probed at this question in #50. It seems reasonable to me that there might be a growing audience for this kind of thing. Maybe we have Docker image numbers to suggest audience size?

@mollux I assume you're one of those people, can you talk about your use-case a bit?

Currently, only the x64 builds from here are special cased https://github.com/nodejs/docker-node/blob/1b70b5dfb424d67c8e0b0badb985aedf43a2227a/Dockerfile-alpine.template#L11-L26 but it's possible it could be done for arm64. Not sure if it would need to be arm64v8 vs arm64 or if that's implied

I'm guessing it's OK from https://github.com/nodejs/docker-node/blob/1b70b5dfb424d67c8e0b0badb985aedf43a2227a/Dockerfile-debian.template#L13

@rvagg

our use case

Our use case is that we have a custom image (based on php:cli-alpine) where we install the theia editor to have an in-browser IDE to develop / compile / without a local IDE.

One of the tasks to perform is to compile frontend themes, where we require nodejs.
We use nvm to install multiple versions (for some old projects we are updating we still need nodejs 10).

On amd64 we use the pre-build version from unofficial builds, hence the PR to be able to do the same for arm64.
We have this use case as we are switching more and more of our laptops to Macbook M1.

I currently use a self-managed location where we host the compiled versions and the index.tab, but ideally they are all hosted on an official unofficial location :)

use the binaries in the nodejs-docker images

It looks like there is not much change needed to use the arm64 binaries if they are available.

• Add arm64 logic to the template
  https://github.com/nodejs/docker-node/blob/main/Dockerfile-alpine.template#L13

• Add the checksum discovery to the update script
  https://github.com/nodejs/docker-node/blob/main/update.sh#L156
  https://github.com/nodejs/docker-node/blob/main/update.sh#L164

• Update files where architecures are mentioned
  https://github.com/nodejs/docker-node/blob/main/architectures
  https://github.com/nodejs/docker-node/blob/main/versions.json

hi @rvagg

is there anything I can do on my side to move this PR forward?

hey @rvagg, any news on this? anything we can do to help?

in our company, we use docker with a custom alpine base image. having prebuilt binaries would help us have multiarch images rather sooner & quicker than building from source

@acifani there are already prebuilt Alpine images on dockerhub through the official node image

@acifani there are already prebuilt Alpine images on dockerhub through the official node image

Hey @nschonni, thanks for the heads up! Unfortunately that doesn't work for us because we need to use our own Alpine base image, so we can't depend on the node alpine image directly 😞

I am facing a similar scenario as @acifani. I am required to use a specific alpine base image and need to install node 18 with musl support.
@rvagg can you make some time to merge this?

This would enable Node.js to run on mobile devices like the PinePhone and PinePhone Pro running Alpine-based PostmarketOS and open up new possibilities for the use of such devices in education and elsewhere.

Is there anything we can do to help get this merged @rvagg? :)

@rvagg @nodejs/build @nodejs/docker could you take a look?

@rvagg need this for cloud provided arm64 server

let's just deploy and see what happens eh? will report back if there are errors and this needs to be backed out, disabled or whatever and has to be fixed

Nope:

• https://unofficial-builds.nodejs.org/logs/202302192326-v18.14.1/arm64-musl.log
• https://unofficial-builds.nodejs.org/logs/202302192347-v16.19.1/arm64-musl.log

I think I can leave this in place for now while it gets fixed as it shouldn't disrupt other builds, but it'll need to get fixed or reverted soon please. @mollux are you able to take a look at this and figure out how to address it?

Maybe nodejs/node#45756?

reverting in #70

I believe this can be reopened after nodejs/node#51256 got merged. Probably have to wait for the fix to land in the release branches first though. Do you want me to create a separate issue?

It would be best if you would open a fresh PR