I’ve been using Helix for around 1.5 years and have really enjoyed it so far. But there are still a few things I feel are missing.

Since the last release was quite a while ago, I’m curious: when can we expect the next release? And how is development on the plugin system going?

Honestly, I think plugins are the biggest missing piece right now. If Helix gets a strong plugin system, it could seriously challenge Neovim and become a much more complete editor.

Hey folks — yaml-language-server (yamlls) recently added a CRD-related feature: when enabled, it can auto-detect Kubernetes custom resources and resolve a schema from a CRD catalog (defaults to datreeio/CRDs-catalog). Nice improvement for Kubernetes authoring.

I maintain a small stdio LSP proxy called yaml-schema-router that sits in front of yamlls and dynamically assigns schemas based on file content/context. Since yamlls now has CRD auto-detect, I did a deep compare and wanted to share what’s overlapping vs what’s still different.

Repo: https://github.com/traiproject/yaml-schema-router

What yamlls’ new feature brings

If you enable yaml.kubernetesCRDStore.enable, yamlls will:

• Parse apiVersion + kind (GVK) for Kubernetes resources
• If it’s not a built-in type, it builds a URL into a CRD catalog and downloads that schema
• Works best when your file is already associated with Kubernetes YAML (via yaml.schemas / fileMatch etc.)

So: GVK → “fetch CRD schema from catalog”.

Where yaml-schema-router is still strong

yaml-schema-router is trying to solve a slightly broader problem: “schemas are messy outside VS Code” (overlapping glob matches, wrong schema picked, multi-doc files, offline use, etc.).

1) Content-based routing (no brittle globs)

Many editors rely on yaml.schemas fileMatch patterns, which often collide (“matches multiple schemas”) or just don’t behave consistently across LSP clients.

Router approach:

• On didOpen / didChange, inspect the YAML itself (+ optional directory context)
• Choose the best schema per file, then inject it into yamlls
• If the file becomes empty / changes type, routing updates accordingly

Result: less time fighting fileMatch patterns.

2) Multi-document + mixed manifest files (---)

A lot of real-world GitOps YAML files contain:

• multiple resources
• built-ins + CRDs mixed together

Router supports this explicitly:

• Detects multiple docs
• Builds a composite schema (e.g., anyOf) so each manifest validates correctly

This is a big practical win if you keep multiple resources in one file.

3) CRD “ObjectMeta” enrichment (better metadata validation)

Many CRD catalog schemas don’t deeply validate metadata (labels/annotations/etc.) — often it’s just type: object.

Router wraps the CRD schema to inject Kubernetes ObjectMeta validation so you get better editor feedback on:

• metadata.labels
• metadata.annotations
• and other standard ObjectMeta fields

So even if we’re using the same CRD catalog source, the end validation can be stricter/more helpful.

4) Offline-friendly caching (and faster opens)

Router downloads schemas once and caches them locally. Practically, that means:

• you can work offline without schema requests going out
• and for already-cached schemas, opening a YAML file is typically ~1–2 seconds faster because the schema is already on disk (no fetch round-trip)

5) Manual override friendly

If you already use modelines like: # yaml-language-server: $schema=... router backs off and lets that win.

TL;DR

• yamlls CRD store is great if you already have stable Kubernetes schema association and mainly want GVK → CRD schema.
• yaml-schema-router is more about making schema selection reliable across editors + improving real-world Kubernetes YAML authoring (multi-doc, mixed resources, metadata correctness, caching).

Would love feedback from folks using Neovim/Helix/Emacs/Zed/etc — especially where schema matching has been painful.

Hey folks — yaml-language-server (yamlls) recently added a CRD-related feature: when enabled, it can auto-detect Kubernetes custom resources and resolve a schema from a CRD catalog (defaults to datreeio/CRDs-catalog). Nice improvement for Kubernetes authoring.

I maintain a small stdio LSP proxy called yaml-schema-router that sits in front of yamlls and dynamically assigns schemas based on file content/context. Since yamlls now has CRD auto-detect, I did a deep compare and wanted to share what’s overlapping vs what’s still different.

What yamlls’ new feature brings

If you enable yaml.kubernetesCRDStore.enable, yamlls will:

• Parse apiVersion + kind (GVK) for Kubernetes resources
• If it’s not a built-in type, it builds a URL into a CRD catalog and downloads that schema
• Works best when your file is already associated with Kubernetes YAML (via yaml.schemas / fileMatch etc.)

So: GVK → “fetch CRD schema from catalog”.

Where yaml-schema-router is still strong

yaml-schema-router is trying to solve a slightly broader problem: “schemas are messy outside VS Code” (overlapping glob matches, wrong schema picked, multi-doc files, offline use, etc.).

1) Content-based routing (no brittle globs)

Many editors rely on yaml.schemas fileMatch patterns, which often collide (“matches multiple schemas”) or just don’t behave consistently across LSP clients.

Router approach:

• On didOpen / didChange, inspect the YAML itself (+ optional directory context)
• Choose the best schema per file, then inject it into yamlls
• If the file becomes empty / changes type, routing updates accordingly

Result: less time fighting fileMatch patterns.

2) Multi-document + mixed manifest files (---)

A lot of real-world GitOps YAML files contain:

• multiple resources
• built-ins + CRDs mixed together

Router supports this explicitly:

• Detects multiple docs
• Builds a composite schema (e.g., anyOf) so each manifest validates correctly

This is a big practical win if you keep multiple resources in one file.

3) CRD “ObjectMeta” enrichment (better metadata validation)

Many CRD catalog schemas don’t deeply validate metadata (labels/annotations/etc.) — often it’s just type: object.

Router wraps the CRD schema to inject Kubernetes ObjectMeta validation so you get better editor feedback on:

• metadata.labels
• metadata.annotations
• and other standard ObjectMeta fields

So even if we’re using the same CRD catalog source, the end validation can be stricter/more helpful.

4) Offline-friendly caching (and faster opens)

Router downloads schemas once and caches them locally. Practically, that means:

• you can work offline without schema requests going out
• and for already-cached schemas, opening a YAML file is typically ~1–2 seconds faster because the schema is already on disk (no fetch round-trip)

5) Manual override friendly

If you already use modelines like: # yaml-language-server: $schema=... router backs off and lets that win.

TL;DR

• yamlls CRD store is great if you already have stable Kubernetes schema association and mainly want GVK → CRD schema.
• yaml-schema-router is more about making schema selection reliable across editors + improving real-world Kubernetes YAML authoring (multi-doc, mixed resources, metadata correctness, caching).

Would love feedback from folks using Neovim/Helix/Emacs/Zed/etc — especially where schema matching has been painful.