This language server adds support for Ansible and is currently used by the following projects:
- Ansible extension for vscode/codium
- Ansible extension for vim and neovim
- Ansible client for Emacs LSP
Releases are published to npmjs registry.
Ansible keywords, module names and module options, as well as
standard YAML elements are recognized and highlighted distinctly. Jinja
expressions are supported too, also those in Ansible conditionals (when,
failed_when, changed_when, check_mode), which are not placed in double
curly braces.
The screenshots and animations presented in this README have been taken using the One Dark Pro theme. The default VS Code theme will not show the syntax elements as distinctly unless customized. Virtually any theme other than default will do better.
While you type, the syntax of your Ansible scripts is verified and any feedback is provided instantaneously.
On opening and saving a document, ansible-lint is executed in the background
and any findings are presented as errors. You might find it useful that
rules/tags added to warn_list (see
Ansible Lint Documentation)
are shown as warnings instead.
If you also install
yamllint,ansible-lintwill detect it and incorporate into the linting process. Any findings reported byyamllintwill be exposed in VSCode as errors/warnings.
Note
If ansible-lint is not installed/found or running ansible-lint results in
errors, it will fall back to ansible --syntax-check for validation.
The extension tries to detect whether the cursor is on a play, block or task etc. and provides suggestions accordingly. There are also a few other rules that improve the user experience:
- the
nameproperty is always suggested first - on module options, the required properties are shown first, and aliases are shown last, otherwise ordering from the documentation is preserved
- FQCNs (fully qualified collection names) are inserted only when necessary;
collections configured with the
collectionskeyword are honored. This behavior can be disabled in extension settings.
When writing a Jinja expression, you only need to type "{{<space>, and it will
be mirrored behind the cursor (including the space). You can also select the
whole expression and press space to put spaces on both sides of the
expression.
Documentation is available on hover for Ansible keywords, modules and module
options. The extension works on the same principle as ansible-doc, providing
the documentation straight from the Python implementation of the modules.
You may also open the implementation of any module using the standard Go to
Definition operation, for instance, by clicking on the module name while
holding ctrl/cmd.
For standalone usage with a language-server client, the Ansible language server can be installed from npm with the following command:
npm install -g @ansible/ansible-language-serverFor details on settings, their descriptions and their default values refer to settings.
For details on setting up the development environment and debugging refer to the development document.
- Ansible 2.9+
- Ansible Lint (required, unless you disable linter support)
- yamllint (optional)
For Windows users, this extension works perfectly well with extensions such as
Remote - WSL and Remote - Containers.
If you have any other extension providing language support for Ansible, you might need to uninstall it first.
- The shorthand syntax for module options (key=value pairs) is not supported.
- Only Jinja expressions inside Ansible YAML files are supported. To do syntax highlighting of Jinja template files, you'll need to install other extensions.
- Jinja blocks (inside Ansible YAML files) are not supported yet.
Based on the good work done by Tomasz Maciążek