vscode-yaml: schema validation, Kubernetes support, and a strict YAML 1.2 parser

One extension covers compose files, pipelines and manifests

The extension contributes the yaml language id and recognises .yml, .eyaml, .eyml and .yaml files. It also registers itself for ansible, azure-pipelines, dockercompose, github-actions-workflow, home-assistant, manifest-yaml and spring-boot-properties-yaml, so one install covers the places where YAML actually turns up in daily work rather than only hand written data files. Underneath, the extension delegates to yaml-language-server, and the project description names built-in Kubernetes schema support as a headline feature.

The important consequence is that everything on offer, validation, outlining, completion, hover and formatting, is driven by whichever schema applies to the file. A YAML file with no associated schema still gets parsing help and diagnostics about the file as a whole, but you get no knowledge of individual keys, because the key names live in the schema. That single design choice explains most of the behaviour described in the sections that follow.

The parser changed at 1.0.0 and now enforces the spec you pick

Since version 1.0.0 the language server uses the eemeli/yaml parser rather than one of its own, and that switch is the reason a file that used to open quietly can now be reported as invalid. The parser strictly enforces the YAML spec version it has been given. The default is 1.2, and the documentation points users with older files to set yaml.yamlVersion to 1.1 rather than leaving them to guess why diagnostics appeared.

This is a deliberate trade. One parser and one spec means no silent acceptance of a construct the spec does not define, and it means the same file is judged the same way by every developer running the extension. It also means the extension holds an opinion about what valid YAML is, and a repository full of legacy manifests may need the 1.1 switch before the validation is worth anything. The 1.2 default is the right choice for new work, but it is a real migration decision for older code bases, not a detail.

Completion and hover are three separate schema driven layers

Completion is not a keyword list. With Ctrl+Space the extension proposes keys, values and structure taken from the schema that applies to the file, and it fills in a default value when the schema declares one. Two settings shape what you see. yaml.disableDefaultProperties removes not required properties with default values from the suggestion text, which helps when a schema is noisy. yaml.suggest.parentSkeletonSelectedFirst makes you choose a parent skeleton before the remaining properties appear, but that setting stops applying once the YAML object is not empty, at which point all properties and skeletons come back.

Hover carries three independent layers, each with its own switch. Schema descriptions appear when the schema provides them. Anchor information is shown when yaml.hoverAnchor is enabled, and it is on by default. The schema source appears in the tooltip when yaml.hoverSchemaSource is enabled, also on by default, and that toggle is the quickest way to find out which schema a completion came from when several schemas overlap.

Formatting options and the 5000 item ceiling on symbols

The formatter is on by default and can be switched off with yaml.format.enable. The printing options resemble a Prettier style setup, and the repository does carry a .prettierrc.json. yaml.format.printWidth wraps at 80 characters. yaml.format.proseWrap takes always, never or preserve and defaults to preserve. yaml.format.singleQuote switches output to single quotes, yaml.format.bracketSpacing controls spaces inside brackets, and yaml.format.trailingComma keeps trailing commas in JSON like segments. On type formatting also runs on newline and indents mappings and array items for you as you type.

The ceiling worth knowing about is yaml.maxItemsComputed, which defaults to 5000. It limits how many document symbols and folding regions the server computes, and the reason given is performance. A very large generated manifest therefore does not produce a complete outline, and the limit applies to folding as well as to the symbol list. Document outlining is available through Ctrl+Shift+O, populating the Outline view and the Go to Symbol list.

Installing from the marketplace and the engine floors in package.json

The project documentation gives no install command, so the route is the editor itself. The extension is published under the publisher name redhat with the identifier redhat.vscode-yaml, and the README carries badges for the Visual Studio Marketplace and the OpenVSX Registry, so you can search for that identifier in the extension pane. The floors come from package.json, which states a minimum VS Code version and a minimum npm version for anyone building from source rather than installing the package.

  "engines": {
    "npm": ">=7.0.0",
    "vscode": "^1.91.0"
  }

A VS Code older than the stated version is where the install quietly fails to activate, so check that before blaming the extension.

The activation list in package.json is also worth reading, because it explains why the extension starts for a compose file or a GitHub Actions workflow and not only for files that end in .yml.

  "activationEvents": [
    "onLanguage:yaml",
    "onLanguage:ansible",
    "onLanguage:azure-pipelines",
    "onLanguage:dockercompose",
    "onLanguage:github-actions-workflow"
  ]

The same file records that untrusted workspaces are supported and that virtual workspaces are enabled, which matters for teams that work in a browser based editor or a remote container.

Kubernetes manifests and the two schema sources behind them

Kubernetes support has two layers. A file that yaml.schemas maps to the kubernetes keyword gets a schema built for the version named in yaml.kubernetesVersion. If that setting is omitted, the extension falls back to a predefined default Kubernetes version, so a cluster that has moved on from that default may not match what the server checks against your manifests.

Beyond the built-in resources, yaml.kubernetesCRDStore.enable pulls schemas for well known Custom Resource Definitions from a catalog hosted in the datreeio CRDs-catalog repository, with the base address held in yaml.kubernetesCRDStore.url. The same association machinery covers everything outside Kubernetes through the SchemaStore: yaml.schemaStore.enable is true by default, and yaml.schemaStore.url points at the schemastore.org catalog. For files you own, yaml.schemas maps glob patterns to your own schema, and yaml.disableSchemaDetection can switch off detection for a matched pattern, though modelines still apply.

Where the extension is the wrong tool for the job

Three limits are worth stating plainly. First, the strict parser with a 1.2 default means a repository of older YAML needs the 1.1 switch before diagnostics mean anything. Second, the 5000 item cap on symbols and folding means the outline is not a map of a very large generated file. Third, and most importantly, this is an editor feature rather than a pipeline gate. It is scoped to the language ids listed in package.json, so a YAML file that is never opened in VS Code is never checked, and a merge request that touches only a remote manifest gets no feedback.

The project is built on yaml-language-server, and that server is the part you would point at a continuous integration job, but running it headless is a separate setup that this documentation does not cover. The same goes for undoing a formatting run that rewrote more of a file than you wanted, which the documentation does not address either. If either of those matters to you, budget for the server rather than the extension.

MIT licence and a release cadence close behind the last push

Red Hat publishes the extension under the MIT licence, so the code and the packaged extension carry permissive reuse and modification terms, and the repository keeps a thirdpartynotices.txt file for the bundled third party components. Anyone building the extension from source also inherits those notices, which matters for internal distribution.

On maintenance, the project is current. The last push was on 2026-10-19, and the release history shows 2.0.0 published on 2026-10-16, 1.25.0 on 2026-10-09 and 1.24.0 on 2026-07-07, while package.json already carries version 2.1.0. The gap between the most recent published tag and the version in package.json suggests the 2.1.0 build is still in flight, which is worth knowing if you pin an exact extension version in a shared developer image. The repository layout supports that kind of work directly, with a src directory, a build directory, a test directory, a smoke-test directory, a docs directory and a CHANGELOG.md alongside the extension manifest.

Editorial conclusion

Adopt vscode-yaml if your team edits YAML in VS Code and wants schema driven completion and validation without wiring a separate linter, and skip it if you need a gate that runs outside the editor or if your repository lives on YAML 1.1 and you cannot change the parser setting. Before rolling it out, open one legacy manifest and one Kubernetes file to confirm the strict 1.2 parser accepts them, then check that the schemas you expect are actually resolved for your file globs. If the parser rejects files your team has lived with for years, the first change to make is yaml.yamlVersion, not the extension itself.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. redhat-developer/vscode-yaml on GitHub
5. Releases