Add Helm extension

[cabrinha]

I've got this extension to a point now where all highlights seem to be working properly, but there are still a couple issues I need some help with:

• Files aren't automatically detected as "Helm", but instead as "YAML", need to find a way to detect helm if the *.yaml file is located in a directory named templates: templates/*.yaml, is this possible?
• Some errors are being displayed as YAML errors, but really its valid Helm syntax

[aohoyd]

Files aren't automatically detected as "Helm", but instead as "YAML", need to find a way to detect helm if the .yaml file is located in a directory named templates: templates/.yaml, is this possible?

I don't think templates/*.yaml is enough. Personally I use templates directory for my projects as a base directory for templates not related to helm. Imo it should check for a file Chart.yaml in the parent directory of templates/ and only then recognise templates/**/*.(yaml|yml|tpl) files as go templates. I'm not sure how to do it in Zed, trying to figure out

Some errors are being displayed as YAML errors, but really its valid Helm syntax

These errors come from original YAML language server. You can disable it and errors will be gone.

[yodatak]

Any news on this would love to use it ^^ for more kubernetes with rust

[cabrinha]

Any news on this would love to use it ^^ for more kubernetes with rust

Need some help on getting this to "work". First up, the CI tests are failing, but this extension mostly works. Second...

@yodatak do you know how to get .yaml files recognized as Helm? Either the existence of a Chart.yaml file or the files exist inside of a templates directory? Maybe the existence of {{ }} in a .yaml is enough to switch the syntax from YAML to Helm?

[selfisch]

Any news on this would love to use it ^^ for more kubernetes with rust

Need some help on getting this to "work". First up, the CI tests are failing, but this extension mostly works. Second...

@yodatak do you know how to get .yaml files recognized as Helm? Either the existence of a Chart.yaml file or the files exist inside of a templates directory? Maybe the existence of {{ }} in a .yaml is enough to switch the syntax from YAML to Helm?

Hey there, thanks for working on this, great work so far. Unfortunately I cannot support you.

But just said, {{ }} is not automatically Helm. I am using a tool which has Jinja2 templating, so I can template my kubernetes manifests with it. I have also this issue of bracket space with Zed not only, but also for Helm.

[runitmisra]

@cabrinha What I have generally seen from neovim autocmds to load helm-ls as language server automatically, is that it looks for the following:

• The yaml or tpl file should be in a templates folder
• There should be a Chart.yaml in the project root directory (same level as templates folder)

If both are true, it is pretty safe to assume user is working with Helm. Hope this helps.

[cabrinha]

@cabrinha What I have generally seen from neovim autocmds to load helm-ls as language server automatically, is that it looks for the following:

• The yaml or tpl file should be in a templates folder
• There should be a Chart.yaml in the project root directory (same level as templates folder)

If both are true, it is pretty safe to assume user is working with Helm. Hope this helps.

Thanks for those ideas, but how does that implementation look in Zed?

[gnikishin]

a bit of nuance, sometimes Chart.yaml isn't located in project root. e.g /project_root/dir/.helm/Chart.yaml and /project_root/dir/.helm/templates/

UPD. also there is related issue, which will make working with helm kinda painful #12122

[yodatak]

I know in vscode it use the json shema for help https://json.schemastore.org/kustomization.json https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml

Via the yaml language server

https://github.com/redhat-developer/vscode-yaml

and helm chart is supported by https://github.com/vscode-kubernetes-tools/vscode-kubernetes-tools

like https://github.com/redhat-developer/vscode-yaml/issues/464

the textmate language of vscode https://github.com/vscode-kubernetes-tools/vscode-kubernetes-tools/blob/master/syntaxes/helm.tmLanguage.json

and some https://github.com/vscode-kubernetes-tools/vscode-kubernetes-tools/blob/master/docs/extending/README.md

[mikeymop]

@yodatak Have you gotten that to work? I actually asked for help about that in 14528

I believe this is correct according to both documentations

{
  "lsp": {
    "yaml-language-server": {
      "initialization_options": {
        "yaml.schemas": {
          "http://json.schemastore.org/chart.json": "templates/*.yaml"
        }
      }
    }
  }
}

{
  "lsp": {
    "yaml-language-server": {
      "initialization_options": {
        "yaml": {
          "schemas": {
            "http://json.schemastore.org/chart.json": "templates/*.yaml"
          }
        }
      }
    }
  }
}

However I could only apply a schema with inline comments

# yaml-language-server: $schema=https://json.schemastore.org/chart.json

[yodatak]

I think we need to fix https://github.com/zed-industries/zed/issues/7636 before merging ? i would love to have more kubernetes autocompletion with flux2 and so one but

