Add support for relative release path overrides

[kristoff3r]

I wanted to try using this extension with the new expert lsp in my project, but I couldn't find a way to keep it self-contained without hardcoding an absolute path. VSCode doesn't support variables in settings, and this extension checks that the file exists at the path given, meaning I can't just have it in PATH. This PR solves it by interpreting relative paths as being relative to the workspace directory.

I also improved the logging, as most cases where the file didn't exist wouldn't print anything.

[Blond11516]

Hi @kristoff3r !

The change looks good but I'm not entirely sure I understand the problem, and therefore that this is the right solution. Could you give a specific example of how you're using this to do something you couldn't before?

[kristoff3r]

Hi @kristoff3r !

The change looks good but I'm not entirely sure I understand the problem, and therefore that this is the right solution. Could you give a specific example of how you're using this to do something you couldn't before?

Sure, I'll try to list the steps I tried before I ended up making this PR.

• I wanted to try expert, so I can't use the auto install and disable it.
• I tried to use the expert binary from PATH, but Lexical interprets the override as an absolute path so that didn't work.
• Since I installed expert via their Nix flake, I tried hardcoding the Nix store path, but that's both brittle and also it didn't work, because since recently expert needs to be started with expert --stdio to work, and there's no way to pass command line arguments via releasePathOverride.
• Then I made a tiny wrapper script called start_expert.sh, and set releasePathOverride: "absolute/path/to/start_expert.sh":

#!/bin/sh

expert --stdio

• That works as long as expert is in PATH. But now I wanted to share my setup with my team to test, and if I just add this file to our repository I cannot assume the absolute path to it on their systems.
• I spent quite a while thinking "surely VSCode must have a way to refer to the workspace directory in settings.json", but then I stumbled upon Support variables when resolving values in settings microsoft/vscode#2809 and realized that every plugin must implement this manually.
• Then I made this change, and tested it by setting "lexical.server.releasePathOverride": "scripts/start_expert.sh" in .vscode/settings.json in our repository, which worked.

There are probably a bunch of other solutions that could make experimenting with expert easier, but this was the simplest change that solves my problem. The logging changes might also save someone else some time in the future, as it's pretty confusing to see "Starting lexical release in ${some_path}" and no errors when in reality it's trying to run ${some_path}/start_lexical.sh which doesn't exist.

[Blond11516]

Thanks for the detailed explanation, the situation is much clearer to me now!

If vscode-lexical gave you the option to launch expert directly from PATH and pass in arguments (--stdio) would you prefer that instead?

I think it's worth merging relative paths either way, just wondering if that could be worthwhile in the future.

[kristoff3r]

Thanks for the detailed explanation, the situation is much clearer to me now!

If vscode-lexical gave you the option to launch expert directly from PATH and pass in arguments (--stdio) would you prefer that instead?

I think it's worth merging relative paths either way, just wondering if that could be worthwhile in the future.

That would save the indirection to the script, so that would be even better. As long as it allows me to provide the binary on PATH myself and doesn't require auto install, as that works poorly on NixOS.

[Blond11516]

Thanks for the detailed explanation, the situation is much clearer to me now!
If vscode-lexical gave you the option to launch expert directly from PATH and pass in arguments (--stdio) would you prefer that instead?
I think it's worth merging relative paths either way, just wondering if that could be worthwhile in the future.

That would save the indirection to the script, so that would be even better. As long as it allows me to provide the binary on PATH myself and doesn't require auto install, as that works poorly on NixOS.

I'll try to see if I can get that done then. In the meantime I've updated the logging a bit and added tests to this current branch and will merge it. Expect a release later today!

Thanks for the contribution @kristoff3r!