Change:
<ins> --- ./build/gulpfile.reh.js +++ ./build/gulpfile.reh.js @@ -277,8 +277,6 @@ .pipe(util.stripSourceMappingURL()) .pipe(jsFilter.restore); -		const nodePath = `.build/node/v${nodeVersion}/${platform}-${platform === 'darwin' ? 'x64' : arch}`; -		const node = gulp.src(`${nodePath}/**`, { base: nodePath, dot: true }); let web = []; if (type === 'reh-web') { @@ -296,7 +294,6 @@ license, sources, deps, -			node, ...web ); @@ -376,7 +373,6 @@ const destinationFolderName = `vscode-${type}${dashed(platform)}${dashed(arch)}`; const serverTaskCI = task.define(`vscode-${type}${dashed(platform)}${dashed(arch)}${dashed(minified)}-ci`, task.series( -				gulp.task(`node-${platform}-${platform === 'darwin' ? 'x64' : arch}`), util.rimraf(path.join(BUILD_ROOT, destinationFolderName)), packageTask(type, platform, arch, sourceFolderName, destinationFolderName) )); </ins>

Discussion:
Project description It's like but closer to upstream, as I understand it. Maybe this can be packaged similarly to how is packaged? shamelessly ccing past code-server contributors: (hi!) and maybe would be interested, or maybe has a nix derivation already? Metadata homepage URL: source URL: license: mit platforms: linux
from Gitpod. I am pretty close to finishing packaging this. Happy to open a WIP and get the help of others to finish up. was causing me grief but is now fixed.
Oh cool, this would be great to have packaged! Feel free to cc me if you run into any sticking points, I'd be glad to take a look.
Hey folks ( ) can I get your help with getting this over the line? Problems experienced: esbuild continues to attempt downloading linux binaries during the compilation phase in a pure environment
Sure, let me try to find some time to poke around at it this week. My guess is that inserting the binary using will be the way to go, and it might be easier/more reliable to compile esbuild in the derivation rather than trying to install a prebuild in one of the earlier phases and copy it through.
I hope so; what I experienced was esbuild attempting to pull binaries from the internet during the build phase. Wasn’t aware of ESBUILDBINARYPARTH. I tried to mitigate via bumping esbuild version (thus explaining why using my fork)
Made some progress -- There are two separate versions of esbuild in the project, one in the root and one in extensions. runs a script that executes in a few other directories, which then triggers another that attempts to download esbuild. I think you were on the right track with adding to that postinstall script, but it seemed a bit tricky to replace via substitution. We could probably patch it instead, but I ended up just reimplementing the postinstall script with and building the necessary esbuild versions within the derivation. It got further along in the build, but I think it's looking for the node sources now: I'll have some more time this weekend to make progress on it, but here's my WIP branch:
I have a working version pushed up on the branch I linked in my previous comment.

I tested it runs on both Darwin and Linux x64, but I haven't extensively QAed it to make sure everything works as expected. Would you like to take over submitting a PR for it? I can do it if you prefer, but since you got the ball rolling, I wanted to give you the opportunity if you're interested
I'm back to being curious about this. GitPod is just very precise about mostly having achieved their goal and about trying to be as minimal as possible to enable the in browser experience properly. They have a new blog post:
Sounds good, I'll clean up my branch based on code review I received in and put up a PR for it tonight. I haven't done much research into it, but I'm interested to see if MS will publish any of the work they've made in this direction, either on or GitHub CodeSpaces. Neither of them are exactly comparable to code-server/openvscode-server, but it's nice to see a variety of projects making progress in that direction.
Some updates on OpenVSCode server!
Oh, I read the above blog post and it looks like they did, that's great! PR for this issue is open ^
Thanks a bunch this is really cool and powerful to have available via Nix! I'm very curious to see where upstream/openvscode/code-server go, especially in terms of things like Auth. It'd be neat to be able to tell VSCode to take accept auth information passed via headers, or pass it JWS info to validate a JWT header or something. Although if it's remaining single-user, just disabling auth and letting the reverse proxy handle it seems as elegant as anything. Anyway, thanks again!
Also, I just did notice a difference. OpenVSCode server blocked me from installing extensions that Code-Server allowed (or maybe isn't new enough to try and block?). And I don't have an override but there might exist a way? Are you on the OpenVSCodeServer Discord , or are you both maybe on Matrix? We could spin up a room to share notes?

(EDIT: turns out the one extension it did block was the bracket colorizer, but 1) it wasn't working in code-server anyway, and 2) I think there was a blog post and it's going to become built-in)
I'm not in either yet, but I'll hop in the OpenVSCodeServer/Gitpod Discord at least! I know at least one improvement that would be nice to make would be adding back the built-in extensions -- I saw there's a directory in nixpkgs that might work for building the extensions.