[yodatak]

@yodatak Have you gotten that to work? I actually asked for help about that in 14528

I believe this is correct according to both documentations

{
  "lsp": {
    "yaml-language-server": {
      "initialization_options": {
        "yaml.schemas": {
          "http://json.schemastore.org/chart.json": "templates/*.yaml"
        }
      }
    }
  }
}

{
  "lsp": {
    "yaml-language-server": {
      "initialization_options": {
        "yaml": {
          "schemas": {
            "http://json.schemastore.org/chart.json": "templates/*.yaml"
          }
        }
      }
    }
  }
}

However I could only apply a schema with inline comments

# yaml-language-server: $schema=https://json.schemastore.org/chart.json

I don't find any way seem to be a bug from yaml lsp i think

for me for flux2 i need to do

# yaml-language-server: $schema=https://raw.githubusercontent.com/fluxcd-community/flux2-schemas/main/helmrelease-helm-v2.json
---
apiVersion: helm.toolkit.fluxcd.io/v2

or for kustomisation

# yaml-language-server: $schema=https://json.schemastore.org/kustomization.json
apiVersion: kustomize.config.k8s.io/v1beta1

or for namespace

# yaml-language-server: $schema=https://kubernetesjsonschema.dev/v1.14.0/Namespace-v1.json
---
apiVersion: v1
kind: Namespace

[aohoyd]

I think that LanguageMatcher should be extended with something like path_globs to match not only file suffixes but also subpaths

[notpeter]

I think that LanguageMatcher should be extended with something like path_globs to match not only file suffixes but also subpaths

I think you should be able to use ** which will match 0 or more segments across directories. So maybe something like: templates/**/*.yaml?

[cabrinha]

I think that LanguageMatcher should be extended with something like path_globs to match not only file suffixes but also subpaths

I think you should be able to use ** which will match 0 or more segments across directories. So maybe something like: templates/**/*.yaml?

Tried to do this here: https://github.com/cabrinha/helm.zed/commit/6f2ac4636cdc39d92a917a2535f957c0fd0d8544 ... Still not working.

[nabiltntn]

Files aren't automatically detected as "Helm", but instead as "YAML", need to find a way to detect helm if the .yaml file is located in a directory named templates: templates/.yaml, is this possible?

I don't think templates/*.yaml is enough. Personally I use templates directory for my projects as a base directory for templates not related to helm. Imo it should check for a file Chart.yaml in the parent directory of templates/ and only then recognise templates/**/*.(yaml|yml|tpl) files as go templates. I'm not sure how to do it in Zed, trying to figure out

Some errors are being displayed as YAML errors, but really its valid Helm syntax

These errors come from original YAML language server. You can disable it and errors will be gone.

I think also that some charts also create sub-charts under the charts folder, so I think this should also be include in the pattern

[cabrinha]

I think also that some charts also create sub-charts under the charts folder, so I think this should also be include in the pattern

Those charts are tar'd up, so they don't really need to be opened and rendered.

[selfisch]

Hey, discussing what files need to be edited and which not is not purposeful in this case.

Like mentioned many posts above, this is no explicit helm issue, but more like a templating include issue in the yaml lsp. I am using jinja2 templating in yaml files and have almost the same issue, no matter which ide using. There needs to be a way to include templating definitions like go/sprig for helm, but also jinja2 for example, into the yaml lsp definition. And that makes the whole topic more komplicated in general :-/

[gnikishin]

Those charts are tar'd up, so they don't really need to be opened and rendered.

not always, it can be custom sub chart which written in plain yaml files.

This directory "multipurpose", subcharts can be in form of tar.gz, and in form of directory

[cabrinha]

Those charts are tar'd up, so they don't really need to be opened and rendered.

not always, it can be custom sub chart which written in plain yaml files.

This directory "multipurpose", subcharts can be in form of tar.gz, and in form of directory

This is all valid, but how do we get closer to getting Zed to support helm syntax?

[mikeymop]

Those charts are tar'd up, so they don't really need to be opened and rendered.

not always, it can be custom sub chart which written in plain yaml files.

This directory "multipurpose", subcharts can be in form of tar.gz, and in form of directory

This is all valid, but how do we get closer to getting Zed to support helm syntax?

I would argue that properly supporting jsonschema overrides in yaml-language-server is the best place to divert focus towards.

It is working with an inline comment today, if it can be made to work in settings.json, and with glob patterns, it would be comparable what VsCode offers.

[cabrinha]

Those charts are tar'd up, so they don't really need to be opened and rendered.

not always, it can be custom sub chart which written in plain yaml files. This directory "multipurpose", subcharts can be in form of tar.gz, and in form of directory

