Stream: git-wasmtime

Topic: wasmtime / issue #13136 Add an optional typed interactive...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 11:48):

afsalthaj opened issue #13136:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 11:49):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 11:49):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 11:50):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 11:57):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

https://github.com/user-attachments/assets/e006e346-2481-408d-9a08-b565d648441f

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 20:47):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

https://github.com/user-attachments/assets/e006e346-2481-408d-9a08-b565d648441f

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let x = instance()
>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 20:54):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

https://github.com/user-attachments/assets/e006e346-2481-408d-9a08-b565d648441f

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let x = instance()

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

It's very easy for developers to press Tab after typing a function name to automatically populate the arguments in correct Wasm Wave syntax. They can then simply edit the generated values instead of having to learn the syntax and type everything manually.
If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Here is a few other examples that showcase the use of option, variant, enum, record, result type etc with REPL

<img width="962" height="549" alt="Image" src="https://github.com/user-attachments/assets/8820b26d-c7fb-4be0-9fa4-b70fdbe0798a" />

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 21 2026 at 08:25):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

https://github.com/user-attachments/assets/e006e346-2481-408d-9a08-b565d648441f

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let x = instance()

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Here is a few other examples that showcase the use of option, variant, enum, record, result type etc with REPL

<img width="962" height="549" alt="Image" src="https://github.com/user-attachments/assets/8820b26d-c7fb-4be0-9fa4-b70fdbe0798a" />

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers. I can also attach a short video and screenshot of the REPL in action.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 21 2026 at 08:27):

afsalthaj edited issue #13136:

Feature

Add an optional typed interactive REPL to the Wasmtime CLI for exploring and invoking WebAssembly Components.

https://github.com/user-attachments/assets/e006e346-2481-408d-9a08-b565d648441f

The REPL would be powered by the rib-repl crate, which provides:

Example session after wasmtime component repl my-component.wasm:

>>> let counter = instance()
>>> counter.increment-and-get()
1
>>> counter.increment-and-get()
2
>>> let another-counter = instance()
>>> another-counter.increment-and-get()
1
>>> counter.increment-and-get() + another-counter.increment-and-get()
5

It works especially well with complex WIT types, including resources via dot-method syntax. In the below example cart is a WIT resource, and add-line, and line-count were functions within resource.

While it may sound intimidating to introduce a new language, users can become productive with just a 2-minute read of the basics — specifically how to create an instance and call functions on it. This makes it very easy for developers to quickly experiment with Wasmtime and their components.
By depending on rib-repl, we also get full auto-completion:

Function names
Function arguments (in correct Wasm Wave syntax)

If users don’t know the available function names, they can simply keep pressing Tab to list all exported functions. Typing a function name followed by ( and pressing Tab again will auto-populate the arguments with properly typed placeholders, which the user can then edit as needed.

>>> let x = instance()

>>> let my-resource = x.cart("foo")
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.add-line({sku: "foo", qty: 42})
()
>>> my-resource.line-count()
2

If there is a type mismatch or if not all required arguments are provided, a clear compilation error is shown before any WebAssembly code is executed.
The rib-repl crate does the heavy lifting. On the Wasmtime CLI side, we only need minimal integration with the rib-repl crate.

Here is a few other examples that showcase the use of option, variant, enum, record, result type etc with REPL

<img width="962" height="549" alt="Image" src="https://github.com/user-attachments/assets/8820b26d-c7fb-4be0-9fa4-b70fdbe0798a" />

Benefit

The current Wasmtime CLI excels at one-shot execution (wasmtime run) and serving, but interactively exploring components with rich WIT interfaces remains painful. Developers often end up writing a full Rust host just to test a few calls or understand stateful behavior.
A typed REPL would significantly improve the developer experience by making the Component Model more approachable for:

This directly supports broader adoption of the Component Model, a key focus area for Wasmtime.
Note on maturity: Although the public rib repository is relatively new, Rib has been developed and used in production for a couple of years inside Golem Cloud. It previously powered the Golem REPL and advanced usage of rib-lang. It was recently extracted into a standalone project so that other runtimes and tools in the wider WebAssembly ecosystem can reuse it. As part of the extraction, we removed all Golem-specific dependencies and simplified the surface area for broader applicability.
The project is backed by the Ziverge + Golem Cloud team, with multiple people actively working in the WebAssembly ecosystem.
Language guide: https://golemcloud.github.io/rib/guide.html

Implementation

I have already implemented a working prototype in this branch (feature-flagged under rib):
https://github.com/afsalthaj/wasmtime/tree/wasmtime_rib
The rib-repl crate is deliberately designed for easy embedding:

The integration is minimal and only re-exports what is needed from rib-repl. I am happy to refine the subcommand name, adjust the feature flag, or make any changes the team prefers.

I am happy to do any refinements needed.

Alternatives

*Existing external tools: The only other notable component REPL is wepl, which is tied to Wasmtime v17, lacks modern WIT-aware features, and is not designed as an embeddable library.

Rib REPLis currently the most modern and feature-rich option purpose-built for easy integration with Wasmtime (and other hosts). It uses the official wasm-wave crate for value formatting, staying fully aligned with the Component Model. Adding it as an optional, feature-gated dependency strikes the best balance between value and maintenance burden.
I believe this would be a valuable addition that helps accelerate Component Model adoption.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 23 2026 at 17:02):

tschneidereit commented on issue #13136:

Hi @afsalthaj, thank you for starting this conversation!

We just talked about this in the Wasmtime project meeting, and I'll try to laid out the conclusions we came to here. Other maintainers, please chime in if I'm missing or misrepresenting something!

The key conclusions we arrived at are:

  1. We very much would like to have a REPL for Wasmtime
  2. We don't want to tie it to a particular language, and instead support loading components that can act as a REPL by supporting a dedicated WIT world

The primary reasons for the second conclusion are that we don't want to choose a single language to become the REPL language for Wasmtime, and that doing it this way doesn't add a sizable chunk of dependencies to our supply chain. You mention that this could be an optional, off-by-default feature, but unfortunately that wouldn't really help with the supply chain issues, since we'd still want to cargo-vet everything. Additionally, an off-by-default REPL would provide a lot less value than one we can enable in the default builds.

Luckily, the Component Model gives us the means to do really powerful things here, and we have precedent for using it this way: this is pretty much how we're adding debugging support to Wasmtime. And in fact, the interface we're exposing for debugging has a lot of overlap with what a REPL/scripting interface needs. So much so that we think it'd be ideal if we could merge things as much as possible: the debugger API could be split into one part for introspection and one for debugger things like setting breakpoints, etc. A REPL interface could then include the former, and add functionality for things like dynamic instantiation, etc.

There'd obviously be questions around Capabilities (both around which to expose to the scripting component and how they'd be provided to dynamically created instance) and UX (such as how to determine which component to load as the REPL), but those seem eminently solvable.

Is this something you might be interested in taking on, by any chance? As @cfallin pointed out, now would be a fantastic time to do this, as the debugger interface hasn't quite been stabilized, so could still be reshaped to support this.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 23 2026 at 17:31):

jdegoes commented on issue #13136:

Would donating Rib to bytecodealliance help in any way? It can be owned by bytecodealliance and merely maintained by @afsalthaj and others as necessary.

I like the idea of supporting multiple REPL languages. However, the reality is that the component model has its own packaging system (with versioning, metadata, etc.), its own naming requirements, its own type system, its own everything.

Every time we tried to map another language onto the component model, we ran into usability issues. For our tastes personally, these usability issues were too severe to head down that direction.

Contrast that with Rib: its type system is the component model type system. It thinks about everything exclusively in terms of component model constructs. Although it is not an existsing language, it looks and feels natural when working with the component model, and adopts other standards where relevant (e.g. WAVE for literals).

Moreover, as the component model continues to evolve (e.g. first-class 'modules' or 'functions'), Rib can evolve alongside, with 1-to-1 mapping between the two.

A fully general-purpose multi-language REPL will have to solve the mapping problem, once per language, and then deal with evolution in the component model itself. If such a thing were possible with great usability, then we personally were not able to discover how. Rib packages everything we learned into something that's fun to use and doesn't hide or change anything in the component model.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2026 at 11:12):

tschneidereit commented on issue #13136:

Would donating Rib to bytecodealliance help in any way? It can be owned by bytecodealliance and merely maintained by @afsalthaj and others as necessary.

