# Chevrotain and the ten-year gap between its releases and its install snippet

> A JavaScript parser toolkit with built-in LL(K) support and grammars written as plain sources with no code generation. Its GitHub releases stop at 0.5.21 from March 2016, its own install example pins 13.2.0, and its root manifest has no test script at all.

**Chevrotain/chevrotain** — Parser Building Toolkit for JavaScript

- Repository: https://github.com/Chevrotain/chevrotain
- Website: https://chevrotain.io
- Stars: 2,804 · Forks: 221
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/chevrotain-chevrotain

## The releases stop at 0.5.21 while the install example pins 13.2.0

Three releases are attached to this repository: v0.5.21 on 2016-03-12, v0.5.20 on 2016-03-09 and v0.5.19 on 2016-03-06. Three releases in six days, and then nothing for the following decade, while the branch took a push on 2026-10-02. The installation section tells a different story about where the version lives. Alongside the npm line, it offers browser ESM bundles for the latest build and for an explicit version, and the explicit version it names is 13.2.0, in both an unminified and a minified file:

```bash
npm install chevrotain
```

So the number in the release list and the number in the install instructions are three orders of magnitude apart, and both are correct about their own thing. Nothing in the README explains the difference, which means the version you depend on has to come from the npm registry rather than from the release page.

## Compatibility is a pointer to a manifest that is not in the root

The compatibility section commits to nothing numeric. It says Chevrotain supports modern JavaScript runtimes, which it defines as the Node.js versions declared in the published package's package.json engines field, plus current evergreen browsers; that it may rely on modern standard library APIs; and that the relevant tsconfig files and package engines fields hold the exact requirements. It then says legacy runtimes are not supported, and that older browsers may need transpilation and polyfills. The file you land on when you clone this repository is not that file. The manifest at the root is named root, marked private, and declares workspaces of packages/* and examples/*, with no version and no engines field. The engines field the section relies on belongs to the published sub-package.

## Grammars are JavaScript source, and LL(*) comes from someone else

The central design claim is that grammars are written as pure JavaScript sources with no code generation phase, which removes the build step most parser toolkits impose. The grammar class is LL(K), built in. Anything stronger comes from outside: the introduction points at a third party plugin for LL(*) grammars, and the resources list includes a write-up on ALL(*) lookahead in Langium, whose own project is listed among the users. The distinction matters when you choose the toolkit, because the two classes differ in what you can write and in how much error handling a grammar needs. It also means the stronger capability has its own version and its own maintenance, separate from the library whose documentation you are reading. Chevrotain's own summary adjectives, blazing fast and feature rich, both link to its performance page.

## The root manifest releases with lerna, installs with bun, runs tasks with turbo

The root manifest declares its package manager as bun at 1.3.10, and then hands three different jobs to three different tools. Releasing is lerna: release:version runs the ci task and then lerna version with force-publish, and release:publish runs lerna publish from-git with --yes and --no-verify-access. Building is turbo and tsc, with compile running turbo run clean before tsc --build. The ci entry point is npm-run-all, which resolves to the npm-run-all2 package, running a prettier check and then ci:subpackages, which is turbo run ci. The version script ends with git add on the bun lockfile, so the release path stages a file into git as part of versioning. Formatting is prettier, and it is invoked with --experimental-cli on every TypeScript, JavaScript, JSON, Markdown, YAML, CSS and HTML file in the tree.

## A test framework and a coverage tool, with no test script

The root devDependencies include mocha at 11.7.5, chai at 6.2.2 and c8 at 12.0.0 for coverage, and the root scripts list has no test entry at all. What it has instead is ci, which validates formatting and then calls ci:subpackages, and that in turn is turbo run ci, meaning each package runs its own ci task. So the tests are reachable only through the per-package delegation, and a contributor reading the root manifest sees a test framework, an assertion library and a coverage tool with nothing to invoke. The compile task has the same shape of dependency, since turbo run clean expects a clean task that the root does not define, and turbo has to find it in the packages.