This is all valid, but how do we get closer to getting Zed to support helm syntax?

I would argue that properly supporting jsonschema overrides in yaml-language-server is the best place to divert focus towards.

It is working with an inline comment today, if it can be made to work in settings.json, and with glob patterns, it would be comparable what VsCode offers.

Not sure I have much to offer there... Should we close this PR?

[aohoyd]

It is working with an inline comment today, if it can be made to work in settings.json, and with glob patterns, it would be comparable what VsCode offers.

@mikeymop I didn't get what did you mean on what VsCode offers. VsCode offers separated extension which supports Helm syntax and it's features. The same is proposed here.

Moreover jsonschema provided above by @yodatak is a schema of Chart.yaml file, it doesn't automagically adds support of gotemplates syntax used by helm.

@cabrinha Here is what we need to do to get Helm support in Zed (from my point of view). We need some option, that would tell Zed to use Helm language for files stored in templates/** directories. I've seen this PR, but it doesn't support file path, so it should be somehow extended to also support full paths. I'll try to take a look there

[aohoyd]

@cabrinha I figured it out. By some reason path_suffixes option in config.toml doesn't accept globs. You can specify

  "file_types": {
    "Helm": [
      "**/templates/**/*.tpl",
      "**/templates/**/*.yaml",
      "**/templates/**/*.yml"
    ]
  }

in your local .zed/settings.json config and get Helm language auto detected in projects. It works perfectly for me now, thank you!

[cabrinha]

@cabrinha I figured it out. By some reason path_suffixes option in config.toml doesn't accept globs. You can specify

  "file_types": {
    "Helm": [
      "**/templates/**/*.tpl",
      "**/templates/**/*.yaml",
      "**/templates/**/*.yml"
    ]
  }

in your local .zed/settings.json config and get Helm language auto detected in projects. It works perfectly for me now, thank you!

@aohoyd nice find, but why is the CI still failing?

What needs to happen in this PR to get this extension merged in and natively supported in Zed?

[notpeter]

@cabrinha I figured it out. By some reason path_suffixes option in config.toml doesn't accept globs. What needs to happen in this PR to get this extension merged in and natively supported in Zed?

Since those globs are not supported can you remove them from here: languages/helm/config.toml and update the submodule commit?

We should also add a helm to the official languages docs including the suggested file_types configuration for Helm.

I fixed the sort order so tests should pass now.

[hedgieinsocks]

Thank you, it does work! But I encourage everyone who's waiting for this to be merged, in the meantime, to also visit the upstream issue https://github.com/ngalaiko/tree-sitter-go-template/issues/23 and motivate the dev to review and fix it. Since it's likely that your helm charts use dash (-) to combine 2 templates into a single value.

[hedgieinsocks]

@cabrinha you might want to add "**/helmfile.d/**/*.yaml" to the common patterns when adding commit to the docs as suggested above

[cabrinha]

@cabrinha I figured it out. By some reason path_suffixes option in config.toml doesn't accept globs. What needs to happen in this PR to get this extension merged in and natively supported in Zed?

Since those globs are not supported can you remove them from here: languages/helm/config.toml and update the submodule commit?

We should also add a helm to the official languages docs including the suggested file_types configuration for Helm.

I fixed the sort order so tests should pass now.

I'm sure I will be flamed for "doing it wrong" but, here you go: https://github.com/zed-industries/zed/pull/19095

[qvalentin]

@cabrinha nice work :D. I'm the current maintainer of helm-ls and also contributor to tree-sitter-go-template and would love to see them being used in zed.

---

Here are some of my viewpoints for the discussed topics:

Like mentioned many posts above, this is no explicit helm issue, but more like a templating include issue in the yaml lsp.

@selfisch yaml-language-server will probably never implement support for templating languages, it would be better to use a specific lsp for the template language like helm-ls.

---

I would argue that properly supporting jsonschema overrides in yaml-language-server is the best place to divert focus towards.

@mikeymop this PR may be interesting for you: https://github.com/redhat-developer/yaml-language-server/pull/962

---

Thank you, it does work! But I encourage everyone who's waiting for this to be merged, in the meantime, to also visit the upstream issue https://github.com/ngalaiko/tree-sitter-go-template/issues/23 and motivate the dev to review and fix it. Since it's likely that your helm charts use dash (-) to combine 2 templates into a single value.

@hedgieinsocks I just opened https://github.com/tree-sitter-grammars/tree-sitter-yaml/issues/12 for this, as its a problem with the yaml tree-sitter grammar. If anyone has some tree-sitter and/or C knowledge you could help there.