Asher
Decided to move this back to a draft. I am going to look into making their script work because that would be the more maintainable solution.
> Doesn't this simply add the same path twice? Yup, for anyone that has already added it to the path it will appear twice. We could add a check to...
@jsjoeio that is awesome, I actually intended on adding a test for this so that code will be very helpful!
I think the ideal solution is going to be to fix upstream's `code-server` script so that it can find Node. This means invocations on the integrated terminal will use their...
Yeah renaming the upstream script would cause `code-server` invocations to use our script instead (for users that have it on their path) but since upstream's script does everything ours does...
> `/opt/code-server/bin/code-server` is the equivalent to `/opt/code-server/lib/vscode/bin/code-server-oss` and not `/opt/code-server/lib/vscode/bin/remote-cli/code-oss`. `./bin/code-server` is like `./lib/vscode/bin/code-server-oss` when ran from an external terminal (spawns a server) but it is like `./lib/vscode/bin/remote-cli/code-oss` when ran...
Sorry for being dense; how does this change anything with https://github.com/coder/code-server/issues/1315? Our script and upstream's are more or less doing the same thing (run Node and interact with code-server via...
The VS Code remote extensions. Remote - SSH, remote - containers, and remote WSL I think. Although that issue (#1315) is only about implementing open-source versions of the first two...
Ahh right I see what you mean! Yeah the settings situation has been confusing. Upstream `User` settings were changed to be stored in the browser so now they are local...
We might also want a way to override this for cases like Coder where we already provide a subdomain proxy outside of code-server. For this we can probably just check...