Latest version seems to depend on `wasi:cli/[email protected]`

[karthik2804]

With the release of ComponentizeJS v0.17.0 we seem to have a hard dependency on the target world wit importing wasi:[email protected]. This seems to be due to StarlingMonkey trying to call environ_sizes_get. Here is a repro case https://github.com/karthik2804/componentizejs-env-bug-repro.

This was not a requirement in the previous versions of componentizeJS.

[karthik2804]

@tschneidereit pointed out that this would be the reason for it https://github.com/bytecodealliance/StarlingMonkey/blob/cd722519dc81b03a0db0afff4f6bf79a18169c83/host-apis/wasi-0.2.0/host_api.cpp#L1037

[guybedford]

We used to stub out environment after Wizering. If we add https://github.com/bytecodealliance/ComponentizeJS/issues/190 to allow enabling / disabling the env feature, we could then support stubbing env post-Wizer to create pure components again.

Also, that this slipped through is because we don't have a proper pure component test at the moment, we should ideally have one of those.

[tschneidereit]

I think this is a bug more in StarlingMonkey than here: the env reset should only happen where it does if the debugging opt-in happened during wizening.

We should also fix the issue here to restore pure components, of course :)

[andreiltd]

This should be fixed by this PR: https://github.com/bytecodealliance/StarlingMonkey/pull/249

[vados-cosmonic]

In a somewhat roundbout fashion, this is confirmed fixed via the automated example tests in Jco!