It would be nice if this package would replace vscode package and vscode package to be renamed to vscode-bin.

Would be vscode-src different from a vscodium built from source?

Is this build compatible with Microsofts propritary addons?

I have no reason to believe it behaves any differently regarding proprietary plugins, but you have to install them yourself. I will check tomorrow.

vscodium is same thing with different logo and modified product.json (https://github.com/VSCodium/vscodium/blob/cb04b93044fb74f4e0f74ac0951d34f4de1f2e5d/prepare_vscode.sh#L19) and separate builds. For what I am aware since code in official repo is opensource, we can put any product.json and I do not see any reason to modify it by default.

I do not want to call it vscodium, as that's the name of their "open source" binaries, but for me these are as closed source as vscode binaries minus property plugins. Why not leave it as vscode-oss?

Vscode-oss name comes from here: https://github.com/microsoft/vscode/blob/master/product.json#L4 So they already have naming convention that suggest vscodium is not same thing. But at the end of the day however we call it I don't care too much.

I'll check why hashes fail, I think I changed something and did not recheck hashes.

Ok download hashes do not match only for aarch64, looks like downloaded dependencies are different there.

Ok. We just need to make sure, they don't hold any trademark right on the name.

vscodium is same thing with different logo and modified product.json (VSCodium/vscodium:prepare_vscode.sh@cb04b93#L19) and separate builds. For what I am aware since code in official repo is opensource, we can put any product.json and I do not see any reason to modify it by default.

I do not want to call it vscodium, as that's the name of their "open source" binaries, but for me these are as closed source as vscode binaries minus property plugins. Why not leave it as vscode-oss?

I think they disabled telemetry. Not sure if your build does the same.

I have no reason to believe it behaves any differently regarding proprietary plugins, but you have to install them yourself. I will check tomorrow.

They did not work with vscodium, hence the question. If they don't work we might need to keep the binary vscode.

I have to check regarding telemetry and disable if not disabled, thanks!

Will also do a bit of cleanup, on comments and I see I need to remove downloadPage from meta and other minor things.

I feel there is still a need for a proper explanation of why anyone would use this instead of vscodium or vscode(-bin)? Who's the target audience?

I can see an added value for aarch64 where there are no official binary builds from MS (yet). Is that it?

I see some advantages of building vscode from source:

• the ability to apply NixOS-specific patches
• shared electron binaries between this and other packages
• One vendor less to trust
• Better portability

I want to test vscode with Wayland support and for that I need to build electron from source and vscode from source. That's why I decided to make a package to make process reproducible.

At the same time I feel much better if distro provides package, instead of third party vendor (even if that vendor is Microsoft). I feel like too many projects these days only provide binary releases and only support some mainstream distros. And then they call these binary releases open source, where you have source, but it's really hard to build actual source, as they do not provide clear instructions how to do the build.

@prusnak thanks for review

Oh yeah one more thing, aarch64 builds should work now.

I have generalized this a bit and made vscode-oss part of vscode folder as we have for vscodium. I have also generalized vscode-with-extensions so you can now call vscode.withExtensions or vscode-oss.withExtensions you get the idea.

@Mic92 Good news is also vscode-remote now works as soon as i set extensionAllowedProposedApi option in product.json. I do not see that being a problem, since it only whitelists which additional api-s are allowed (you can still not use them) and extensions are not installed by default anyway.

Telemetry is also disabled by default now.

Ok. Than we could actually drop the proprietary build. What do you think?

Well yes, or can rename to vscode-bin, but i would like to do in another pull request, since i would like for more people test this build.

The issue now is it also uses different configuration folder in home, so that means users need to copy their configs under code-oss folder, i don't want to replace something and break user configurations. I can make vscode compatible product.json configuration and build, but i maybe would like to leave this (original one) as is.

I am still unsure why aarch64 yarn cache sha256 is different on @GrahamcOfBorg, since i run many times on packet host aarch64 instance and got same hash. yarn install is non deterministic between different platforms, and i don't know how to force it to be more deterministic, or just to force it to download everything.

I am still unsure why aarch64 yarn cache sha256 is different on @GrahamcOfBorg, since i run many times on packet host aarch64 instance and got same hash. yarn install is non deterministic between different platforms, and i don't know how to force it to be more deterministic, or just to force it to download everything.

You can check with diffoscope between archives from different architectures.

How is the progress on this?

@turion maybe just open a different pr with x86 only for now.

@offlinehacker I cherry picked your changes to the Electron package in #105241 - so the headers are now included. Thanks! You might want to rebase this branch on top of the current master. (There were other conflicts as well).

I marked this as stale due to inactivity. → More info

Is this PR still active?

I marked this as stale due to inactivity. → More info

@offlinehacker @Mic92 Maybe we should just merge this with just x86 support, then a new PR for other architectures. This would be nice to have.

Yes, I would merge such a PR.

Is there anything else that needs to be done other than rebasing with master then, for the x86 support to be merged in @offlinehacker? if not, it might be good to unset this as a draft and request review.