Langium: build a language, its editor support and its tooling in TypeScript

For the person who has to write the language, not use it

Eclipse Langium is a language engineering tool for TypeScript with built-in support for the Language Server Protocol. The framework is described as an all-in-one solution for building programming languages, domain specific languages, code generators, interpreters and compilers, and it serves as a spiritual successor to the Eclipse Xtext framework.

The word that matters in that list is the first one. This is not a library for consuming a language, or a parser generator you drop into an existing program. It is a framework for the person whose job is to define a language in the first place, and it assumes the language will be used by other people, in an editor, while they work.

That assumption shapes everything else. The same language definition has to produce a parser, an abstract model, validation, and an editor experience, and the framework's bet is that all of that can come from one description. The three headline properties in the README make the argument. Semantics First means you build the abstract model of your language in parallel to its syntax. Lean by Default, Customizable by Design means the infrastructure you need comes from defining a grammar, and every detail can be fine tuned through the dependency injection system if that is not enough. Write Once, Run Everywhere is the payoff, since a language built with Langium can run in all kinds of IDEs and browsers, or be embedded in CLIs and server applications.

The audience is a language implementor, a platform team building a configuration DSL, or a tool vendor who has been tempted to hand-roll a parser and a language server and has realised how much of that work is not the interesting part.

The grammar is the source of the abstract model, not just the syntax

The parsing architecture is the part worth understanding before writing any code.

Langium parsers are powered by Chevrotain, and the parser is not the interesting output. The interesting output is the abstract syntax tree, because in Langium you describe the language with a grammar declaration language, and from that description the framework derives the tree structure, the scopes and the type system.

The semantics first claim is that you build the abstract model of your language in parallel to its syntax. In practice that means the grammar file describes both what the text looks like and what the elements mean, and the tree you get out of the parser already has the structure your language semantics need.

The reason this matters is that the alternative, a hand-written parser, separates the two layers by accident. You write a parser that produces tokens and shapes, and then you write a separate visitor or visitor-equivalent that builds the model, and the two drift apart. Langium's model makes that drift a compile error rather than a runtime surprise, which is the difference between a language you can evolve and a language you are afraid to touch.

The repository structure reflects the size of the job. There is a packages directory holding the framework and the VS Code extension, an examples directory, and scripts for versioning and publishing. The root package.json is a workspace file named langium-workspaces, and the build script compiles the TypeScript project and then builds the language server, the VS Code extension and each of the examples in turn.

The dependency injection container is the escape hatch

Lean by Default, Customizable by Design is the README's phrase for the arrangement, and the second half of it is a dependency injection system.

The idea is that a language is described by a grammar, and the framework supplies the standard machinery around it: how the parser is built, how the documents are indexed, how validation is triggered, how the language server responds, how cross references are resolved. The container is where all of that is wired together, and it is where you replace a piece of it.

This matters for a specific reason. The things you most often need to change in a language implementation are the ones that are hardest to change when they are baked in. The error message format, the scope provider that decides which declarations are visible from where, the way the document is serialised, the specific behaviour of the code generator. A framework that only lets you edit a grammar file is a framework that fails at exactly that point.

Langium's answer is to make the wiring explicit and replaceable, and the configuration services documentation exists for that purpose. The trade is the usual one: you can change everything, and you can also break the defaults in ways that are hard to diagnose, because a language that behaves oddly is often a language where one service was replaced with something subtly different.

The honest framing for an evaluating team is this. The grammar gets you a working language quickly, and the injection system is what lets you turn that working language into the language your users need. Both halves are the framework, and you will use them at different times.

The Language Server Protocol is the integration point

The reason a Langium language can appear in an IDE without a plugin written for each editor is the Language Server Protocol, and the framework's support for it is described as built in rather than bolted on.

The consequence is a decoupling that has a practical shape. The language server exposes features such as completion, diagnostics, formatting and navigation over a standard protocol, and any editor that speaks that protocol can host it. The README's write once, run everywhere claim leans on exactly this, adding that a language written using Langium can run in all kinds of IDEs and browsers, or be embedded in CLIs and server applications.

There is a dedicated package for the editor side of it, langium-vscode, which the root build script compiles alongside the framework and the examples, and the repository also has a .devcontainer directory and a .vscode directory, so the project is developed in the environment it targets.