I don't think that changes the fundamental picture too much: the reasons I laid out above are unrelated to control of Rib, after all. That includes the review/vetting burden: we'd want Wasmtime maintainers to be comfortable with the code, since it'd be a pretty key part of the project. Additionally, looking at the Lockfile changes, Rib brings a fairly sizable set of additional dependencies we'd have to vet in any case.

Contrast that with Rib: its type system is the component model type system. It thinks about everything exclusively in terms of component model constructs. Although it is not an existsing language, it looks and feels natural when working with the component model, and adopts other standards where relevant (e.g. WAVE for literals).

Is this something that's somehow not possible to do with the type reflection APIs expressed as a WIT interface? If so, it'd be great to hear what the limitations are. If it is, though, then maybe Rib would simply be an excellent fit for a CM scripting language, but could nevertheless coexist with other languages using the same API? Looking through the repl command, I can't immediately see anything that couldn't be done with a WIT reflection API.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2026 at 12:51):

jdegoes commented on issue #13136:

Additionally, looking at the Lockfile changes, Rib brings a fairly sizable set of additional dependencies we'd have to vet in any case.

That's definitely legitimate. If it helps at all, we can remove any dependency not already in wasmtime (I don't think that would be a ton of work for us to do).

Looking through the repl command, I can't immediately see anything that couldn't be done with a WIT reflection API.

I haven't looked at the specifics, I think @afsalthaj would know better, but if it's possible to do this without changes to wasmtime, and retain the existing feature set, then that seems much better. I'll let Afsal comment on this one.

With the existing --invoke flag, I think we assumed that eventually wasmtime did want to have some kind of REPL integrated, with hot-reloading and stuff. But I can understand if that's out of scope, and if there's a way to get the same effect without integrating into wasmtime, then that sounds like the best of all possible worlds.

In that case, would bytecodealliance be a good home for a standalone CM REPL?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2026 at 12:56):

tschneidereit commented on issue #13136:

Quoting from my reply above:

  1. We very much would like to have a REPL for Wasmtime
  2. We don't want to tie it to a particular language, and instead support loading components that can act as a REPL by supporting a dedicated WIT world

The feedback here is entirely about _how_ to add a REPL to Wasmtime, not about not wanting to do so. I think it'd be fantastic if we could get to the point where one could just run wasmtime in a shell and enter a fully-featured REPL, configured to use an implementation of one's choosing in a config file.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 24 2026 at 22:48):

afsalthaj commented on issue #13136:

Thanks @tschneidereit and @jdegoes on the above comments.

Looking through the repl command, I can't immediately see anything that couldn't be done with a WIT reflection API.

I believe, this integration will be combination of usage of WIT reflection API , along with using rib-repl and simply inform the details to the REPL API. But I need to learn more on WIT reflection API before making more details.

Additionally, looking at the Lockfile changes, Rib brings a fairly sizable set of additional dependencies we'd have to vet in any case.

As @jdegoes already mentioned, we can try reducing the surface area further to not bring in too many dependencies.

Luckily, the Component Model gives us the means to do really powerful things here, and we have precedent for using it this way: this is pretty much how we're adding debugging support to Wasmtime. And in fact, the interface we're exposing for debugging has a lot of overlap with what a REPL/scripting interface needs. So much so that we think it'd be ideal if we could merge things as much as possible: the debugger API could be split into one part for introspection and one for debugger things like setting breakpoints, etc. A REPL interface could then include the former, and add functionality for things like dynamic instantiation, etc.

It makes sense to integrate the REPL part into the introspection capability of the debugging support that's in progress. I am happy to engage on this.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2026 at 10:59):

tschneidereit commented on issue #13136:

It makes sense to integrate the REPL part into the introspection capability of the debugging support that's in progress. I am happy to engage on this.

Great! I think the right first step here would be to identify the functionality that's required on top of what the debugging API already provides. Next, a proposal for a structure of the interfaces would make sense. As mentioned above, ideally both the debugger and the REPL would re-export an interface that contains all of the shared functionality.

Note that, same as for debugging, this is sufficiently large and complex that we'd want to have an RFC for it, so the key design decisions can be agreed upon before too much work is done in potentially the wrong direction.

Last updated: May 03 2026 at 22:13 UTC