wasmer-wasix unkown import "env" "now"

[WanderLanz]

wasmer-wasix dependency tempfile-v3.4.0 relies on fastrand-v1.9.0 which still has this issue for wasm32-unkown-unknown (web) target related to feature flag misconfiguration with the instant crate (outlined in this issue). This issue looks to be fixed in fastrand-v2.0.0, and tempfile-v3.6.0 depends on fastrand-v2.0.0 now. Also mentioned in wasm-bindgen on this issue and in parking-lot on this issue.

wasmer-wasix v0.x.x
└── tempfile v3.4.0 <-- v3.6.0 uses fastrand v2.0.0
    ├── cfg-if v1.0.0
    └── fastrand v1.9.0 <-- misconfigured feature flags, sometimes makes feature resolver "fail"? fixed in v2.0.0?
        └── instant v0.1.12 (*) <-- origin of (import "env" "now" (func ...))

As a temporary workaround for anyone who encounters this issue, you can try and pin the instant crate itself, as mentioned here:

[dependencies]
instant = { version = "0.1", features = ["wasm-bindgen"] } # same version pinned as `fastrand` v1.9

I haven't seen anyone else mention this issue and it didn't even manifest until I tried to implement HttpClient, so this probably isn't an issue for everyone.

It might just be the resolver being weird, but I thought I'd give anyone a heads up.

EDIT: see below

[WanderLanz]

So sorry, I made a goofy mistake of checking the git tempfile source for the dependency graph. tempfile v3.6.0 still depends on fastrand 1.x, so it still needs the instant-pin fix.

However, updating tempfile doesn't break anything and should have probably still been done just as with other dependencies, thank you for the quick response to this.

[Michael-F-Bryan]

This is no longer an issue as of the latest master (64ab037).

You can verify it using the following:

$ cargo tree --package=wasmer-wasix --features=js,wasmer/js,wasmer/std --target=wasm32-unknown-unknown --edges=features