Yuku is a JavaScript toolchain written in Zig

Why a toolchain in Zig

The project describes itself in one line, a JavaScript and TypeScript compiler toolchain written in Zig, and the site is at yuku.fyi with a playground at playground.yuku.fyi for trying it without installing anything. The choice of implementation language is the first thing to notice, because a JavaScript toolchain written in JavaScript inherits the performance characteristics of the host, and the whole point of a parser is to be called on every file of a large project. Writing it in Zig gives a compiled binary with predictable startup cost, and the repository layout backs that up, with a build.zig and a build.zig.zon for the Zig side, a bun.lock for the JavaScript tooling, and a packages/ directory holding the published artefacts. The package is on npm under the name yuku, and the repository also documents how to install for Zig users through a separate page on the documentation site.

Five imports, five jobs

The install table is the API map, and each import does one thing. The yuku import parses source into an ESTree or TypeScript-ESTree AST, which is the detail that matters most for adoption, because an ESTree shaped tree is what the rest of the JavaScript tooling already consumes. The yuku/analyzer import resolves scopes, bindings, references and imports, which is the semantic layer that turns a tree into something you can query. The yuku/ast import walks, builds and checks an AST. The yuku/codegen import prints an AST back to source, with source maps, which makes it possible to round-trip a file and to rewrite code with a usable mapping. And the yuku/types import provides the TypeScript types for the AST. The separation matters because it lets a consumer take only what it needs, since a formatter that just prints does not have to pay for the analyzer.

Installing and trying it

Installation from npm is a single command, and the project points at the documentation site for the details of the Zig install path as well:

npm install yuku

The playground is the part worth using first, because a parser is exactly the kind of component where behaviour is easier to judge by looking at a tree than by reading a specification. The README is otherwise brief, which is a deliberate division of labour rather than an omission, since the documentation site carries the material and the repository carries the code. There is also a documentation generator script in the package scripts, which produces a machine readable documentation file for the site, and that is a hint about how the project expects both humans and tools to consume its documentation.

The test script is the interesting file

The root package script for tests is a single long line that tells you the whole shape of the project. It fetches the fixtures, builds, type checks, and then runs the parser, codegen, AST, analyzer, dialect, sourcemap and runtime suites in sequence, and each of those has its own script. The parser suite loads a fixture set and runs it:

bun test/parser/run.ts && bun test test/parser

The code generator suite is the interesting one, because it builds the Zig reference implementation and compares it against the JavaScript output:

bun run --cwd packages/yuku build && zig build codegen-reference && bun test test/codegen

The dialect suite compiles the parser to WebAssembly with a dialect file chosen at build time, which is how a project checks that a language variant parses the same way through two very different execution paths. The runtime suite builds a smoke test with Bun targeting Node, so the same code is exercised in a different JavaScript runtime. There are also tool tests and a fuzz target, each of which is a Zig build invocation:

zig build test-tools

zig build fuzz

A fuzz target in a parser is the difference between a parser that handles the valid programs and one that handles the invalid ones without crashing.

Zig and Bun in the same repository

The build is a deliberate mix of two toolchains, and the scripts show which is used where. The Zig side builds the package and the reference binaries, with a format script that runs zig fmt over the Zig sources, and the JavaScript side uses Bun for the tests, the type check and the playground server, with the type check running tsc twice, once for the root and once for the packages/yuku project. The build script for the published package is itself a composition, building the Zig package and then building the JavaScript package. The tests are run with Bun rather than Node, which is faster and is why the runtime smoke test explicitly targets Node with Bun's build, so that the artefact is still verified in the runtime users actually have. The repository also has a profile/ directory, which in a Zig project is where the allocation and performance profiles live, and a tools/ directory for the helper binaries the build produces.

How the npm packages are assembled

The root package is a private workspace root rather than a published package, with the version left empty and the workspaces set to packages/*. The published packages are therefore assembled by the build rather than published from the root, and the release script is a small TypeScript file in the GitHub scripts directory that runs under Bun. The engines field asks for Node 16.4.0 or newer, which is a deliberately low floor, since the compiled artefacts are what the consumers install and the Node version only matters for the parts that still run as JavaScript. The build output is produced by zig build package, and the JavaScript package is built separately in packages/yuku, so the distribution is a compiled binary plus a thin JavaScript wrapper.

Licence, releases and the current state

Yuku is licensed under the MIT licence, and the repository has the full set of community files, with a CHANGELOG.md, a code of conduct, a CONTRIBUTING.md, a SECURITY.md for reporting vulnerabilities privately, and an AGENTS.md for coding agents. The author is credited as Arshad Yaseen, and the project is funded through GitHub sponsors. The release history shows a project moving quickly, with v0.21.0 published on 2026-10-19, v0.20.1 on 2026-10-16 and v0.20.0 on 2026-10-15, and the last push to the repository on 2026-10-19. A 0.x version with releases days apart tells you the API is still moving, so the practical advice for an adopter is to pin an exact version and to run the parser fixtures against your own corpus before you rely on it.

Editorial conclusion

Yuku fits a developer who wants a fast JavaScript and TypeScript parser they can embed, or who wants to read how a modern compiler toolchain is put together in a language that is not JavaScript, since the Zig source is compact and the documentation site covers the semantics. It does not fit a team that needs a drop-in replacement for an existing bundler plugin today, since the package is a young 0.x release with a fast moving release history. It does not fit someone who needs a type checker, because the analyzer resolves scopes, bindings, references and imports rather than performing type checking. Before you depend on it, try the playground and run the parser fixtures yourself, and note the release state, where v0.21.0 was published on 2026-10-19 and the last push was the same day.

Frequently asked questions

Official sources

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