# Ezno: a Rust TypeScript checker that refuses to guess

> Ezno is a TypeScript type checker and compiler written in Rust, built around an imperative type system that evaluates control flow and side effects with types instead of values. It is not yet ready to check existing projects, and the README says so plainly.

**kaleidawave/ezno** — A correct and efficient TypeScript type checker and compiler with additional experiments

- Repository: https://github.com/kaleidawave/ezno
- Website: https://kaleidawave.github.io/posts/introducing-ezno/
- Stars: 2,736 · Forks: 49
- Language: Rust
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/kaleidawave-ezno

## What Ezno is trying to fix about TypeScript checking

Most type checkers infer a type, compare it to an annotation, and move on. Ezno evaluates a program the way an interpreter would, except the values flowing through it are types. The README calls this an imperative type system: it tracks and evaluates the side effects of functions and control flow structures. The stated goal is a program with guaranteed type safety, meaning no runtime TypeError, qualified by the phrase "as long as definitions are sound". That caveat matters more than the headline. A checker can only promise absence of runtime type errors if the ambient definitions it trusts, such as library declarations, are themselves correct. Ezno is aimed at people who care about that distinction: language tooling authors, researchers working on type systems, and engineers who want to see what a soundness-oriented checker does differently. It is not aimed at teams who want a drop-in replacement for tsc today, and the project says as much in its own README.

## How the checker evaluates control flow instead of just annotating it

The workspace splits into two main crates. The parser crate holds AST definitions, the parsing logic, AST to string conversion and visiting. The checker crate holds the stores for types and contexts, the type checking logic, and optional synthesis over the parser AST. That division is the architecture in one sentence: parsing produces a tree, and checking walks it while maintaining type and context stores. Because the checker follows control flow, it can reason about a value after a branch has narrowed it, which is where the interpreter analogy comes from. The README is explicit that it does not run IO or side effects; it only simulates them at the type level. The checker is also described as doing optional synthesis over the AST, which is why the project calls itself a compiler rather than only a checker. It takes JavaScript, or a TypeScript or Ezno superset, runs compiler-like passes, and emits JavaScript. The README notes that a future version could emit a lower level format from its event representation, but that is stated as a possibility, not a feature.

## Building Ezno and running a first check

The repository is a Cargo workspace whose root package is named ezno, with a binary target also named ezno and a library target named ezno_lib. The README points readers to CONTRIBUTING.md for information about building and testing, and to the getting started guide under checker/documentation for experimenting with what the checker currently supports. The workspace members listed in Cargo.toml include parser, parser/visitable-derive, parser/generator, checker and checker/binary-serialize-derive, with the lsp/server member commented out. The root package sets default-run to ezno, and the crate-type entry lists cdylib and rlib. The README does not give a copy-paste build command, so the concrete entry point it names is CONTRIBUTING.md rather than a command line. The CLI dependency list includes multiline-term-input, described in Cargo.toml as being for CLI input across multiple lines, and notify with notify-debouncer-full for watching files. So the interactive path is to enter a program across several lines and have it checked, and there is a file-watching mode for iterating on a file. The README does not spell out the flag names for either mode, so check the getting started guide before assuming a syntax. The dependency list also includes release-downloader with the self-update feature, which suggests the binary can update itself, though the README does not document that command either. For a library consumer, the checker dependency is exposed as the ezno-checker package with the ezno-parser and serde-serialize features enabled in the root manifest.

## The blocking issue label is the real feature list

The most important line in the README is the warning at the top: Ezno is in active development and does not currently support enough features to check existing projects, with a link to issues labelled blocking. That label is the honest scope boundary. If you point Ezno at a real codebase today, the failure will not be a wrong type; it will be a construct the checker has no rule for. The README also states that Ezno should work in existing projects using tsc, but that sentence sits next to a comparison page of emitted errors and warnings against TSC, and the project explicitly says it is not on parity with TSC and has different behaviors. Read those two statements together and the practical meaning is that the output is not interchangeable. A second limitation is structural: the LSP is described as being in the works and is tracked in an issue, and the lsp/server workspace member is commented out in Cargo.toml. So editor integration is not part of what you get. A third is the soundness caveat itself. Guaranteed absence of runtime TypeErrors depends on sound definitions, and the checker cannot verify the declarations you feed it.

