Dependency surface

What Cruft owns and what it does not: the roughly 70 in-tree crates that replace crates.io libraries (the parser, TLS, crypto, the SQLite and Postgres engines, HTTP, compression, Unicode, the package manager, and more), the two outside dependencies it keeps (Cranelift and libc), and why the line falls there.

Most runtimes are thin: a large fraction of what they do is delegated to third-party libraries pulled from a package registry. Cruft is the opposite. It owns almost its entire dependency surface: the parser, the bytecode compiler, Exegesis, the garbage collector, the hidden-class system, the package manager, TLS, the crypto primitives, the HTTP and HTTP/2 codecs, the SQLite and Postgres engines, the compression codecs, the Unicode tables, and even the small utility data structures most Rust projects vendor without a second thought, are all crates inside this repository, not dependencies from crates.io.

This page states what Cruft owns, what it does not, and why the line falls where it does. For the reasoning behind the approach, see Owning the stack.

Why own the surface

Two reasons, one about trust and one about correctness.

Supply chain. Every third-party crate is ambient authority at build time and a trust assumption at run time. A runtime whose job is to contain untrusted code cannot credibly rest on a deep tree of unaudited transitive dependencies. Owning the surface means the code that runs your code is code this project maintains and can account for, line by line.

Correctness ownership. Each owned crate implements the specification (ECMA-262, WHATWG, the relevant RFCs) directly. When a bug surfaces, the fix is in this tree, on this project's schedule, against a spec this project reads directly, not filed upstream and waited on.

The bar runs the opposite way most developers assume: owning a crate is the default, not the exception. Cruft reimplements what almost no one reimplements — crypto, TLS, the SQLite and Postgres engines — because the code that runs untrusted code has to be code this project can account for. A crate is left un-owned only in the rare case where rolling our own would cost more than the correctness or soundness that ownership would buy (see What Cruft does not own).

What Cruft owns

Sixty-five owned crates, all path-local, every one of them listed below. They fall into the families that follow; the third column names the crates.io library each owned crate stands in for, the dependency Cruft would otherwise have. (The workspace holds seventy path-local crates in all — the remaining five are the cruft binary itself and four build- and test-harness tools, which stand in for nothing.)

Engine

The JavaScript engine.

Standard-library data structures

The small crates most Rust projects vendor by reflex, implemented in-tree so even the utility layer carries no external trust.

Unicode and text

Compression

TLS, crypto, and security

Networking and HTTP

Data and database

CruftScript

Package manager and manifests

Node and web platform

The Node-compatibility and web-global surfaces, the Temporal implementation, the TypeScript resolver, and the Bun- and Deno-compatible shims, each implemented in-tree rather than depended on:

The Deno-compatibility surface (the Deno.* global) has no crate of its own: it is a host-level prelude that reshapes the node:* modules above into the Deno API, so it rides on the crates already listed rather than adding new ones.

What Cruft does not own

The shipped cruft binary takes exactly two direct third-party dependencies, Cranelift and libc. The count of crates that actually link in is larger, because Cranelift is not a single crate: it pulls a transitive subtree of roughly thirty third-party crates from crates.io (smallvec, indexmap, anyhow, regalloc2, gimli, hashbrown, bumpalo, target-lexicon, and more, including the very smallvec and indexmap the ownership table above replaces in-tree for Cruft's own code). So the ownership line is drawn at Cruft's direct dependencies: two edges the project chose deliberately, one of which (Cranelift) brings its own supply chain along with it.

Cranelift, the JIT backend

cranelift-codegen, cranelift-frontend, cranelift-jit, cranelift-module, and cranelift-native (currently 0.118) are the machine-code backend for LeJIT, Cruft's baseline JIT. Cruft owns the entire path down to the backend, which functions are admitted, what each specialization may assume, hidden-class shapes, OSR, and deoptimization all live in rusty-js-jit, and hands Cranelift a low-level IR to turn into native code for the host architecture.

This is the one place the ownership bar is deliberately not met: an optimizing code generator with correct register allocation and multi-architecture support is a multi-year project whose correctness benefit for Cruft's concerns (soundness, isolation, spec conformance) is essentially nil, Exegesis is already the semantic source of truth, and the JIT must merely match it. Cranelift is a focused, well-scoped backend that does exactly that job. See LeJIT for how the two fit together.

libc, the operating-system ABI

libc (0.2) is the binding to the platform's C ABI, the syscall surface every native program ultimately calls. It is essentially the name of the operating system's own interface; there is nothing to own here.