Arch Linux User Repository

NOTE: If you are building in a chroot, make sure package systemd-sysvcompat is installed on your system, as this is required for nvm. This cannot be included in the dependencies, since it will break on non-systemd distributions.

Of course it would conflict extra/code. But most people won't install VSCode if they already have VSCodium :-)
Wasn't a request to this package. Just wanted to share my workaround since VSCodium hasn't a dedicated ArchWiki page.
Haven't thought about putting it in ~/.local/bin. Thanks. Applications still may ignore the PATH variable and just look into the known binary folders. Who knows. But I'll test that on UE5.

@sausix that would make this package conflict with extra/code, which is not necessarily desirable. You could make a separate package that depends on this package but provides and conflicts with code that has that symlink, or just make it manually as you already have (although I would recommend placing the symlink in ~/.local/bin instead).

Create a symlink to get VSCodium being detected by other software. Worked for me on Unreal Engine: ln -s /usr/bin/vscodium /usr/bin/code

I tried installing and got the following error:

yarn install v1.22.21
warning Skipping preferred cache folder "/.cache/yarn" because it is not writable.
warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-61330".
$ node build/npm/preinstall.js
warning Cannot find a suitable global folder. Tried these: "/usr/local, /.yarn"
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning "@microsoft/1ds-core-js > @microsoft/applicationinsights-core-js@2.8.15" has unmet peer dependency "tslib@*".
warning " > gulp-postcss@9.0.0" has unmet peer dependency "postcss@^8.0.0".
warning " > tsec@0.2.7" has unmet peer dependency "@bazel/bazelisk@>=1.7.5".
warning " > tsec@0.2.7" has unmet peer dependency "@bazel/concatjs@>=5.3.0".
[4/4] Building fresh packages...
warning Cannot find a suitable global folder. Tried these: "/usr/local, /.yarn"
error /var/cache/private/pamac/vscodium/src/vscode/node_modules/@parcel/watcher: Command failed.
Exit code: 1
Command: node-gyp-build
Arguments: 
Directory: /var/cache/private/pamac/vscodium/src/vscode/node_modules/@parcel/watcher
Output:
gyp info it worked if it ends with ok
gyp info using node-gyp@9.3.1
gyp info using node@18.15.0 | linux | x64
gyp info find Python using Python version 3.11.6 found at "/usr/bin/python3"
gyp WARN install got an error, rolling back install
gyp ERR! configure error 
gyp ERR! stack Error: ENOENT: no such file or directory, mkdir '/.cache'
gyp ERR! System Linux 6.5.13-1-MANJARO
gyp ERR! command "/var/cache/private/pamac/vscodium/src/.nvm/versions/node/v18.15.0/bin/node" "/var/cache/private/pamac/vscodium/src/.nvm/versions/node/v18.15.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /var/cache/private/pamac/vscodium/src/vscode/node_modules/@parcel/watcher
gyp ERR! node -v v18.15.0
gyp ERR! node-gyp -v v9.3.1
gyp ERR! not ok
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Error: EROFS: read-only file system, open '/.yarnrc'

Sorry if this appears a bit off-topic: I am now the maintainer of vscodium-electron (which uses system electron) and I have updated it. Check comments and commit logs for details.

Using the system electron can break some plugins (like https://github.com/zokugun/vscode-sync-settings/issues/53).

The main objective of VSCodium is to provide an as close as possible version of Visual Studio Code without MS tracking... This version will stay with the included electron

But I could look into the vscodium-electron version. Maybe we could maintain it. Feel free to make any PR, it will be helpful.

By the way, the newer version delay is due to https://github.com/microsoft/vscode/issues/197976

While I would personally prefer to use system electron, I think that this package should keep bundling electron unless vscodium officially supports doing it differently. Would be nice to have vscodium-electron be maintained again though, and I'll probably switch over when it is.

Do you consider making this dependent on the system's electron instead of the electron shipped with vscode?

A discussion (5-years ago) is here talking about the rationale:

Isn't electron meant to be used in this way anyway? You have it on your system once, and everything that wants to use it shares it, rather than having it multiple times.

Clearly this isn't the way it's used in practice, as many projects bundle a copy of electron. It seems like allowing code to use the system electron would be a step in the right direction.

The Archlinux official code package already does that, with this PKGBUILD you can reference. The things to change includes:

• handling version for the system's electron
• building native modules for the system's electron before building vscodium
• replace some strings so that the system's electron is called upon starting vscodium

An alternative AUR package vscodium-electron is designed so, but its maintainer is not responding anyone and the package is seriously out-of-date.

Thank your for creating and maintaining this package. Please update vscodium-uri-handler.desktop:

$ sudo sed -i "s\/opt/\/usr/share/\\g" /usr/share/applications/vscodium-uri-handler.desktop

When compiling with makepkg parameters: --cleanbuild --syncdeps --noconfirm --clean and with aurutils I get the following error:

Downloading ripgrep failed: TypeError [ERR_INVALID_PROTOCOL]: Protocol "https:" not supported. Expected "http:"
    at new NodeError (node:internal/errors:399:5)
    at new ClientRequest (node:_http_client:189:11)
    at request (node:https:360:10)
    at Object.get (node:https:394:15)
    at /home/user/.cache/aurutils/sync/vscodium/src/vscode/node_modules/@vscode/ripgrep/lib/download.js:141:15
    at new Promise (<anonymous>)
    at get (/home/user/.cache/aurutils/sync/vscodium/src/vscode/node_modules/@vscode/ripgrep/lib/download.js:135:12)
    at getAssetFromGithubApi (/home/user/.cache/aurutils/sync/vscodium/src/vscode/node_modules/@vscode/ripgrep/lib/download.js:190:27)
    at async module.exports (/home/user/.cache/aurutils/sync/vscodium/src/vscode/node_modules/@vscode/ripgrep/lib/download.js:298:9)
    at async main (/home/user/.cache/aurutils/sync/vscodium/src/vscode/node_modules/@vscode/ripgrep/lib/postinstall.js:72:9)

Am I doing something wrong or is there something faulty during the build-process?