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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions