Support musl-libc and android

[ntkme]

This PR adds support for musl-libc and android (and windows-arm64).

Because npm optionalDependenices only knows about generic linux, we have to install two variants on all linux system, and pick the correct one to run at runtime. It's not a huge problem other than waste some network bandwidth for download and a small amount of disk space.

Closes #263

[ntkme]

The biggest problem here is we must install both -gnu and -musl at the same time, as that is a limitation of optional dependencies. For the embedded host it is not an issue, as we can detect the runtime and pick one to use, however it is a problem for the cli, as now we have two packages trying to install a bin with the same name.

  "bin": {
    "sass": "./dart-sass/sass"
  },

One way to solve this is to use a wrapper script to run the same platform detection logic and then invoke the dart sass command. The problem here is that node does not have proper support for exec call that replaces the current process, so that the node js wrapper need to stay alive until the child process exit, which is a minor performance issue.

[nex3]

Do we need Node to have an exec? Since these packages are only ever going to be run on Linux anyway, could we have them ship a shell script to choose between them instead?

Also, does it make sense to have separate packages for glibc and musl, since they're both going to be installed anyway?

[ntkme]

Do we need Node to have an exec? Since these packages are only ever going to be run on Linux anyway, could we have them ship a shell script to choose between them instead?

It is unfortunate that the issue is closed without progress: nodejs/node#21664

Also, does it make sense to have separate packages for glibc and musl, since they're both going to be installed anyway?

We don't really need two packages, however the logic is simpler in this way because all the optional packages have the exact same structure.

[nex3]

It is unfortunate that the issue is closed without progress: nodejs/node#21664

I mean, what if we didn't make the frontend script Node at all, and just made it a shell script instead?

[ntkme]

I mean, what if we didn't make the frontend script Node at all, and just made it a shell script instead?

I that case I'm not sure how to support posix shell and windows shell at the same time, unless we to with combined gnu/musl package, and have the shell script doing the detection work, in which way we can still go with the existing approach that each optional package contains one shell script.

[ntkme]

Or I we can still use separate packages, but include a separate bash script for the linux (-gnu) package, and use that for command line. For -musl, there will be no command script. I think this might be the best compromise.

[nex3]

I that case I'm not sure how to support posix shell and windows shell at the same time, unless we to with combined gnu/musl package, and have the shell script doing the detection work, in which way we can still go with the existing approach that each optional package contains one shell script.

If it's enough easier to have separate packages for gnu/musl, you could also just say "the gnu package is the only one with a script and that script determines which actual executable to load".

[ntkme]

If it's enough easier to have separate packages for gnu/musl, you could also just say "the gnu package is the only one with a script and that script determines which actual executable to load".

I also had the same idea and we almost posted at exact same time :-)

[nex3]

Nit: document this (in particular why it works consistently)

[ntkme]

Added a comment

[nex3]

Thanks!

[ntkme]

@nex3 Any chance we can cut a release together with the current set of bug fixes, so that we can try it out and fix issues in the release pipeline if any.