-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for includes #59
Comments
Actually, should Helm-ls even support sources other than the current chart and dependencies collected in the Most other language servers just make use of the locally collected dependencies. For example: |
@AndersBennedsgaard I think you're correct, this should only read dependencies that are built and stored within the For example, the user will need to make sure they execute:
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 |
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 #80 |
Opening this issue to track your feature request @Mo0rBy.
To support this I would suggest to approach it using the following steps:
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).
Support local includes from dependency charts
On startup you could read in all dependency charts that are defined like
repository: file:https://../mylibchart
and add their templates to the templates that are queried for go-to-definition or hover of includesSupport remote includes from dependency charts
Would be the same as 2. but you would need to fetch the dependencies over the network.
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)
The text was updated successfully, but these errors were encountered: