Skip to content

kuri-bind: multiplatform (KSP) binding backend for non-JVM targets #41

Description

@OmarAlJarrah

kuri-bind's runtime binder is JVM-only: it discovers annotated members through Kotlin reflection
(kotlin-reflect), which exists only on the JVM. The annotations, BindOptions, KuriBindException,
and the internal UrlBinder/UriBinder seam already live in commonMain, so their coordinates are
stable and code on any target can declare bindings today — only the runtime engine is JVM-bound.

A compile-time backend would close the gap: a KSP processor reads the same commonMain annotations and
generates a per-type binder — the same "binding plan" the reflective backend computes at runtime —
registered behind the existing binder seam. JS/Wasm/Native would then get the identical KuriBind
public surface with no reflection and no user-facing change.

Scope:

  • KSP processor emitting a binder per @Url/@Uri root, mirroring PlanCompiler/ReflectiveBinder
    (leaves, scalar-scoped recursion, @Url/@Uri merge, @PathTemplate hole resolution).
  • Wire generated binders into the seam resolver; move the KuriBind entry points from jvmMain to
    commonMain (ABI-compatible for JVM consumers — generated class names are unchanged).
  • Declare the additional Kotlin Multiplatform targets on the kuri-bind module.

Additive; current JVM behavior is unchanged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions