Feature/improvement: Go to actual definition for local fs dependencies

[artem-nefedov]

Currently, when using "goto definition" with dependent charts, it always jumps into .helm_ls_cache/ directory, which makes this feature useless if you want to make any edits. If dependency config in Chart.yaml is pointing to the local filesystem (repository: file://../foo/bar), it should be possible to jump to actual definition in the source file, greatly improving the usability. Also this could be reused in the future for "rename" functionality (if ever implemented).

Caveat: If source dependency is changed, consumer chart needs to have dependencies rebuilt. It may be out of scope for LS to care about this, or there could be some logic to handle this automatically - whatever makes more sense.

[qvalentin]

I have a fix for the specific "goto definition" problem you mentioned here: #162.
But I'm not to sure about it, since it could provide wrong information if the local chart was updated but the current chart has an old version in the Chart.lock.

If you compare it to how for e.g. an lsp for python works:
With "goto definition" you go to the source file in your .venv/... but no to the location where the library is defined.

So its kind of the question what the source of truth is:

• The tar.gz/Chart.lock
• The local directory of the dependency

Pointing to the the local directory of the dependency definitely breaks once you make changes to that directory since the actual values/templates are loaded from the tar.gz.

[artem-nefedov]

@qvalentin I understand your point, but I do think it still would be an improvement over what we have now if we think about it like this:

1. If you want to go to definition only for checking it and not editing, it works equally well in both cases (disregarding edge case when file:// points to non-existent directory, don't think it's important).
2. If you want to do edits going to definition, the proposed change will make it easier, even if it doesn't solve the whole "dependency rebuild", which is expected to be done separately. Meanwhile, current implementation isn't helping at all in this case.

Also, I think python case is different, because there you almost always have a library downloaded from remote registry (you would only temporarily override it to local fs sometimes), while with helm charts it's normal to dependencies that are always pointing to local fs.