Can't you use yaml-language-server from the YAML vscode extension?

[felipecrs]

I was wondering if instead of asking users to install yaml-language-server if you couldn't just reuse the one from the YAML vscode extension.

Since this extension already depends on Kubernetes extension (which depends on YAML extension), I think that would be nice and would simplify things a lot.

It exposes language server as an entrypoint: https://github.com/redhat-developer/vscode-yaml/blob/db9fc028fea610c2247c0d528fded24bfa9e839b/webpack.config.js#L22

[felipecrs]

Or better yet, why not just add yaml-language-server as npm dependency of this project and configure helm-ls to point to its executable in node_modules?

[qvalentin]

Good point, I also thought about this but did not yet look deeper into it.

Regarding the two options:

1. Adding yaml-language-server as a npm dependency: This could actually be quite easy.
2. Using yaml-language-server from the yaml extension: This would have the advantage that only one instance of yaml-language-server is downloaded. The helm-ls extension depends on the k8s extension, which depends on the yaml extension. So the yaml extension should always be installed.

I would suggest trying 1. and then looking at how 2. could be achieved.
Feel free to test it out and provide a PR.

[qvalentin]

Ok, so i have a working version in #20.
Problem is that it still requires the user to have node installed an on PATH.

Do you think this would be fine?

[felipecrs]

I'm just wondering: if the YAML extension has the language server running, isn't there a way to interact with it instead of having to spin up a new one?

---

Also, I wonder if you cannot start the YAML language server like any other language server should be started in VS Code, using LanguageClient ServerOptions poiting module to the language server file so that VS Code itself will manage its execution.

https://github.com/redhat-developer/vscode-yaml/blob/4b1730412b5a6bf82f0bc23f6665db8904bf4c21/src/node/yamlClientMain.ts#L39

https://code.visualstudio.com/api/language-extensions/language-server-extension-guide#explaining-the-language-client

[felipecrs]

But adding the YAML language server as a npm dependency and then removing all options related to customizing its path is also a good option.

This way you have full control over the YAML language server being used by your users, reducing the risk of any kind of incompatibilities.

You can also get rid of the code that handles whether the YAML language server is available or not, since it will always be.

[qvalentin]

Starting the lsp using LanguageClient is not possible because of how helm-ls works: helm-ls is basically a proxy between the editor and yamlls that converts gotemplate to yaml. And it runs outside of vscode.

But I just remembered that yamlls does not only support stdio so maybe we could start yamlls in vscode and pass the socket (or similar) to helm-ls and connect to that.

Good link btw, looks like vscode-yaml is also using ipc.

[felipecrs]

But I just remembered that yamlls does not only support stdio so maybe we could start yamlls in vscode and pass the socket (or similar) to helm-ls and connect to that.

Interesting.

I also wonder if you cannot start the yaml-language-server using some import or require gimmick.

[felipecrs]

I also wonder if you cannot start the yaml-language-server using some import or require gimmick.

I think that would be the best, @qvalentin, so that you can manage the lifecycle of yamlls directly within helm-ls without requiring to spawn a separate process.

[felipecrs]

Also, execa supports executing with the process' own node binary.

https://github.com/sindresorhus/execa/blob/main/docs/node.md

I wonder if it does any magic to locate the binary within VS Code context.

[felipecrs]

Execa's solution is based on process.execPath + process.execArgv, and it can be replicated.

It works even in scenarios where Node.js is not available. In my Windows, it yields to the Code.exe which seems to be a Node.js wrapper as well (accepts its options and runs JavaScript files).

@qvalentin the only thing I don't like about #20 is that it will update my VS Code settings. I hate when that happens...

Perhaps if you accept the yaml-language-server path as an environment variable, then the extension could easily inject it without updating the settings.

When the variable is set, ignore the config and use it.

Then, in the extension you can decide when to set it.

[qvalentin]

Good points.

Using process.execPath + process.execArgv seems like a good fallback if node is not found on PATH.

Regarding updating the settings: Using a env variable sounds good. I can add this to helm-ls and then use it in the extension.
This also would be more backwards compatible then mrjosh/helm-ls#165.