Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Roadmap

This page tracks where WeaveFFI is, where it’s going next, and what lives beyond 1.0. The shape and stability of each surface is documented in the stability page; this page is the feature timeline.

Completed

Everything shipped in the 0.x line. The CLI is feature-complete for eleven targets and ~900 tests pass on Linux, macOS, and Windows.

Core CLI and IR

  • Subcommands: generate, new, validate, extract, lint, diff, doctor, completions, schema-version, upgrade, watch, format, schema.
  • IDL parsing from YAML, JSON, and TOML with span-aware miette-rendered diagnostics.
  • Validation rejecting name collisions, reserved keywords, and unsupported shapes; non-fatal diagnostics behind --warn and the dedicated lint command.
  • Inline [generators.<target>] configuration in IDL files plus external TOML configs; every GeneratorConfig field is reachable from both.
  • IR schema versioning with CURRENT_SCHEMA_VERSION = "0.3.0" and a weaveffi upgrade migrator that handles every supported source version.
  • JSON Schema export (weaveffi schema --format json-schema) and a checked-in weaveffi.schema.json for editor autocomplete.
  • File-watch regeneration (weaveffi watch) with debounced events.
  • Canonical IDL formatter (weaveffi format / --check).
  • Determinism: every generator’s output is byte-identical across runs on the same WeaveFFI version, enforced by tests.
  • Snapshot tests via cargo-insta for every generator across an eight-fixture corpus including a kitchen-sink IDL.
  • Fuzzing harnesses (cargo-fuzz) for the YAML/JSON/TOML parsers, the validator, and parse_type_ref, with a 5-minute CI smoke run on every PR.
  • Parallel orchestrator with per-generator cache invalidation.

Type system

  • Primitives, string, bytes, &str, &[u8] borrowed views.
  • Structs (with builder: true, default field values, doc strings).
  • Enums with explicit discriminants and per-variant docs.
  • Optionals (T?), lists ([T]), maps ({K:V}).
  • Typed handles (handle<T>) and the legacy untyped handle alias.
  • Iterators (iter<T>) for streaming sequences.
  • Module-level callbacks: and listeners: for event patterns.
  • async: true and cancellable: true functions.
  • Cross-module type references and nested sub-modules.
  • deprecated:, since:, and mutable: annotations.

Generators (eleven targets)

  • C — header with error struct, free helpers, typed handles, configurable c_prefix propagated through every emitted symbol.
  • C++ — RAII header (std::optional, std::vector, std::unordered_map, std::future), exception-based errors, CMakeLists.txt, configurable namespace and standard.
  • Swift — SwiftPM System Library + Swift wrapper with async/await and throws.
  • Android (Kotlin/JNI) — Kotlin wrapper, JNI shim, Gradle scaffold, suspend fun for async.
  • Node.js — N-API addon loader and .d.ts types with Promise for async.
  • WASM — JS loader and .d.ts types aligned with the C ABI error model.
  • Pythonctypes binding, .pyi stubs, asyncio for async.
  • .NET — P/Invoke binding, .csproj/.nuspec, Task<T> for async.
  • Dartdart:ffi binding, pubspec.yaml, Future<T> for async.
  • Go — CGo binding, go.mod, idiomatic error returns.
  • Rubyffi gem binding, gemspec, struct class wrappers.

