WikiParser-Node is an offline Wikitext parser developed by Bhsd for the Node.js environment. It can parse almost all wiki syntax and generate an Abstract Syntax Tree (AST) (Try it online). It also allows for easy querying and modification of the AST, and returns the modified Wikitext.
Although WikiParser-Node is not primarily designed to convert Wikitext to HTML, it provides pragmatic HTML rendering for many situations. Here is a list of example HTML pages from MediaWiki.org rendered using this package.
WikiParser-Node has been extensively tested against the official MediaWiki PHP parser tests with ~3,000 test cases, covering various edge cases and peculiarities of Wikitext. These tests are available here.
- Round-trip editing for bots and automation: parse Wikitext into an AST, query and modify nodes, then write back valid Wikitext.
- LSP and linting ready for Node.js tooling: powers WikiLint and Wikitext LSP.
- Browser/editor integration: works with CodeMirror, Monaco, and MediaWiki's official CodeMirror extension.
- Large-scale usage evidence: full-dump parsing and linting on English Wikipedia scale is practical on consumer hardware.
- Transparent quality signals: CI, CodeQL, public parser-test results, and coverage are all visible in this repository.
This version provides a CLI, but only retains the parsing and linting functionality. At the cost of losing AST modification and HTML rendering capabilities, it executes 2.4x faster. Projects can use WikiLint in their CI pipelines to automatically lint wiki content (e.g., qBittorrent).
It powers the Wikitext LSP, which provides multiple language services for editors such as VS Code, Sublime Text, and Helix.
A list of available linting rules can be found here.
Note: The major version number of WikiLint is always higher than that of WikiParser-Node by 1.
A lightweight version that only supports parsing and manipulation of templates. This version is designed for use cases where only template processing is needed, such as certain types of bots or web tools (e.g., GANReviewTool) that focus on template manipulation.
A browser-compatible version, which can be used for code highlighting or as a LSP plugin in conjunction with editors such as CodeMirror and Monaco (Usage example). It has been integrated into the MediaWiki official CodeMirror extension since MediaWiki Release 1.45.
To ensure maximum responsiveness within browser environments, the parser is optimized for speed and memory usage while AST manipulation and HTML rendering are intentionally excluded to prevent main-thread blocking.
Please install the corresponding version as needed (WikiParser-Node or
WikiLint), for example:
npm i wikiparser-nodeor
npm i wikilintYou can install any of the following optional packages to enable advanced features:
| Package | Purpose |
|---|---|
mathoid-texvcjs |
Diagnostics and HTML conversion support for <math> and <chem> extension tags |
stylelint-config-recommended |
Diagnostics for style attributes |
vscode-css-languageservice |
CSS language support for style attributes |
vscode-html-languageservice |
Language support for HTML tags |
vscode-json-languageservice |
JSON language support for <templatedata>, <mapframe> and <maplink> tags |
ajv + ajv-errors |
HTML conversion support for <templatedata> extension tags |
katex |
HTML conversion support for <math> and <chem> extension tags |
prismjs + prism-wiki |
Syntax highlighting of <syntaxhighlight> extension tags |
# Full LanguageService features for `Parser.createLanguageService()`
npm i mathoid-texvcjs stylelint-config-recommended vscode-css-languageservice vscode-html-languageservice vscode-json-languageservice
# Full HTML conversion support for `Parser.toHtml()`
npm i ajv ajv-errors katex mathoid-texvcjs prismjs prism-wikiYou can download the code via CDN, for example:
<script src="//cdn.jsdelivr.net/npm/wikiparser-node"></script>or
<script src="//unpkg.com/wikiparser-node/bundle/bundle-lsp.min.js"></script>For more browser extensions, please refer to the corresponding documentation.
For MediaWiki sites with the CodeMirror extension installed, such as different language editions of Wikipedia and other Wikimedia Foundation-hosted sites, you can use the following command to obtain the parser configuration:
npx getParserConfig <site> <script path> [user] [force]
# For example:
npx getParserConfig frwiki https://fr.wikipedia.org/w user@example.netThe generated configuration file will be saved in the config directory.
You can then use the site name for Parser.config.
// For example:
Parser.config = "frwiki";Please refer to the Wiki. In particular, there are some usage examples that demonstrate how to use this package to complete various tasks.
import Parser from "wikiparser-node";
import type {TranscludeToken} from "wikiparser-node";
Parser.config = "enwiki";
const root = Parser.parse("{{Infobox|name=Old}}\nText"),
template = root.querySelector<TranscludeToken>("template#Template:Infobox");
template?.setValue("name", "New");
const wikitext = String(root);
assert.strictEqual(wikitext, "{{Infobox|name=New}}\nText");WikiParser-Node prioritizes syntax accuracy and compliance over synthetic benchmarks. It does not chase higher speed by cutting corners on complex edge cases, but its real-world performance remains reliable for production use.
A full scan (parsing and
linting) of an English Wikipedia database dump (*.xml.bz2) with ~19 million
articles—from short stubs to massive, template-heavy pages—takes about 5 hours
(wall-clock) on a personal MacBook Air.
Performance comparison between WikiParser-Node and WikiLint
| Version | Average time per article | Max time per article |
|---|---|---|
| WikiParser-Node | 3.6ms | 2.8s |
| WikiLint | 1.5ms | 0.75s |
- MediaWiki bot workflows that require robust AST manipulation and round-trip-safe edits.
- Node.js pipelines for linting and refactoring Wikitext.
- LSP-based language tooling.
- Browser-side editing helpers, and gadgets/user scripts that require Wikitext parsing.
WikiParser-Node has been extensively validated against the official MediaWiki PHP parser tests (~3,000 integration test cases), ensuring robust compliance with the Wikitext quirks and edge cases. However, for complete transparency, the following limitations are documented.
- Memory leaks may occur in rare cases.
- Invalid page names with unicode characters are treated like valid ones (Example).
- Preformatted text with a leading space is only processed by
Token#toHtml. - Link text containing
!!in a table header (Example). - Seemingly broken file link syntax in a table (Example).
- HTML tag pairs may not match when nested inside a list item (Example), but the linter will not report it.
Expand
- Many extensions are not supported.
- Sub-referencing is not supported.
- Special cases involving templates inside the
linkparameter of a gallery image (Example).
- Some parser functions are not supported, notably
#formatdate,#timeand#invoke. - New lines in
{{localurl:}}are not handled correctly (Example).
- RTL support in the table of contents (TOC) (Example).
- Style sanitization is sometimes different (Example).
<caption>elements are wrapped in<tbody>elements (Example).- Unclosed HTML tags in the table fostered content (Example).
<tr>elements should not be fostered (Example).
- Link trail is not supported (Example).
- Block elements inside a link should break it into multiple links (Example).
- Invalid or missing images (Examples 1, 2).
- Link starting with
../on a subpage (Example). - Duplicate file namespace prefixes should be invalid (Example).
- File redirects (Example).
- Figure caption should not be nested inside inline elements (Example).
- No percent-encoding in displayed free external links (Example).
- Incomplete
<p>wrapping when there are block elements (e.g.,<pre>,<div>or even closing tags). - Mixed lists (Example).
<p>wrapping and preformatted text are not supported inside<indicator>.
- Automatic language conversion is not supported.
- Support for manual language conversion is minimal (Example).
- Language conversion should prevent
<p>wrapping (Examples 1, 2).
- Illegal HTML entities (Example).