GitHub - redhat-developer/yaml-language-server: Language Server for YAML Files (original) (raw)

CI version Coverage Status

Supports JSON Schema drafts 04, 07, 2019-09, and 2020-12. Starting from 1.0.0 the language server uses eemeli/yaml as the new YAML parser, which strictly enforces the specified YAML spec version. Default YAML spec version is 1.2, it can be changed with yaml.yamlVersion setting.

Features

  1. YAML validation:
    • Detects whether the entire file is valid yaml
  2. Validation:
    • Detects errors such as:
      * Node is not found
      * Node has an invalid key node type
      * Node has an invalid type
      * Node is not a valid child node
    • Detects warnings such as:
      * Node is an additional property of parent
  3. Auto completion:
    • Auto completes on all commands
    • Scalar nodes autocomplete to schema's defaults if they exist
  4. Hover support:
    • Hovering over a node shows description if available
  5. Document outlining:
    • Shows a complete document outline of all nodes in the document

Language Server Settings

The following settings are supported:

Suppressing diagnostics

You can suppress specific validation warnings on a per-line basis by adding a # yaml-language-server-disable comment on the line immediately before the one producing the diagnostic.

Suppress all diagnostics on a line

yaml-language-server-disable

version: 123

Suppress only specific diagnostics

Provide one or more message substrings (comma-separated, case-insensitive). Only diagnostics whose message contains a matching substring will be suppressed; the rest are kept.

yaml-language-server-disable Incorrect type

version: 123

yaml-language-server-disable Incorrect type, not accepted

version: 123

The substrings are matched against the diagnostic message text reported by the language server.

Adding custom tags

In order to use the custom tags in your YAML file you need to first specify the custom tags in the setting of your code editor. For example, we can have the following custom tags:

"yaml.customTags": [ "!Scalar-example scalar", "!Seq-example sequence", "!Mapping-example mapping" ]

The !Scalar-example would map to a scalar custom tag, the !Seq-example would map to a sequence custom tag, the !Mapping-example would map to a mapping custom tag.

We can then use the newly defined custom tags inside our YAML file:

some_key: !Scalar-example some_value some_sequence: !Seq-example

Associating a schema to a glob pattern via yaml.schemas:

yaml.schemas applies a schema to a file. In other words, the schema (placed on the left) is applied to the glob pattern on the right. Your schema can be local or online. Your schema path must be relative to the project root and not an absolute path to the schema.

For example: If you have project structure

myProject

> myYamlFile.yaml

you can do

yaml.schemas: { "https://json.schemastore.org/composer": "/myYamlFile.yaml" }

and that will associate the composer schema with myYamlFile.yaml.

More examples of schema association:

Using yaml.schemas settings

Single root schema association:

When associating a schema it should follow the format below

yaml.schemas: { "url": "globPattern", "Kubernetes": "globPattern" }

e.g.

yaml.schemas: { "https://json.schemastore.org/composer": "/*" }

e.g.

yaml.schemas: { "kubernetes": "/myYamlFile.yaml" }

e.g.

yaml.schemas: { "https://json.schemastore.org/composer": "/*", "kubernetes": "/myYamlFile.yaml" }

On Windows with full path:

yaml.schemas: { "C:\Users\user\Documents\custom_schema.json": "someFilePattern.yaml", }

On Mac/Linux with full path:

yaml.schemas: { "/home/user/custom_schema.json": "someFilePattern.yaml", }

Since 0.11.0 YAML Schemas can be used for validation:

"/home/user/custom_schema.yaml": "someFilePattern.yaml"

A schema can be associated with multiple globs using a json array, e.g.

yaml.schemas: { "kubernetes": ["filePattern1.yaml", "filePattern2.yaml"] }

e.g.

"yaml.schemas": { "http://json.schemastore.org/composer": ["/"], "file:///home/johnd/some-schema.json": ["some.yaml"], "../relative/path/schema.json": ["/config.yaml"], "/Users/johnd/some-schema.json": ["some.yaml"], }