Quality and infrastructure

  • cargo deny, cargo audit, cargo machete, rustdoc lints, and coverage in CI on every PR.
  • Cross-platform CI matrix (Linux, macOS, Windows) including an android-ndk job, a swift-spm job, and a windows-e2e-extended job.
  • End-to-end consumer programs in examples/ for every target, exercised in CI against the calculator and contacts cdylibs via examples/run_all.sh.
  • Async stress tests (1000 concurrent calls per target) verifying no callback/handle leaks.
  • Doc strings flow through to native doc-comment syntax in every target.
  • Standard prelude header (// Generated by WeaveFFI X.Y.Z … DO NOT EDIT) on every generated file.
  • Templates engine (Tera) with user-overridable templates.
  • Pre/post generation hooks.
  • Benchmarking infrastructure (criterion).
  • Automated publishing to crates.io via semantic-release.
  • Governance: CONTRIBUTING.md at the repo root and the canonical internal architecture reference under docs/src/.

Samples

  • calculator, contacts, inventory, async-demo, events, node-addon, plus the production-quality kvstore reference that exercises every IDL feature in one place.

v1.0 candidate

Every PRD-v4 phase is complete. The workspace has graduated from “feature-complete prototype” to “1.0 release candidate” pending the format-canonicalization polish noted in the README “Status” section.

  • Phase 1 — Eliminate TypeRef::Callback dead code across the workspace.
  • Phase 2 — Implement weaveffi upgrade and bump schema to 0.3.0.
  • Phase 3 — Wire every GeneratorConfig option through inline IDL configs.
  • Phase 4 — Source-span-aware diagnostics with miette.
  • Phase 5 — Snapshot testing every generator with insta.
  • Phase 6 — Deterministic generator output (sort all map iteration).
  • Phase 7 — weaveffi watch, weaveffi format, JSON Schema export.
  • Phase 8 — Real-world end-to-end consumer tests in CI for every target.
  • Phase 9 — Quality infrastructure: deny, audit, machete, doc lints, coverage.
  • Phase 10 — Fuzzing harness for parser, validator, and parse_type_ref.
  • Phase 11 — Doc strings everywhere: doc: → native doc comments.
  • Phase 12 — c_prefix audit: full propagation through C, C++, scaffold.
  • Phase 13 — Build a non-trivial real-world sample: kvstore.
  • Phase 14 — Parallel codegen with rayon and per-generator caching.
  • Phase 15 — Cross-platform CI hardening: Windows path/hook fixes, NDK glue, Swift/iOS smoke.
  • Phase 16 — doctor --json, target-specific checks, richer hints.
  • Phase 17 — --check and --format json for CI integration.
  • Phase 18 — Add CONTRIBUTING / SECURITY / CODE_OF_CONDUCT / ARCHITECTURE.
  • Phase 19 — Async robustness: GC pinning, cancellation, leak tests.
  • Phase 20 — Generator output polish: deterministic order, named-after-fields, prelude.
  • Phase 21 — Beautiful README, comparison page, marketing polish.
  • Phase 22 — Versioning policy, stability docs, roadmap to 1.0.
  • Phase 23 — Performance: run benchmarks, profile, optimize hot paths, set targets.
  • Phase 24 — Honesty pass on docs and full SUMMARY audit.
  • Phase 25 — Add weaveffi extract enhancements and round-trip integrity.
  • Phase 26 — Final quality pass and release-readiness checklist.

Post-1.0

Stretch goals that are out of scope for 1.0 but on our radar for the 1.x line:

  • LSP server for IDL files. Schema-driven completion, hover docs, go-to-definition for cross-module type references, and validation diagnostics inside any LSP-aware editor.
  • Official VS Code extension. Bundles the LSP server, adds syntax highlighting for .weaveffi.yml files, runs weaveffi watch integrated with the editor’s task system, and surfaces weaveffi doctor results in the status bar.
  • Bazel and Buck rules. First-class build-system integration so weaveffi_library(name = ..., idl = ...) produces all eleven target outputs as cacheable, reproducible Bazel/Buck targets.
  • Plugin SDK for third-party generators. A stable Generator trait surface plus a weaveffi-plugin-sdk crate so generators for additional targets (e.g. Lua, Erlang, OCaml, R) can ship as independent crates and be loaded dynamically by the CLI.
  • weaveffi publish automation. A subcommand that drives the per-target package publishers — npm publish, pod trunk push, mvn deploy, gem push, dotnet nuget push, pub publish, go mod proxy warmup, pip upload — from a single config file, with dry-run support and a CI-friendly --check mode.

If any of these would unblock your use case sooner, please open an issue describing the workflow you want — community demand drives the order.

See also

  • Stability and Versioning — what’s covered by SemVer and how the deprecation policy works.
  • Comparison — how WeaveFFI stacks up against UniFFI, cbindgen, diplomat, SWIG, and autocxx.
  • Architecture — the canonical “how WeaveFFI works internally” reference for contributors.