wasmtime / PR #13108 Delete the `wasi-common` crate from ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #13108 Delete the `wasi-common` crate from ...

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:30):

alexcrichton requested wasmtime-wasi-reviewers for a review on PR #13108.

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:30):

alexcrichton opened PR #13108 from alexcrichton:remove-wasi-common to bytecodealliance:main:

This crate has been languishing without maintenance within this repository for a number of years now and I think it's time to remove it. This commit proposes removing it without replacement.

Some history of the wasi-common crate:

This crate is the original implementation of WASIp1 dating back to 2020 or so.

The wasmtime-wasi crate was a reimplementation of WASIp1 and WASIp2 introduced with the component model. Upon introduction the wasmtime-wasi crate was off-by-default for WASIp1.

The wasmtime CLI eventually grew a -Spreview2={y|n} for controlling which implementation to use. Perhaps a bit confusingly -Spreview2 affects the implementation of WASIp1 when running core modules as well.

Eventually -Spreview2 was enabled by default meaning that core modules in the wasmtime CLI used the wasmtime-wasi implementation by default.

Since then wasi-common has been on life support and has received little-to-no updates. All maintenance and work is focused on wasmtime-wasi while wasi-common is more-or-less ignored.

The main reason wasi-common has stuck around until now is that it's the only way to use WASIp1 APIs when enabling the experimental wasi-threads proposal. The wasmtime-wasi crate architecturally does not support threads, so it cannot fill this niche.

This begs the question of: why remove the crate now? The rationale I have is:

The writing has been on the wall for wasmtime-wasi for quite a long time. This is an acknowledgement that it's there.

The wasi-threads proposal as-is is a dead-end and this has long been known. Further work on that proposal is all expected to go down the route of shared-everything-threads, which is a drastically different approach than what it is today.

The dependency burden of wasi-common is real and cannot be overlooked. We've still had to update code in wasi-common for crate updates and such and this, while small, is not trivial. I'm recently trying to remove the system-interface dependency from Wasmtime and it's deeply embedded within wasi-common as an example.

Users being able to run at least cooperatively threaded code is expected to be possible with WASIp3. This is expected to land this year which means users will, eventually, have a path forward for "just run code that uses pthreads".

Wasmtime still supports this crate in the LTS releases. Wasmtime 36, for example, is supported until August 2027 which means that we're still maintaining it for another 1.5 years no matter what. This, however, is also a reason to remove it before the next LTS to avoid furthering its ongoing maintenance.

Overall I personally feel that the calculus has pointed towards the removal of wasi-common for quite a long time now and we just haven't gotten around to it. Thus, this commit gets around to it. The concrete changes here in this commit are:

The wasi-common crate is deleted.

The -Spreview2=n flag on the wasmtime CLI now unconditionally prints an error saying it's unsupported.

The -Sthreads flag now requires that -Scli=n is passed (wasi-threads is incompatible with the implementation of WASIp1)

Tests are updated in a few locations as well.

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:30):

alexcrichton requested cfallin for a review on PR #13108.

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:30):

alexcrichton requested wasmtime-default-reviewers for a review on PR #13108.

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:30):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13108.

Wasmtime GitHub notifications bot (Apr 15 2026 at 17:39):

alexcrichton updated PR #13108.

Wasmtime GitHub notifications bot (Apr 15 2026 at 18:00):

cfallin submitted PR review:

Removal looks OK to me technically!

