Crates

API documentation lives on docs.rs and is not duplicated here. This page is the map: what each crate is for, and which one to read.

Crate	crates.io	docs.rs	Role
ezu	crates.io	docs.rs	Umbrella crate: re-exports plus feature flags. Start here.
ezu-core	crates.io	docs.rs	Tile and world coordinates, deterministic seeding.
ezu-features	crates.io	docs.rs	GIS feature parsing — MVT via geozero, GeoJSON. No remote fetch.
ezu-style	crates.io	docs.rs	Style spec parser (serde). Pure data, no rendering.
ezu-graph	crates.io	docs.rs	Typed node-DAG evaluator: cache, pad propagation, Rayon parallelism. No rendering deps.
ezu-paint	crates.io	docs.rs	Painting primitives, the built-in ops, host glue (PNG/WebP, asset banks, fonts).
ezu-translate	crates.io	docs.rs	Lower other engines’ styles into ezu recipes. MapLibre GL is the first frontend.
ezu-cli	crates.io	docs.rs	The ezu binary: rendering, translate, check, graph, schema, serve.
ezu-renderer	—	—	The embedding renderer, host-neutral: bind a tile’s bytes per source, render one tile. Everything the embedding shells share. Not published to crates.io.
ezu-wasm	—	—	WebAssembly bindings over ezu-renderer, published to npm as @reearth/ezu. Not published to crates.io.
ezu-cabi	—	—	A flat C ABI over ezu-renderer, built to wasm and embedded in the Go module. Not published to crates.io.
ezu-compare	—	—	Internal benchmark: convert a MapLibre style, render it, pixel-compare against maplibre-gl-js. Not published.

Sister repositories

Project	What it is
maplibre-expr	Pure-Rust MapLibre expression parser and evaluator, 100 % conformance against the official spec fixtures. Its own repository and crate.
hokusai	The brush engine behind fill-dabs, line, and friends.

The dependency shape

ezu-style   (parse)  ──┐
                       ├──> ezu-graph (evaluate) ──> ezu-paint (the ops + host glue)
ezu-core    (coords) ──┘                                   │
ezu-features (MVT/GeoJSON) ────────────────────────────────┘

ezu-translate ──> emits ezu-style JSON
ezu-cli ──> native host
ezu-renderer (bind + render, host-neutral) ──┬──> ezu-wasm ──> JS host
                                             └──> ezu-cabi ──> Go host (wazero)

Three boundaries are worth knowing:

• ezu-graph has no rendering dependencies. tiny-skia, hokusai, and libblur all live in ezu-paint, which registers the concrete ops. That is why a custom op in your own crate is a first-class citizen — see custom ops.
• ezu-style does not evaluate anything. Parsing gives you a Document, which is data. build_graph turns it into something executable.
• An embedding shell holds no rendering logic. ezu-renderer owns the whole bind-then-render flow and names its failures; ezu-wasm reads JS option objects, builds JS results, and converts errors, and ezu-cabi does the same across a flat C ABI for the Go module. An embedding in another language is written against ezu-renderer the same way, so the shells cannot drift apart — which is why the same style renders to the same bytes in a browser and in a Go service, and why a failure carries the same name in both.

Feature flags

On the umbrella crate:

Feature	Effect
parallel	pulls in Rayon and enables Evaluator::render_parallel. Leave off for wasm.

ezu-cli additionally has heap-profile, which writes dhat-heap.json for allocation-site attribution.

Versioning

All published crates are versioned together with the workspace (currently 0.10.x) and released as a set, so ezu 0.10.0 expects ezu-graph 0.10.0. Pin the umbrella crate and let it pin the rest. maplibre-expr versions independently.