Extension host throws exception "Named export 'rgPath' not found." on RISC-V64 (installed by Open Remote - SSH)

[Release-Candidate]

Happens with both VSCodium 1.95.0.24287-insider and 1.94.2.24286. Client is MacOS ARM64, server is RISC-V64 Armbian/Debian Sid Linux.

Log entry - the full log file for 1.95.0.24287-insider is attached dda161016e115d6fa0fd302d2609be345b578a8b.log:

SyntaxError: Named export 'rgPath' not found. The requested module '@vscode/ripgrep' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@vscode/ripgrep';

Originally posted there: jeanp413/open-remote-ssh#173

[daiyam]

@Release-Candidate Have you changed the node executable on the remote server?
Which extensions do you have on remote?

@kxxt Do you have the same issue?

[KnappRoland]

These are the answers for the "insiders" version:

It uses Node v18.18.1 (you can see that in the log) that has been installed with (the remote) VSCodium, installed at .vscodium-server-insiders/bin/dda161016e115d6fa0fd302d2609be345b578a8b/node. The Node version installed globally is v20.17.0.

No Extensions on the remote host

cat .vscodium-server-insiders/extensions/extensions.json 
[]

[kxxt]

@kxxt Do you have the same issue?

Yes. I could reproduce it on 1.94.1.

I think that is probably caused by the mismatched nodejs version. riscv64 is using node 18 while others are still using node 16. There's no node 16 build available for riscv64 on https://unofficial-builds.nodejs.org/download/release/index.json and iirc node 16 is more buggy than node 18 on riscv64.

Not a direct cause of this issue, but BTW no ripgrep prebuilt binary is shipped for riscv64. I have tried to add riscv64 CI/CD to https://github.com/BurntSushi/ripgrep but there appears to be test failures that only happens in the cross-rs qemu-user that I cannot figure out.

[Release-Candidate]

I do have ripgrep installed as a Debian package (and Alpine has it too), so if you could use the globally installed one it should work, at least for now. A hacky workaround would be copying the rg executable to the path codium is expecting it (I guess .vscodium-server-insiders/bin/BLA/rg?)

% rg --version
ripgrep 14.1.1

features:+pcre2

PCRE2 10.42 is available (JIT is available)

[kxxt]

I do have ripgrep installed as a Debian package (and Alpine has it too), so if you could use the globally installed one it should work, at least for now.

Yes, you could symlink it to ~/.vscodium-server/bin/<COMMIT>/node_modules/@vscode/ripgrep/bin/rg but that's not what goes wrong here. The error here is that an import failure crashed the extension host.

[daiyam]

I've tested the server on macOS (node-v20) and linux x64 (node-v16, node-v18, node-v20) and I don't have the issue.

Can you try to replace your .vscodium-server-insiders/bin/dda161016e115d6fa0fd302d2609be345b578a8b/node with the node from https://unofficial-builds.nodejs.org/download/release/v20.16.0/node-v20.16.0-linux-riscv64.tar.gz (in bin directtory)?

[Release-Candidate]

Yes, thanks, I know about the Common-JS / ES Module problem. I just use enough Node.js to have experienced these myself.

Can you try to replace your

Will do and report back ...

[kxxt]

I've tested the server on macOS (node-v20) and linux x64 (node-v16, node-v18, node-v20) and I don't have the issue.

I tested by symlinking nodejs 22 binary from Arch Linux RISC-V and it works. And nodejs 20.16 from https://unofficial-builds.nodejs.org/download/release/v20.16.0/node-v20.16.0-linux-riscv64.tar.xz also works. So probably there's bug in nodejs 18 for riscv64.

For a new architecture like riscv64, in general newer nodejs means better support.
I think we can bump the nodejs version used for riscv64 to 20. But that appears to deviate too much from what vscode uses(16.x) and might in turn cause some new problems. I cannot think up other better solutions though.

[Release-Candidate]

Using either the globally installed v20.17.0 or v20.16.0 from the linked tar above does indeed work (no more exceptions and "search" works in files) after linking rg too.

Btw. there is a rg binary installed, but the x86 (32 Bit) version:

% file ~/.vscodium-server/bin/62f778783c52510c94e687de293bc2ad230f9a67/node_modules/\@vscode/ripgrep/bin/rg
/home/roland/.vscodium-server/bin/62f778783c52510c94e687de293bc2ad230f9a67/node_modules/@vscode/ripgrep/bin/rg: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=3c2f98d645e679912eaf08d8553096d505532ee0, stripped

[kxxt]

I opened PR #2061 to fix it. Let's wait for the CI.

Btw. there is a rg binary installed, but the x86 (32 Bit) version

Yes. Microsoft will fallback to assume the architecture is x86 32 bit.

[daiyam]

Btw. there is a rg binary installed, but the x86 (32 Bit) version

Yes. Microsoft will fallback to assume the architecture is x86 32 bit.

Is it because we aren't using a sysroot built for riscv64?

[kxxt]

Btw. there is a rg binary installed, but the x86 (32 Bit) version

Yes. Microsoft will fallback to assume the architecture is x86 32 bit.

Is it because we aren't using a sysroot built for riscv64?

No, that logic is hardcoded into @vscode/ripgrep package.

[daiyam]

No, that logic is hardcoded into @vscode/ripgrep package.

Ok, I see that there no case for riscv64 at https://github.com/microsoft/vscode-ripgrep/blob/e1773d7264e95fb02fba0f0e20029723d0cfa4b8/lib/postinstall.js#L40
Maybe you could make a PR there?

[kxxt]

No, that logic is hardcoded into @vscode/ripgrep package.

Ok, I see that there no case for riscv64 at https://github.com/microsoft/vscode-ripgrep/blob/e1773d7264e95fb02fba0f0e20029723d0cfa4b8/lib/postinstall.js#L40 Maybe you could make a PR there?

It won't do too much good until proper CI/CD is set up for ripgep itself, which I got stuck at.

[daiyam]

It won't do too much good until proper CI/CD is set up for ripgep itself, which I got stuck at.

The swap of the binary could done in vscodium workflow after the npm ci.

[kxxt]

It won't do too much good until proper CI/CD is set up for ripgep itself, which I got stuck at.

The swap of the binary could done in vscodium workflow after the npm ci.

Thanks for your advice. Would you accept a PR that builds the ripgrep for riscv64 in VSCodium? I think I can first try to make a PR to ripgrep to add CD for riscv64 without adding CI, though I don't really think that could be accepted by ripgrep.

[daiyam]

Thanks for your advice. Would you accept a PR that builds the ripgrep for riscv64 in VSCodium? I think I can first try to make a PR to ripgrep to add CD for riscv64 without adding CI, though I don't really think that could be accepted by ripgrep.

Yes, that's fine.