As a policy decision this should probably be discussed at the next Wasmtime meeting just for completeness / formal approval (I personally agree completely with your rationale here but don't want to speak for the whole project).

Wasmtime GitHub notifications bot (Apr 15 2026 at 18:00):

cfallin created PR review comment:

Should we update the comment just above this to no longer refer to the "historical preview1 implementation"?

Wasmtime GitHub notifications bot (Apr 15 2026 at 18:28):

pchickey submitted PR review:

As the one of the authors of wasi-common I strongly support this change - its definitely time to sunset this legacy code. I agree with Chris that we can discuss it at a Wasmtime project meeting just to give everyone time and opportunity to weigh in.

For anyone who still needs wasi-common, they can use it on the LTS releases until their support term is up, but removing this crate from the tree frees us from a real maintenance burden and is the right path for the project.

The -Sthreads flag now requires that -Scli=n is passed (wasi-threads is incompatible with the implementation of WASIp1)

I think that this means that, effectively, there are no more programs that can make use of the wasi-threads proposal in wasmtime.

wasi-threads was always proposed and used a superset of wasip1, and since now the implementation won't support the wasip1 imports at all, we should also be sunsetting the wasi-threads implementation at the same time as we sunset wasi-common.

As you said in the justification for removing wasi-common, the entire story behind wasi-threads has long been known to be a dead end, and with wasip3 we now have a cooperative threads implementation on track to land, and shared-everything threads will follow after that.

Wasmtime GitHub notifications bot (Apr 15 2026 at 18:30):

pchickey edited PR #13108:

This crate has been languishing without maintenance within this repository for a number of years now and I think it's time to remove it. This commit proposes removing it without replacement.

Some history of the wasi-common crate:

This crate is the original implementation of WASIp1 dating back to 2020 or so.

The wasmtime-wasi crate was a reimplementation of WASIp1 and WASIp2 introduced with the component model. Upon introduction the wasmtime-wasi crate was off-by-default for WASIp1.

The wasmtime CLI eventually grew a -Spreview2={y|n} for controlling which implementation to use. Perhaps a bit confusingly -Spreview2 affects the implementation of WASIp1 when running core modules as well.

Eventually -Spreview2 was enabled by default meaning that core modules in the wasmtime CLI used the wasmtime-wasi implementation by default.

Since then wasi-common has been on life support and has received little-to-no updates. All maintenance and work is focused on wasmtime-wasi while wasi-common is more-or-less ignored.

The main reason wasi-common has stuck around until now is that it's the only way to use WASIp1 APIs when enabling the experimental wasi-threads proposal. The wasmtime-wasi crate architecturally does not support threads, so it cannot fill this niche.

This begs the question of: why remove the crate now? The rationale I have is:

The writing has been on the wall for wasi-common facing end-of-life for quite a long time. This is an acknowledgement that it's there.

The wasi-threads proposal as-is is a dead-end and this has long been known. Further work on that proposal is all expected to go down the route of shared-everything-threads, which is a drastically different approach than what it is today.

The dependency burden of wasi-common is real and cannot be overlooked. We've still had to update code in wasi-common for crate updates and such and this, while small, is not trivial. I'm recently trying to remove the system-interface dependency from Wasmtime and it's deeply embedded within wasi-common as an example.

Users being able to run at least cooperatively threaded code is expected to be possible with WASIp3. This is expected to land this year which means users will, eventually, have a path forward for "just run code that uses pthreads".

Wasmtime still supports this crate in the LTS releases. Wasmtime 36, for example, is supported until August 2027 which means that we're still maintaining it for another 1.5 years no matter what. This, however, is also a reason to remove it before the next LTS to avoid furthering its ongoing maintenance.

Overall I personally feel that the calculus has pointed towards the removal of wasi-common for quite a long time now and we just haven't gotten around to it. Thus, this commit gets around to it. The concrete changes here in this commit are:

The wasi-common crate is deleted.

The -Spreview2=n flag on the wasmtime CLI now unconditionally prints an error saying it's unsupported.

The -Sthreads flag now requires that -Scli=n is passed (wasi-threads is incompatible with the implementation of WASIp1)

Tests are updated in a few locations as well.

Wasmtime GitHub notifications bot (Apr 15 2026 at 20:03):

github-actions[bot] added the label wasi on PR #13108.

Wasmtime GitHub notifications bot (Apr 23 2026 at 22:13):

alexcrichton closed without merge PR #13108.

Wasmtime GitHub notifications bot (Apr 23 2026 at 22:13):

alexcrichton commented on PR #13108:

I've opened an RFC for this after the discussion in today's meeting, so I'll close this in favor of that.

Last updated: May 03 2026 at 22:13 UTC