Error resolving module specifier “env”

[MartinKavik]

Hi,
a Seed app that indirectly depends on topo started to fail in runtime after some dependency updates.

The error in the console log:
Uncaught TypeError: Error resolving module specifier “env”. Relative module specifiers must start with “./”, “../” or “/”.

After some hours of debugging I was able to track it to the parking_lot. This crate doesn't support Wasm on stable Rust and I wasn't able to compile it on nightly to prove that it works - see my effort in the parking_lot issue.

It looks like it works with parking_lot <= 0.10, but the latest 0.11.x fails. Some cfg_ifs for wasm32 have been introduced in the latest parking_lot versions.

I was also looking at wasm-bindgen and something like more explicit JS module handling has been introduced in recent versions according its changelog.

So I guess that wasm-bindgen tries to link a required wasm module from parking_lot, but the module is "hidden" under some compilation flags in parking_lot and linking silently fails with some mess in the initialization JS script. Then the script is invoked on the app start and immediately outputs that cryptic error to the console log and dies.
The error is basically a show-stopper for most people - see the issue in wasm-bindgen.

Possible next steps:

• Choose another library for Mutex or use the one from std if possible and fast enough.
• We should somehow improve that error message - I'm not really sure if it's related to wasm-bindgen or Rust compiler or another library - some help would be very welcome.

Thank you very much!
Martin

[zetanumbers]

The parking_lot does actually support Wasm on stable Rust just like std::sync (by panicking on block). This is a moxie bug actually, because parking_lot dependency didn't specify any web required features like stdweb or wasm_bindgen. However right now code does panicked at 'already borrowed: BorrowMutError', D:\projects\moxie\dom\raf\src\lib.rs:62:32, while simple_mutex solution worked perfectly (which is based on std::sync::Mutex). Right now I think this happens bc of async schedule or smth. Oh my mistake, that's it!

[anp]

Thanks @zetanumbers for investigating and finding a fix! I've merged 24ab304 and am publishing patch releases of the affected crates.

@MartinKavik can you give that a try? I'll close this for now but if this issue still isn't resolved please reply back and/or reopen the issue.

[MartinKavik]

can you give that a try? I'll close this for now but if this issue still isn't resolved please reply back and/or reopen the issue.

I tried it with the new topo version (0.13.1) and it doesn't fix the issue. The flag wasm-bindgen only set the same feature flag in the instant crate - I can imagine it would resolve some other issues but not this one.
The problem is that parking_lot uses experimental API. The API requires nightly Rust and a compiler flag, see more info in this comment.

[zetanumbers]

@MartinKavik no. The parking_lot uses experimental wait/notify API only if you specify atomics target feature for wasm32. Without it there is no other option of blocking API on wasm32-unknown-unknown currently, so implementations of std::sync and parking_lot just panics if would block. The actual issue is that the instant crate relies on extern functions if none of stdweb or wasm-bindgen features are present, meaning it is trying to pull and link to them from this "env" thing.

EDIT: my advice to you would be to not use atomics feature and try to replicate this issue on the current main branch.

[MartinKavik]

my advice to you would be to not use atomics feature and try to replicate this issue on the current main branch.

I've just tried it with the moxie/topo's latest main and with topo 0.13.1. No luck for both cases, the same problem. I don't use atomics feature

My idea was that parking_lot fallbacks to a non-complete WASM support on stable Rust or without atomics feature and wasm-bindgen isn't able to process it correctly and fails in runtime because of that env error. But yeah I might be wrong, I wasn't deep enough it this rabbit hole to find all necessary data to prove my assumption.

[zetanumbers]

Ah sorry I forgot. Use feature wasm-bindgen for topo. @MartinKavik