Just a note the most recent version of vscode (1.40) has updated to node 12.x so if you’re replacing the node binary be sure to update it.
I tried the link
to your fp course and it failed. tried to copy errors from gitpod but no copy and paste available.
Is there another working link I could try?
I made Nix derivation for this tedious work… gist link
If one needs quick solution, just nix-shell fix-vscode-remote.nix and run fix-vscode-remote %USERNAME%.
If one needs permanent solution, make this cronjob or systemd.service and run daily.
Yet you must manually sync node version when vscode changes it.
2 Likes
Did you try / have an issue with https://github.com/NixOS/nixpkgs/blob/38c3a43c0c403c00925212c8a956e0ea3c16b089/pkgs/misc/vscode-extensions/remote-ssh/default.nix ?
1 Like
Hey everyone. Here is a docker-based solution for devcontainers that I built:
Please give it a try and let me know how it goes.
Known issues:
- vscode overrides the entrypoint. I really wanted to be able to start the nix-daemon in there.
- vscode looks for binaries on the container PATH. This is a bit problematic when for example enabling the go or nodejs plugins. The container has a full nix store with mutable profile so you can install those like that.
If I recall correctly, this code only gets executed on linux systems, and no fix is needed for windows so in theory it should work, but let me know if not and can take a look
I first tried something like the solution of @tbenst, which works great for Nix using clients, since it changes the client extension to fix the script run on the server to make sure the node symlink will be used, but this indeed won’t work when e.g. using a Windows client. That is why I made the following solution that runs on the NixOS server instead, making it agnostic about any client, so it works fine for Windows clients too: https://gist.github.com/msteen/95c16659969f30b4682446e37325d737
1 Like
@msteen Looking through your script quickly I’m wondering if this can be a systemd user service? That might simplify it a bit and you might be able to get away with not specifying which users it runs for?
Thanks for the suggestion, since AFAIK you cannot select any other folder than ~/.vscode-server, your suggestion would indeed be better. I updated the gist, however I cannot seem to get it working as an user service. I tried running the script in bash myself and the testing succeeds, but if I run the exact same code (minus the hard coded node path versus $(which node)), the script fails to do what I expect it to do. I have little to no experience with user services, any idea what I might be doing wrong?
It was working fine, I just had to manually disable/enable the user service again after rebuilding my system. I forgot to mention that I also updated it to also handle “Uninstall VS Code Server from Host”, such that running that won’t break the monitor.
I don’t use Windows so haven’t tested. I do think that patching the JS source code so that it triggers only on installation is the better approach than running SystemD constantly. Should be relatively straightforward to modify my patch (in nixpkgs) to detect windows and either not run or use a Junction instead of symlink.
@tbenst the wonderful service by @msteen 
is using inotifytools so it should be very efficient.
I’m still not entirely clear on how your solution works for developers on windows. I’ve never really used vscode (above and beyond some testing to get things working for my developers) so pardon my ignorance… but extensions are distributed to windows developers via the vscode IDE itself. How do I inject your code into my developers IDE, and what happens when they upgrade their plugin?
Didn’t mean to criticize! My understanding is MS distributes the exact same JavaScript extension across platforms, so applying the patch should work the same (but need to use Windows machinery to do automatically) but sounds like you have a different context than I have—I have many servers I use but only one developer (me) connecting from a couple clients, and all are on Linux, whereas sounds like you have many clients connecting to same machines, and some windows clients. In my case, better to patch small number of clients’ infection scripts, whereas in your case maybe it’s easier to patch a small number of hosts, especially if difficult to patch on windows.
@tbenst ahh yeah that makes sense now. We have very different scenarios. For your situation the fix you proposed makes way more sense, yes!
Thanks for clarifying.
I have just packaged code-server if anyone is interested, it’s built from source: code-server: init at 3.4.1 by offlinehacker · Pull Request #87258 · NixOS/nixpkgs · GitHub
I will also implement module for home-manager, which will provide easy way to start code-server in user.
6 Likes
I’m embarrassed to say even though I use vscode daily, including remote SSH, I don’t know what this is… is this what remote-ssh installs if not present already?
@tbenst No, this exposes a web facing instance of vscode similar to the online IDE feature via microsoft
1 Like
With the fix from @tbenst (Thank you!) I think on our NixOS boxes the vscode remote-ssh works out of box.
Not sure whether this post is the best place to ask but I would give it a try. After connecting to the remote server, many extensions need to be “install in SSH” before they can be used. I am not sure how this works (not a vscode user) but my guess is that the extensions will have to be installed to the $HOME/.vscode-server/ folder on the remote machine. The issue here is that if I try to install, I got “permission denited” error. Is this actually what I am supposed to do to use extension while doing remote development, or there exists a more declarative way to do so?
Thanks in advance!
1 Like