This section explains what is ALS, how does it work, who should use it, and how is ALS used today.
The AML Language Server (ALS) is an implementation of the Microsoft Language Server Protocol (LSP) with a primary focus towards API tooling and API specifications, such as RAML, OpenAPI, and AsyncAPI. The objective of the ALS is to simplify API development by relying on the LSP to support API specifications in as many integrated development environments (IDEs) as possible. Besides API tooling and API specifications, you can extend the ALS to support any type of documents.
The supported types of documents include:
- RAML (0.8 and 1.0)
- OpenAPI (2.0 and 3.0)
- AsyncAPI (2.0)
- Any other type of documents via AML dialect (1.0)
- JsonSchema
The ALS relies on the Anything Modeling Language (AML), more specifically on AML's dialect functionality. The ALS uses the AML to provide language server functionalities, such as validation, for the documents (also referred to as "instances" or "instance documents"). The ALS can also deduce possible contextual values at any given position of an instance document.
Using the representation of an API in a model, you can generate an outline or Document Symbol to render a more visual abstraction of an instance.
The ALS is the answer for you if you are interested in authoring specification documents, including out-of-the-box API specification documents (API definitions), but also any custom document using AML's dialect functionality, using your favorite IDE. Additionally, developers can use the ALS to create IDE plugins based on the LSP.
Today, the ALS is used in MuleSoft Anypoint Design Center and in Anypoint Studio to provide feedback when authoring API definitions. You can see a preview in the following section.
This section explains how to use the ALS as a language server.
The ALS can run as a standalone language server that you can use with any IDE. Most modern IDEs either natively support the LSP or provide a way to support the LSP using a plugin.
You can build the ALS server JAR:
sbt serverJVM/assemblyand then ran independently like so:
java -jar als/als-server/jvm/target/scala-2.12/als-server-assembly-%VERSION%.jar --port <port name>You can build the targz to run it in a lsp-client for example:
sbt buildNodeJsClient
cd als-server/js/node-package/
npm packYou can build the targz to run it in monaco for example:
sbt buildJsServerLibrary
cd als-server/js/node-package/
npm packYou'll find the tgz at: als-server/js/node-package/aml-org-als-server-%VERSION%.tgz
You can adapt the Microsoft VSCode LSP example by following these instructions, which guides you to successfully run an ALS client in VSCode.
Here are some examples of how to use the ALS with other IDEs:
- VS Code extension: instructions on how to plug ALS into the VSCode LSP client
- Sublime Text 3 extension: instructions for plugin ALS into ST3 LSP client
- IntelliJ extension: instructions for plugin ALS into IntelliJ's LSP client
- Java LSP4J: example on how to connect to a LSP server in Java using LSP4J, which can then be used for connecting IDE features to a plugin
This sections illustrates previews of different IDEs.
This section explains how the LSP is supported in ALS.
The Language Server Protocol (LSP) is a tooling standardization for IDEs that defines a client-server architecture used to abstract a general implementation of used language-specific smarts.
In this client-server architecture, the server works as a standalone (write once with consistent behaviour) functionality provider. With this server, the client (each IDE plugin) independently understands the LSP messaging and communication, agnostic of the server implementation.
Currently, the following LSP capabilities are supported:
Besides LSP messages, we also support other custom operations, which are detailed here
If you are interested in contributing to this project, ensure that you read our contributing guidelines.