## Ezno compared with tsc, and what the comparison actually shows

The obvious alternative is the TypeScript compiler, and the difference is not just speed or error wording. TSC is a mature checker designed to accept the JavaScript and TypeScript that people already write, including dynamic patterns that are hard to prove sound. Ezno inverts that priority: its types are aimed at soundness and tracing, and the README says it is not smarter as a means to allow more dynamic patterns, with the advice to keep things simple instead. That is a real philosophical split. TSC optimises for accepting existing code; Ezno optimises for proving things about code it can model. The project publishes a comparison page of emitted errors and warnings against TSC, which is the right place to look before drawing conclusions about behavior differences. There is also a test262 directory at the repository root, which indicates conformance testing against the ECMAScript test suite, though the README does not describe how to run it. If your goal is checking a large existing codebase today, tsc remains the tool that does that. Ezno is the tool you read to understand a different design.

## Maintenance, releases and the MIT licence

The last push to the default branch was on 2026-06-16, so the repository is not archived and is not dormant. The most recent tagged release is Ezno 0.0.23 from 2024-11-13, preceded by 0.0.22 in August 2024 and 0.0.21 in May 2024. That gap between the latest tag and the latest commit is worth noting: work continues on main, but the versioned artifacts lag behind it. The root package version is also 0.0.23, and the checker dependency in that manifest is pinned at version 0.0.18, so the CLI package and the checker crate do not share a version number. If you depend on ezno-checker directly, pin the version you actually build against rather than assuming it tracks the CLI release. The project is MIT licensed, which permits commercial and closed-source use and requires preserving the copyright notice and licence text; the repository spells the file as LICENCE rather than LICENSE. That is a summary of the licence terms, not legal advice. The upgrade cost is mostly the cost of tracking a pre-1.0 project: minor version bumps can change behavior, and the README's own warning about feature coverage means a version bump may widen what the checker accepts rather than fix a bug you filed.

## Conclusion

Adopt Ezno if you want to experiment with a soundness-first type system, read the checker specification, and file feedback on the blocking issues; the getting started guide is the entry point. Do not adopt it as a replacement for tsc in a production repository, because the README states it does not currently support enough features to check existing projects. Before anything else, verify which features your own code uses against checker/specification/specification.md and the blocking issue label, and check whether the checker crate version you depend on matches the 0.0.23 workspace version.

## FAQ

### How do I use Ezno on an existing TypeScript project?

You cannot yet. The README states that Ezno does not currently support enough features to check existing projects and links to issues labelled blocking. For experimenting with what it does support, the README points to the getting started guide under checker/documentation.

### What is Ezno's type checking technique and how does it work?

Ezno uses an imperative type system that tracks and evaluates the side effects of functions and control flow structures, similar to an interpreter but operating on types instead of values and without running IO. The checker crate stores types and contexts and can also perform optional synthesis over the parser AST.

### Is Ezno a replacement for tsc?

No. The README says Ezno is not on parity with TSC and has some different behaviors, though it should work in existing projects using tsc. The project publishes a comparison of emitted errors and warnings against TSC.

### What language and licence is Ezno written in?

Ezno is written in Rust and is MIT licensed, with the licence file named LICENCE at the repository root. The workspace contains a parser crate and a checker crate, with the checker exposed as the ezno-checker package.

## Sources

- [kaleidawave/ezno on GitHub](https://github.com/kaleidawave/ezno)
- [License: MIT](https://github.com/kaleidawave/ezno/blob/main/LICENSE)
- [Project website](https://kaleidawave.github.io/posts/introducing-ezno/)
- [README](https://github.com/kaleidawave/ezno/blob/main/README.md)
- [Releases](https://github.com/kaleidawave/ezno/releases)

---

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