REH on linux: auto-download correct NodeJS

[daiyam]

Hi,

Due to compatibility with older libc, REH is still using Node-v16.

I was wondering if it will be good idea:

• to not bundle-in the executable node
• to auto-detect the correct version based on the installed glibc
• download the correct nodejs

@GitMensch @lex-ibm @jeanp413 Would that be ok for you?

Related Issues: #2021 #2125

[GitMensch]

So for REH you'd adjust the start script to do something like node --version and if it isn't working download the right one, once, putting it under bin?

That would work and also allow for system installs from the package manager (or is there aa problem with that), correct?

The only downside is that a REH install consists of two downloads - to support all contexts care must be taken to also allow a manual download of the node parts.

... but then again: why not just bundling the glibc-217 version in general? After all it is included in the "official unofficial releases" - https://unofficial-builds.nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64-glibc-217.tar.xz (it is still included in v23 so we should be able to just drop the matching version in)
I'd prefer that over manually downloading at each install/update.

As another alternative, we could package two REH builds, one x64 and one x64-glibc-217.

[daiyam]

... but then again: why not just bundling the glibc-217 version in general?

Only x64 has an unofficial glibc-217 version but that could work for that version.

The only downside is that a REH install consists of two downloads - to support all contexts care must be taken to also allow a manual download of the node parts.

I was thinking to activate the download of node only it's not present. So it can be done manually before the server is launched once.

[jeanp413]

What's the plan for vscodium once vscode drops official support in February?

I would go the same way vscode does, here's the discussion issue microsoft/vscode#206790
Basically just create another bundle with -legacy suffix that has old version of node, the server bundle already contains a check-requirements-linux.sh script, I need to update the remote extensions to call that script first and based on the exit code download the legacy server as fallback when exit code is 100

[daiyam]

@GitMensch Following #2157, I was wondering if the startup script should do the following steps executed when the node file isn't present:

• if VSCODIUM_SERVER_NODE env variable exists
  • symlink node to the value of that variable
• if not:
  • auto-detect the correct version based on the installed glibc
  • download the correct nodejs

I will try to work on it this week-end.

[GitMensch]

Now I see the use even more - note that the "if not" and download may not be that useful if we don't have special REH versions, like in the related issue that uses bionic - and all node modules distributed are linked against glibc - so the build won't be usable even with the "right node version".

I guess the use-cases of bionic (=android) and musl (mostly containerized environments) are too small to create special REH versions of that, right?

[daiyam]

Now I see the use even more - note that the "if not" and download may not be that useful if we don't have special REH versions, like in the related issue that uses bionic - and all node modules distributed are linked against glibc - so the build won't be usable even with the "right node version".

You are right. The remote console needs to work with node16, if not it's useless.

I guess the use-cases of bionic (=android) and musl (mostly containerized environments) are too small to create special REH versions of that, right?

Alpine has its own REH version (use node 20.18)

No, I'm fine to have special REH versions. It's just that you will need to create the PR ;) since I can't test on all platforms.

[lex-ibm]

Is the node at the root of REH the only binary that needs to be symlinked? I did that with nodejs 18, 19, and 23, and I can't get a terminal.

[daiyam]

You should have been fine since PPC64 use node20 unless the binary of node-pty isn't a PPC64 binary.
Con you check /node_modules/node-pty/build/Release/pty.node and /node_modules/node-pty/build/Release/spawn-helper?

[lex-ibm]

Doesn't look like there is a spawn-helper binary

❯ file node_modules/node-pty/build/Release/pty.node
node_modules/node-pty/build/Release/pty.node: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, BuildID[sha1]=58daf4d88c2aa4e95b9334243664843ce986fed8, not stripped
❯ file node_modules/node-pty/build/Release/spawn-helper
node_modules/node-pty/build/Release/spawn-helper: cannot open `node_modules/node-pty/build/Release/spawn-helper' (No such file or directory)
❯ find . -name spawn-helper

[daiyam]

Hum, maybe try their example usage from https://github.com/microsoft/node-pty

[daiyam]

I've updated to node-v20 since more dependencies requires it,

• x64 use the glibc-217 variant

So there won't be any nodejs download.

[GitMensch]

But VSCODIUM_SERVER_NODE is still on the table, replacing the distributed node binary with a symlink to a system or user install?

[daiyam]

Do you need it?

What about replacing:

"$ROOT/node" ${INSPECT:-} "$ROOT/out/server-main.js" "$@"

with

if [[ -f "$VSCODIUM_SERVER_NODE" ]]; then
  "$VSCODIUM_SERVER_NODE" ${INSPECT:-} "$ROOT/out/server-main.js" "$@"
else
  "$ROOT/node" ${INSPECT:-} "$ROOT/out/server-main.js" "$@"
fi

Would that be fine?
I could add it to the Insiders version so you could test it.

[GitMensch]

That should work (but note: I don't run insiders) - if we document how to set this variable in the server environment.