Support for includes

[qvalentin]

Opening this issue to track your feature request @Mo0rBy.

1 question I have to see if this would even be possible. So with Helm Library charts, they can be stored and referenced within the local machines filesystem and I imagine that with this method, it would be possible to get the LSP to find definitions for Helm templates, however, would this be possible for library charts hosted in online repositories? For example, Bitnami have a common library which contains a bunch of useful utility templates that are heavily used in their own Helm charts and can easily be used in your own custom Helm charts. Furthermore, would it be possible to setup the LSP to get template definitions from private repositories? (my initial guess would be no without setting up some authentication stuff which I think would be kind of advanced for any LSP to do).

To support this I would suggest to approach it using the following steps:

1. Support local includes in same chart For this you would need to read in all templates files in the current chart and parse them with tree-sitter. On go-to-definition or hover you would query the parsed templates for the corresponding definition. For this you would also need to update the parsed templates when they change (this should already be implemented).

2. Support local includes from dependency charts On startup you could read in all dependency charts that are defined like repository: file://../mylibchart and add their templates to the templates that are queried for go-to-definition or hover of includes

3. Support remote includes from dependency charts Would be the same as 2. but you would need to fetch the dependencies over the network.

   4. Support remote includes from dependency charts with authentication Would be the same as 3. but using user defined credentials (e.g. via configuration options or environment variables)

[AndersBennedsgaard]

Actually, should Helm-ls even support sources other than the current chart and dependencies collected in the charts/ folder collected with helm dependency build or similar? Supporting remote library charts with advanced networking, authentication, caching, and all the other issues that come with this, seems out of scope for an LS.

Most other language servers just make use of the locally collected dependencies. For example: gopls only support dependencies already collected with go get or similar. The YAML language server is special in this regard, since it enabled remote lookup of schemas, but in my mind, this is not necessary here

[Mo0rBy]

@AndersBennedsgaard I think you're correct, this should only read dependencies that are built and stored within the charts/ directory. Then all the authentication and stuff is up to the user to sort.

For example, the user will need to make sure they execute:

aws ecr get-login-password | helm registry login --username AWS --password-stdin <my-aws-account-url> && \
helm dependency build

Makes it a whole lot simpler as well as we don't have to worry about different source types etc, it just reads everything it needs from the charts/ directory.

[qvalentin]

You are right, reimplementing the dependency fetch makes no sense. We could either use helm as a library (https://github.com/mrjosh/helm-ls/pull/77) or maybe call helm env to get the HELM_REPOSITORY_CACHE directory and read the charts from there. Either way, step 1 from the first post in this issue is about 50% done in https://github.com/mrjosh/helm-ls/pull/72.

[qvalentin]

Support local includes in same chart is implemented in https://github.com/mrjosh/helm-ls/releases/tag/v0.0.16.

The rest might follow with https://github.com/mrjosh/helm-ls/pull/80 (Preview below)

[qvalentin]

Feel free to test https://github.com/mrjosh/helm-ls/pull/80, which adds support for includes from dependency charts.

[qvalentin]

Added in v0.1.0