Parser Generators for JavaScript and TypeScript
antlr4, jison, langium, nearley, and pegjs are tools that help developers build parsers for custom languages, configuration files, or data formats within the JavaScript ecosystem. They take a formal grammar definition and generate code that can read text input and turn it into a structured data tree (AST). antlr4 is a powerful, industry-standard generator supporting multiple languages, while jison is a classic LALR(1) generator for Node.js. langium is a modern framework focused on building language servers and VS Code extensions using TypeScript. nearley and pegjs use Parsing Expression Grammar (PEG) syntax, which is often more intuitive for recursive structures and avoids the ambiguity issues of traditional context-free grammars.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Parser Generators for JavaScript and TypeScript: A Deep Dive
Building custom languages, configuration parsers, or developer tools in JavaScript requires a solid parsing strategy. The packages antlr4, jison, langium, nearley, and pegjs all solve this problem, but they approach it from different angles. Some focus on raw parsing power, others on developer tooling, and some on grammar simplicity. Let's compare how they handle grammar definition, runtime behavior, and ecosystem fit.
📝 Grammar Definition: External Files vs Inline Code
How you write your grammar changes how you work. Some tools want separate files, while others let you write grammar inside JavaScript strings.
antlr4 requires external .g4 grammar files.
- You write the grammar in a specific syntax, then run a CLI tool to generate JavaScript code.
- This separates language design from implementation logic clearly.
// antlr4: calculator.g4
grammar Calculator;
add: INT '+' INT ;
INT: [0-9]+ ;
WS: [ \t\n]+ -> skip ;
jison uses JSON or Jison-specific grammar files.
- You define tokens and rules in a structure similar to Yacc.
- Often requires a build step to compile the grammar into a JS module.
// jison: grammar.jison
%{
/* code */
%}
%%
add: INT '+' INT { $$ = $1 + $3; }
;
langium uses a dedicated DSL (Domain Specific Language) in .langium files.
- The grammar defines both parsing rules and the shape of your AST types.
- It integrates tightly with TypeScript interfaces.
// langium: calculator.langium
grammar Calculator;
Add returns Expression:
left=INT '+' right=INT;
terminal INT returns number: /[0-9]+/;
nearley uses a concise, custom grammar syntax in .ne files.
- The syntax is very compact and readable, designed for humans.
- You compile it to a JavaScript module using the nearley compiler.
// nearley: grammar.ne
add -> int "+" int {% (d) => d[0] + d[2] %}
int -> /[0-9]+/ {% (d) => parseInt(d[0]) %}
pegjs allows inline grammar strings or external .pegjs files.
- You can pass the grammar as a string directly to the parser generator at runtime or build time.
- Very flexible for dynamic grammar generation.
// pegjs: inline grammar
const parser = peg.generate(`
add = left:integer "+" right:integer { return left + right; }
integer = digits:[0-9]+ { return parseInt(digits.join(""), 10); }
`);
⚙️ Parsing Strategy: LL(*) vs LALR(1) vs PEG
The underlying algorithm determines what kinds of languages you can parse and how errors are handled.
antlr4 uses LL(*) parsing.
- It can handle a wide range of context-free grammars.
- It requires you to resolve ambiguities explicitly if they arise.
// antlr4: Runtime usage
const chars = new antlr4.InputStream(input);
const lexer = new CalculatorLexer(chars);
const tokens = new antlr4.CommonTokenStream(lexer);
const parser = new CalculatorParser(tokens);
const tree = parser.add();
jison uses LALR(1) parsing.
- This is the same algorithm used by Yacc and Bison.
- It is fast but struggles with certain recursive patterns without refactoring.
// jison: Runtime usage
const parser = new Parser();
const result = parser.parse("1 + 2");
// Returns the value computed in the grammar actions
langium uses a PEG-based approach internally.
- It avoids the shift/reduce conflicts common in LALR parsers.
- It is designed to work seamlessly with language server features.
// langium: Service injection
const services = createCalculatorServices(NodeFileSystem);
const result = services.parser.LangiumParser.parse(input);
nearley uses a PEG-like algorithm with support for ambiguity.
- It can return multiple possible parse trees if the grammar is ambiguous.
- Great for natural language processing or loose syntax.
// nearley: Runtime usage
const grammar = nearley.Grammar.fromCompiled(require("./grammar"));
const parser = new nearley.Parser(grammar);
parser.feed("1 + 2");
console.log(parser.results);
pegjs uses Parsing Expression Grammar (PEG).
- PEG is ordered choice, meaning the first matching rule wins.
- This eliminates ambiguity but requires careful rule ordering.
// pegjs: Runtime usage
const result = parser.parse("1 + 2");
// Throws an exception if the input does not match the grammar
🛠️ Tooling and Language Server Support
If you are building an editor extension, parsing is only half the battle. You need validation, autocomplete, and hover tips.
antlr4 has limited LSP support.
- You mostly get the parser. Building a language server requires significant manual work.
- Best for runtime compilation or analysis tools.
// antlr4: Manual visitor pattern
class CalculatorVisitor extends CalculatorVisitor {
visitAdd(ctx) {
// Manually implement logic for each node type
}
}
jison has no built-in LSP support.
- It is purely a parser generator.
- You must build all editor integrations from scratch.
// jison: Pure parsing
// No built-in helpers for hover or autocomplete
const ast = parser.parse(code);
// Developer must traverse AST manually for tooling
langium is built for Language Servers.
- It automatically generates validation, hover, and definition providers.
- Ideal for VS Code extensions.
// langium: Validation provider
class CalculatorValidator implements ValidationResultProvider {
validate(node: Expression, accept: ValidationAcceptor): void {
// Built-in framework for reporting errors in the editor
}
}
nearley has no built-in LSP support.
- Focuses on parsing efficiency and grammar simplicity.
- Community plugins exist but are not official.
// nearley: Post-processing
// Developer must write custom logic to map parse results to editor features
const results = parser.results;
pegjs has no built-in LSP support.
- Like nearley, it focuses on generating the parser itself.
- Good for custom config files where full IDE support isn't needed.
// pegjs: Error locations
try {
parser.parse(input);
} catch (e) {
// e.location contains line and column for error reporting
}
⚠️ Maintenance and Future Proofing
Choosing a library means trusting its maintainers. Some of these tools are legacy, while others are actively evolving.
antlr4 is actively maintained.
- It is a standard in the industry with a large user base.
- Safe for long-term enterprise projects.
// antlr4: Stable API
// API has remained consistent across minor versions
jison is largely inactive.
- Warning: Do not use for new projects. It has not seen significant updates in years.
- Consider
nearleyorpeggy(the fork ofpegjs) instead.
// jison: Legacy status
// No recent feature additions or security patches
langium is actively maintained.
- Backed by TypeFox and the Eclipse Foundation.
- Regularly updated to support new VS Code API features.
// langium: Modern TypeScript
// Fully typed APIs leveraging modern TS features
nearley is in maintenance mode.
- It is stable but sees fewer feature updates.
- Still a solid choice for stable DSLs.
// nearley: Stable compiler
// Grammar compiler output is consistent
pegjs is archived in favor of peggy.
- Warning:
pegjsis no longer the primary recommendation. - Use
peggyfor active support, thoughpegjsstill works.
// pegjs: Fork notice
// Developers are encouraged to migrate to peggy
🤝 Similarities: Shared Ground Between These Libraries
Despite their differences, all these tools share a common goal and some overlapping capabilities.
1. 🌲 AST Generation
- All produce a tree structure representing the input.
- You can traverse this tree to interpret or compile the code.
// Common pattern across all
function traverse(node) {
if (node.type === 'Add') {
return traverse(node.left) + traverse(node.right);
}
}
2. 📍 Error Reporting
- All provide line and column numbers when parsing fails.
- Essential for giving useful feedback to users.
// Common error handling
try {
parser.parse(badInput);
} catch (e) {
console.error(`Error at line ${e.line}, column ${e.column}`);
}
3. 🔌 Extensibility
- You can embed custom JavaScript code within grammar rules.
- Allows for semantic actions during parsing.
// Embedding logic
// ANTLR, Nearley, PEGjs all support action blocks
rule = subrule { /* JS code here */ }
4. 📦 Node.js Compatibility
- All run on Node.js and can be bundled for the browser.
- Suitable for both server-side and client-side parsing.
// Universal usage
import parser from './parser';
// Works in Webpack, Vite, or Node runtime
5. 🧪 Testing Support
- All can be tested using standard unit testing frameworks.
- Grammar logic is just code that can be asserted.
// Jest example
test('parses addition', () => {
expect(parser.parse('1 + 1')).toBe(2);
});
📊 Summary: Key Differences
| Feature | antlr4 | jison | langium | nearley | pegjs |
|---|---|---|---|---|---|
| Algorithm | LL(*) | LALR(1) | PEG-based | PEG-like | PEG |
| Grammar File | .g4 | .jison / JSON | .langium | .ne | .pegjs / String |
| LSP Ready | ❌ Manual | ❌ No | ✅ Yes | ❌ No | ❌ No |
| Status | ✅ Active | ⚠️ Legacy | ✅ Active | ⚠️ Stable | ⚠️ Archived |
| Best For | Complex Languages | Legacy Yacc | VS Code Extensions | Concise DSLs | Quick Prototypes |
💡 The Big Picture
antlr4 is the heavy-duty choice 🏗️. Use it when you need a parser that matches the rigor of a compiler for a major programming language.
langium is the tooling choice 🛠️. If you want to ship a VS Code extension with autocomplete and validation, start here.
nearley and pegjs are the agile choices 🏃. They are perfect for configuration files, query languages, or small DSLs where developer speed matters more than formal grammar constraints. Note that for pegjs, you should look at its fork peggy for new work.
jison is the legacy choice 🕰️. Avoid it for new projects unless you are porting an existing Yacc grammar.
Final Thought: Parsing is hard. Choose the tool that matches your end goal — whether that is a full IDE experience (langium), a cross-platform compiler (antlr4), or a simple config reader (nearley/pegjs).
How to Choose: antlr4 vs jison vs langium vs nearley vs pegjs
- antlr4:
Choose
antlr4if you need a robust, battle-tested parser for a complex language that might also need implementations in other languages like Java or Python. It is ideal for enterprise-grade tooling where performance and strict grammar validation are critical. Be aware that it requires a separate build step to generate parser code from.g4files. - jison:
Choose
jisononly for maintaining legacy projects, as it is largely considered inactive compared to modern alternatives. It mimics the classic Yacc/Bison style and is suitable if you already have LALR(1) grammars from a C/C++ background. For new projects, prefernearleyorpegjsfor better JavaScript integration. - langium:
Choose
langiumif your goal is to build a Language Server Protocol (LSP) implementation or a VS Code extension for a custom language. It provides scaffolding for validation, hover info, and autocomplete out of the box. It is the best fit for developer tooling rather than just runtime parsing. - nearley:
Choose
nearleyif you want a lightweight, expressive grammar syntax that handles ambiguity well without complex conflict resolution. It is excellent for parsing domain-specific languages (DSLs) or configuration formats where readability of the grammar file is a priority. It compiles grammars to JavaScript modules easily. - pegjs:
Choose
pegjsif you need a simple PEG parser that can be defined inline within your JavaScript code. Note thatpeggyis the actively maintained fork ofpegjs, so evaluatepeggyfor new work.pegjsis suitable for quick prototypes or small parsers where external grammar files feel like overkill.
Popular Comparisons
README for antlr4
JavaScript target for ANTLR 4
JavaScript runtime libraries for ANTLR 4
This runtime is available through npm. The package name is 'antlr4'.
This runtime has been tested in Node.js, Safari, Firefox, Chrome and IE.
See www.antlr.org for more information on ANTLR
See Javascript Target for more information on using ANTLR in JavaScript
This runtime requires node version >= 16.
ANTLR 4 runtime is available in 10 target languages, and favors consistency of versioning across targets. As such it cannot follow recommended NPM semantic versioning. If you install a specific version of antlr4, we strongly recommend you remove the corresponding ^ in your package.json.