The browser claim is backed by a real example rather than a promise. The minilogo repository implements a logo language dialect and shows how to integrate Langium in the browser, which is the harder half of the write once story, since a browser has no server to host a language server and the framework has to work inside a page.

For a team choosing a framework, the practical question is whether their editors speak the protocol. Almost all of them do, which is why the framework can claim reach without writing per editor integrations.

The install is one yeoman command, and the playground is the faster start

There are two ways in, and the README presents them in that order.

The fast one is the online playground at langium.org/playground, which the README suggests for building your first language. If you want to see the shape of a Langium project without installing anything, that is the place to start, and it is also the place to find out whether the grammar language is something you can work with before you commit a repository to it.

The real install is a yeoman generator. Once you are ready to set up a project, the README gives:

npm i -g yo generator-langium
yo langium

The generator produces a working project skeleton, and from there the build scripts in the generated project take over.

The toolchain behind it is modern and pinned tightly. The workspace package.json declares engines with node ^22.22.2 or ^24.15.0 or >=26, and npm >=10.2.3, with engineStrict enabled. The tests run on vitest, with a coverage script and a watch mode, linting is eslint with a flat config file, and there is a validate-exports script that checks the public API surface of the langium package. There is also a version:dependencies script that runs a TypeScript script to update versions, and a publish:updated script, both of which are the kind of release plumbing a monorepo with several packages needs.

The Node pins are narrow for a reason, and they are the first thing to check. A framework that pins three specific Node versions and turns on engineStrict will refuse to install on a machine with a slightly different runtime, which is exactly the kind of friction that shows up in a CI image nobody chose deliberately.

The examples are where the hard language problems are answered

The repository carries four examples, and each one exists to demonstrate a specific problem that comes up in real language engineering.

The arithmetics example shows how to create an expression language plus an interpreter, which is the smallest complete case: parse, build a model, evaluate. The domainmodel example shows how to create a language with fully qualified name identifiers, which is the case where name resolution stops being a lookup and becomes a cross reference problem. The requirements example creates a Langium project with multiple languages, which is how you model a system where several grammars share concepts. The statemachine example shows how to create a code generator, which is the point where the abstract model stops being a tree and starts being a program.

That set of four covers the arc: text in, model, behaviour, code out. Someone evaluating the framework can read them in that order and see the shape of each problem solved in the framework's idiom.

More complex examples live in separate repositories in the same GitHub organisation. The lox repository implements the Lox language from the book Crafting Interpreters, which is a full interpreter for a small dynamic language, and minilogo implements a logo language dialect as a demonstration of browser integration.

The documentation is organised in the same way, into Learning Langium, Reference, Recipes and Playground, and the README points at an overview for people new to building programming languages. The website itself is a separate repository, langium-website, which is worth knowing if you want to fix a documentation error.

MIT licensed, an SBOM per release, and a 4.x line with steady tags

Langium is fully MIT licensed, with the LICENSE file at the root of the repository, which means the framework can be embedded in commercial tooling without copyleft obligations.

The release cadence is regular for a framework of this size. Version 4.2.2 was published on 2026-04-16, 4.3.0 on 2026-07-02 and 4.4.0 on 2026-09-21, and the last push to the repository was on 2026-10-19. The major version is still in the 4.x range, so expect breaking changes at the next major bump and read the changelog before upgrading across a major version.

One practice is worth calling out because it is rare. To enhance supply chain security and offer users clear insight into project components, Langium now generates a Software Bill of Materials for every release, and these are published to the Eclipse Foundation SBOM registry, with access instructions in the Eclipse CSI security handbook. For a framework that ends up inside other people's build pipelines, having a published bill of materials per version is a real operational benefit rather than a compliance gesture.

The Eclipse Foundation umbrella is the other structural fact. It brings governance, the SBOM registry and a steady maintainer base, and it is the reason the project can afford a monorepo with a VS Code extension, four examples, a playground and a separate website repository.

Editorial conclusion

Langium fits a team that needs a domain specific language with a real editor experience and is willing to stay in the TypeScript ecosystem, since the language, the language server and the generated code all live in one language. It does not fit a JVM shop that already has Xtext tooling, and it does not fit a project where the language is small enough to hand-write a parser. Before you commit, run yo langium once and read the generated project, and check that the Node versions in engines, which are pinned narrowly, match the versions your CI actually uses.

Frequently asked questions

Official sources

1. eclipse-langium/langium on GitHub
2. License: MIT
3. Project website
4. README
5. Releases