## Conventional commits are enforced twice and formatting covers nine file types

Commit discipline is set up in two independent places. There is a .czrc file at the root, a commitizen badge in the README and cz-conventional-changelog in the devDependencies, and there is a commitlint configuration extending the conventional preset, with matching pinned versions of the commitlint CLI and config. Formatting runs through prettier with endOfLine set to lf, and lint-staged applies the same write command to the same nine glob patterns on staged files, with a .prettierignore alongside. A husky directory and a prepare script that runs husky wire the hooks, and the CI badge points at a workflow named ci.yml. The practical effect is that a commit is judged twice by two different tools before it lands, and that markdown, YAML, CSS and HTML are held to the same formatting standard as source files.

## The adoption list pins one commit, two branches, and skips a source link once

The where used section names five projects. HyperFormula, a spreadsheet-like calculation engine, links its parser source to a single fixed commit. Langium, a language engineering tool with Language Server Protocol support, gets no source link at all. Prettier-Java points at a package directory on a branch, the JHipster Domain Language parser points at a directory in the generator repository, and Argdown points at its parser file in the argdown-core package. So the list meant to demonstrate adoption mixes a frozen reference with three moving ones, and the second entry is the only one without a pointer to the code that uses the library. The tree around it carries a LICENSE.txt and a NOTICE.txt, an agents.md in lower case beside an upper case CONTRIBUTING.md, a .devcontainer, renovate.json5 for dependency updates, and an examples directory whose six subdirectories, from grammars to webpack, are themselves declared as workspaces.

## Conclusion

Chevrotain suits a team writing a grammar in JavaScript and wanting to skip a code generation step, and it is the right tool when the grammar is LL(K) shaped or you are willing to depend on a separate plugin for LL(*). Four things to check before you commit. Treat npm, not GitHub releases, as the version source, because the release list stops at 0.5.21 from 2016 while the documented install pins 13.2.0. Read the engines field of the published package rather than the compatibility section, which names no version itself and points at a manifest that is not the one in the root of this repository. Expect no root test command, since the root manifest carries a test framework and a coverage tool but delegates running them to each package. And if you need LL(*), budget for the third party plugin and its own maintenance, because the toolkit's built-in grammar class is the weaker one.

## FAQ

### What is Chevrotain used for?

It is a parser building toolkit for JavaScript with built-in support for LL(K) grammars, usable to build parsers, compilers and interpreters ranging from simple configuration files to full programming languages. Grammars are written as pure JavaScript sources with no code generation phase.

### How do I install Chevrotain?

From npm with npm install chevrotain, or as a browser ESM bundle from UNPKG, either the latest lib/chevrotain.mjs or an explicit version such as chevrotain@13.2.0, in minified and unminified forms.

### Which Node versions and browsers does Chevrotain support?

The README names none itself. It says modern runtimes only, defined as the Node versions in the published package's package.json engines field plus current evergreen browsers, warns that modern standard library APIs may be relied on, and says legacy runtimes are unsupported and may need transpilation and polyfills.

### Does Chevrotain support LL(*) grammars?

Not in the library itself. Built-in support is for LL(K), and LL(*) comes from a third party plugin linked from the introduction, with a Langium write-up on ALL(*) lookahead among the listed resources.

### What projects use Chevrotain?

The README lists five: the HyperFormula spreadsheet calculation engine, Langium, Prettier-Java, the JHipster Domain Language parser, and Argdown. Four of the five link to the parser source, the HyperFormula one pinned to a fixed commit.

## Sources

- [Chevrotain/chevrotain on GitHub](https://github.com/Chevrotain/chevrotain)
- [License: Apache-2.0](https://github.com/Chevrotain/chevrotain/blob/master/LICENSE)
- [Project website](https://chevrotain.io)
- [README](https://github.com/Chevrotain/chevrotain/blob/master/README.md)
- [Releases](https://github.com/Chevrotain/chevrotain/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chevrotain-chevrotain