Resource Components

[patrickdet]

This PR implements WebAssembly Component Model resources in Wasmex, enabling WASM components to maintain their own internal state across multiple calls, essentially turning them into stateful applications running in a sandbox. This PR only implements guest resources. While host resources are possible in the Wasi component model, I would assume they are less common. We can add that later if needed.

This fundamentally changes what's possible with WebAssembly in Elixir: instead of just calling stateless functions, you're now interacting with persistent, sandboxed applications that maintain their own state, manage their own resources, and expose rich APIs through resource methods, all while maintaining WebAssembly's security guarantees.

It looks like this:

# WIT: counter.wit
  # resource counter {
  #   constructor(initial: u32);
  #   increment: func() -> u32;
  #   get-value: func() -> u32;
  # }

  # Generate Elixir client from WIT
  defmodule MyApp.Counter do
    use Wasmex.Components.GuestResource,
      wit: "counter.wit",
      resource: "counter"
  end

  # Use it
  {:ok, store} = Wasmex.Components.Store.new()
  {:ok, component} = Wasmex.Components.Component.new(store, wasm_bytes)
  {:ok, instance} = Wasmex.Components.Instance.new(store, component, %{})

  # Create and use resource
  {:ok, counter} = MyApp.Counter.start_link(instance, [0])
  {:ok, 1} = MyApp.Counter.increment(counter)
  {:ok, 1} = MyApp.Counter.get_value(counter)

  # Works with OTP supervisors
  children = [{MyApp.Counter, [instance, [42]]}]
  Supervisor.start_link(children, strategy: :one_for_one)

Disclaimer:
It was a quite a bit of work. Claude Code was used extensively.

I have just enabled the GH actions for now so I can see the run status on my branch. We can change that before merging.

[tessi]

hey @patrickdet! as before, huge thanks for this contribution. The LLM did again add a lot of unrelated changes. However, some I really like :D
Before going too deep on this PR review, I would go and pick some of these changes into main if you don't mind. My strategy is to review this massive 9k+ LOC PR by divide and conquer ⚔️

[tessi]

I have just enabled the GH actions for now so I can see the run status on my branch. We can change that before merging.

yes, let's do that. I wish I would be smart enough to figure out GH actions triggers so that they build nicely for your branches but not twice on PR pushes. I tried (also using GitHubs concurrency feature) but failed. Since tweaking CI is not my favourite hobby, I'd just like to keep the currently working config :)