e.g.

"yaml.schemas": { "kubernetes": ["/myYamlFile.yaml"] }

e.g.

"yaml.schemas": { "http://json.schemastore.org/composer": ["/*"], "kubernetes": ["/myYamlFile.yaml"] }

Multi root schema association:

You can also use relative paths when working with multi root workspaces.

Suppose you have a multi root workspace that is laid out like:

My_first_project: test.yaml my_schema.json My_second_project: test2.yaml my_schema2.json

You must then associate schemas relative to the root of the multi root workspace project.

yaml.schemas: { "My_first_project/my_schema.json": "test.yaml", "My_second_project/my_schema2.json": "test2.yaml" }

yaml.schemas allows you to specify json schemas that you want to validate against the yaml that you write. Kubernetes is an optional field. It does not require a url as the language server will provide that. You just need the keyword kubernetes and a glob pattern.

Nested Schema References

Suppose a file is meant to be a component of an existing schema (like a job.yaml file in a circleci orb), but there isn't a standalone schema that you can reference. If there is a nested schema definition for this subcomponent, you can reference it using a url fragment, e.g.:

yaml.schemas: { "https://json.schemastore.org/circleciconfig#/definitions/jobs/additionalProperties": "/src/jobs/*.yaml", }

NoteThis will require reading your existing schema and understanding the schemastore structure a bit. (TODO: link to a documentation or blog post here?)

Using inlined schema

It is possible to specify a yaml schema using a modeline.

yaml-language-server: $schema=

Also it is possible to use relative path in a modeline:

yaml-language-server: $schema=../relative/path/to/schema

or absolute path:

yaml-language-server: $schema=/absolute/path/to/schema

or IntelliJ compatible format:

$schema:

Schema priority

The following is the priority of schema association in highest to lowest priority:

  1. Modeline
  2. CustomSchemaProvider API
  3. yaml.settings
  4. Schema association notification
  5. Schema Store

Containerized Language Server

An image is provided for users who would like to use the YAML language server without having to install dependencies locally.

The image is located at quay.io/redhat-developer/yaml-language-server

To run the image you can use:

docker run -it quay.io/redhat-developer/yaml-language-server:latest

Language Server Protocol version

yaml-language-server use vscode-languageserver@7.0.0 which implements LSP 3.16

Language Server Protocol extensions

SchemaSelectionRequests

SupportSchemaSelection Notification

The support schema selection notification is sent from a client to the server to inform server that client supports JSON Schema selection.

Notification:

SchemaStoreInitialized Notification

The schema store initialized notification is sent from the server to a client to inform client that server has finished initializing/loading schemas from schema store, and client now can ask for schemas.

Notification:

GetAllSchemas Request

The get all schemas request sent from a client to server to get all known schemas.

Request:

Response:

interface JSONSchemaDescriptionExt { /**

GetSchemas Request

The request sent from a client to server to get schemas used for current document. Client can use this method to indicate in UI which schemas used for current YAML document.

Request:

Response:

interface JSONSchemaDescriptionExt { /**

Clients

This repository only contains the server implementation. Here are some known clients consuming this server:

Developer Support

Getting started

  1. Install prerequisites:
  2. Fork and clone this repository
  3. Install the dependencies
    cd yaml-language-server
    $ npm install
  4. Build the language server
  5. The new built server is now located in ./out/server/src/server.js.
    node (Yaml Language Server Location)/out/server/src/server.js [--stdio]

Connecting to the language server via stdio

We have included the option to connect to the language server via stdio to help with integrating the language server into different clients.

ESM and UMD Modules

Building the YAML Language Server produces CommonJS modules in the /out/server/src directory. In addition, a build also produces UMD (Universal Module Definition) modules and ES Modules (ESM) in the /lib directory. That gives you choices in using the YAML Language Server with different module loaders on the server side and in the browser with bundlers like webpack.

CI

We use a GitHub Action to publish each change in the main branch to npm registry with the next tag. You may use the next version to adopt the latest changes into your project.