tree-sitter-wasms

tree-sitter-wasms aggregates dozens of individual tree-sitter-* grammar packages as devDependencies, compiles every one of them to a .wasm binary in a single automated GitHub Actions run (using emscripten via tree-sitter-cli’s build-wasm), and republishes the resulting files as static assets bundled directly with the npm package. Consumers import a specific grammar’s .wasm file straight from tree-sitter-wasms/out/ with no compiler, emscripten install, or native Node addon required.

This solves a real friction point for anyone building browser-based or WASM-sandboxed code tooling: compiling tree-sitter grammars yourself requires emscripten and a working native toolchain per language, which is slow and awkward to repeat across 40+ grammars. By centralizing the build and shipping pinned, prebuilt binaries, projects like in-browser code editors and AI coding assistants can pull in broad multi-language parsing support as a single ordinary npm dependency.

What You Get

• Prebuilt .wasm binaries for 40+ tree-sitter grammars (JavaScript, TypeScript, Python, Rust, Go, Java, C/C++, Ruby, PHP, Swift, Kotlin, Elixir, HTML, CSS, JSON, TOML, YAML, and more) in one package
• A GitHub Actions build pipeline (emsdk + tree-sitter-cli build-wasm) that recompiles every bundled grammar in a single automated workflow_dispatch run
• Directly importable .wasm assets under out/ (e.g. tree-sitter-wasms/out/tree-sitter-rust.wasm) with no native toolchain or emscripten install required at consumption time
• Pinned grammar versions declared as devDependencies, so each release captures a known-good snapshot of every parser it bundles

Common Use Cases

• Loading tree-sitter parsers in a browser-based code editor for syntax highlighting or code folding without shipping a native binary
• Powering AI coding assistants and IDE extensions that need language-aware parsing in a WASM/JS sandbox
• Static analysis or code-search tools running inside serverless/edge runtimes where native Node addons aren’t available
• Prototyping multi-language parsing support quickly without maintaining a per-grammar emscripten build pipeline

Under The Hood

Architecture The repo is a single-purpose build script rather than a runtime library: package.json lists roughly forty tree-sitter-* grammar packages as devDependencies alongside a handful of build-only tools (@supercharge/promise-pool, find-root, ts-node, typescript), and build.ts is the sole source file. It resolves each grammar’s installed package path via findRoot(require.resolve(name)) with a node_modules fallback, invokes tree-sitter-cli’s build-wasm command through child_process.exec inside a concurrency-limited PromisePool bounded by os.cpus().length, special-cases four grammars that need a subpath or an extra generate step, and finally moves the resulting *.wasm files into an out/ directory that is the only thing actually published (files: [“/out”]). There is no runtime module of its own — the entire architecture is a build-then-publish pipeline, and its one real abstraction (the per-grammar dispatch inside buildParserWASM) is an if/else chain rather than data-driven configuration, so adding a grammar with unusual layout requires editing that function directly.

Tech Stack TypeScript run via ts-node, targeting Node.js, with the real “payload” dependencies being the tree-sitter-* grammar packages themselves (some pulled straight from GitHub, including a fork for Dart and commit-pinned refs for Solidity and Vue). Compilation goes through tree-sitter-cli wrapping Emscripten, concurrency is handled by @supercharge/promise-pool, and pnpm is pinned as the package manager. Release automation lives in a GitHub Actions workflow that provisions emsdk 2.0.24 via the mymindstorm/setup-emsdk action, runs the build, and publishes to npm with JS-DevTools/npm-publish — there is no web framework, bundler, or test runner involved since this is purely a build/publish utility over existing grammars.

Code Quality There are no test files anywhere in the repository — no unit tests, no CI test step, nothing beyond “does the build succeed.” Error handling in build.ts wraps each grammar’s build in a try/catch that logs a failure and sets a shared hasErrors flag so one bad grammar doesn’t abort the whole parallel run, with the workflow only failing at the very end via process.exit(1) — a reasonable batch-job pattern, though errors are only logged via a broad catch, never typed or categorized. TypeScript typing is present but light: the build options object has two optional fields with no further modeling of the different per-grammar build recipes, which are instead just string comparisons on grammar name. There is no ESLint or Prettier configuration in the repo, and CI runs only the build-and-publish step with no lint or typecheck gate.

API Design Consumers never call an API surface at all — the package is used purely as a static asset import (import treeSitterRust from "tree-sitter-wasms/out/tree-sitter-rust.wasm"), which is close to zero-boilerplate: no initialization, configuration object, or wrapper function is required, just resolving a file path through whatever bundler or loader the consumer already uses. The tradeoff is discoverability: the README doesn’t enumerate which languages are actually bundled, instead pointing users to browse the published package’s file listing on unpkg to find out, and there’s no changelog or compatibility table showing which grammar version each release was built against.