alef

What Alef generates

Alef is the polyglot binding generator behind the xberg.io ecosystem. The README describes it as extracting a Rust API surface and emitting language native bindings, package scaffolding, type stubs, README files, API docs, end to end tests, and release metadata from a single alef.toml file. The tagline on the page is Rust in, native bindings out, which captures the one way flow from a Rust crate to many language targets.

The key features list spells out what that means in practice. Alef treats one configuration as the source of truth, so a Rust workspace is configured once and every enabled language target is generated from it. It emits host language types, docs, errors, async wrappers, callbacks, and package files. It handles multi crate workspaces, so several independently published binding packages can be driven from a shared workspace config. It generates cross language test suites and registry mode test apps from shared JSON fixtures. It is release aware, syncing versions, generating registry metadata, building artifacts, and validating publication state. Pipelines are configurable, with setup, update, format, lint, test, clean, build, and publish commands per language. A staleness check caches inputs, embeds generation hashes, and verifies whether generated files are current. Together these capabilities aim to remove the repetitive hand written glue that multilingual publishing normally requires.

Targets and configuration

The README lists eighteen supported targets. Python uses PyO3 bindings with type stubs. TypeScript and Node.js use a NAPI-RS native addon with d.ts output. WebAssembly uses a wasm-bindgen package. Ruby uses a Magnus native extension. PHP uses a native PHP extension. Elixir uses a Rustler NIF package. R uses an extendr package. Go uses a cgo package over the generated C FFI layer. Java and Kotlin use JVM packages over the generated native library. Kotlin Android uses an Android package with generated JNI shims. C# uses a .NET package with P/Invoke. Dart and Flutter use a flutter_rust_bridge package. Swift uses a Swift package with Rust bridge support. Zig uses a Zig package over the generated C ABI. Gleam uses a Gleam package backed by Rustler. C FFI emits a C ABI, header, and shared library glue. JNI emits a Rust JNI shim crate used by both kotlin_android and host JVM tests.

The canonical language slugs are python, node, wasm, ruby, php, elixir, r, go, java, csharp, kotlin, kotlin_android, swift, dart, gleam, zig, ffi, and jni. The configuration model stores shared target languages, tool preferences, and pipeline defaults under a workspace table. Each Rust API surface is described by a crates entry, and per language sub tables customize module names, package names, feature flags, output paths, field naming, dependency extras, and language specific generation behavior. Generated binding files carry Alef hashes and are overwritten by generation commands, while scaffolded package files are written once unless the command opts into overwrite.

Commands and extending

Alef ships a long CLI. alef init creates alef.toml and the first generated files. alef extract pulls Rust source into an intermediate representation JSON. alef generate writes bindings, service API wrappers, public API wrappers, and type stubs. alef stubs emits type stubs only. alef scaffold writes package manifests, native build files, and package scaffolding. alef readme and alef docs generate per language README and Markdown API reference pages. alef setup installs per language development dependencies. alef fmt and alef lint run configured formatters, linters, and type checks. alef test runs unit, integration, end to end, or coverage commands. alef build compiles bindings with native tools. alef verify checks generated files and optional compile or lint state for CI. alef diff shows what generation would change without writing. alef e2e and alef test-apps manage local suites and registry mode test apps. alef publish prepares, builds, packages, and validates release artifacts. alef all runs the full workflow in one command.

Beyond the built in behavior, Alef is extensible through an Extension trait. A linked extension implements alef::Extension and ships a thin CLI binary for full type safety, which the README recommends for frameworks that generate an HTTP service API. A dynamic extension loads a compiled shared library declaring a C ABI factory function, useful when shipping a Rust binary is not possible. A template only extension declares blocks in alef.toml pointing at Jinja templates, and Alef's built in TemplateExtension emits them with no Rust required.

Installation and project context

Alef requires Rust 1.88 or newer. The README shows installing it with cargo install alef --locked. People who use cargo binstall can install a prebuilt binary through Alef's published binary install metadata with cargo binstall alef. The quick start shows writing an alef.toml that lists languages such as python, node, ffi, and go, sets an alef_version, and declares a crate with its source files and version source. Running alef generate --format, alef scaffold, alef readme, alef docs, and alef verify then produces the packages. alef init can create the initial config for a new project, and alef all runs the full local generation pass. The --lang and --crate flags restrict commands to selected targets or crates.

The project is part of the Xberg.io ecosystem, and the README links related repos such as Xberg, the content intelligence engine; crawlberg, for web crawling; html-to-markdown; liter-llm; and tree-sitter-language-pack. Alef itself is described as the generator that produces every per language binding across the polyglot repos. The license is MIT, with a link to the LICENSE file in the repository. Development uses the task runner for setup, build, test, and lint, and the targeted commands include cargo test, cargo insta review, and prek run for all files.

Editorial conclusion

Alef is published under the MIT license and requires Rust 1.88 or newer, with the source at github.com/xberg-io/alef.