Can't resolve 'env' in .../pkg - how to investigate?

[kalzoo]

Following on from issue reported here and closed.

My situation in particular:

• private crate, private source
• wasm-bindgen has been working smoothly for about a year across many releases
• WASM package is then consumed by a React frontend. The error appears when that frontend is built, in release or dev mode.
• In the course of one particular, small-scope MR, the task began to fail with the titular error:

Module not found: Error: Can't resolve 'env' in '<redacted>/pkg'

• No crates or JS deps have been updated in Cargo.toml or package.json
• I can reproduce locally and in CI, not a caching/environment issue
• Building the package with wasm-pack build, both --debug and not

What I've done

• Use wasm2wat to text-ify the output. That comes out to roughly 7.6M LoC with no clear indications of the dangling reference
• Created an empty env package and linked that into the package with the following. This at least makes the JS build work. So the missing function reference is only one level deep; not sure how much of a revelation that is.

So, my question - what's the right way to investigate this?

• It appears that something about one of the Rust dependencies changed so that something which was able to be built with WASM can no longer be
• It's not clear to me how that could be the case and why that's not a compilation failure
• It's also not clear how I can go about discovering which external reference in the WASM package no longer exists
• I can diff the (working package versions) with the (no longer working) from CI logs (the lockfile is not source-controlled), but even with a short list of packages, unless something is called out in that package's github issues etc I'm not sure the culprit will be obvious. And - even if it is obvious in my case - this discussion may be useful for others later.

[Liamolucko]

You can pretty easily see the name of the import that's causing an issue using wasm2wat by searching for (import "env", which should show you one or more lines like this:

(import "env" "function" (func $function (type 4)))

Unfortunately though all the information about what crate the import came from is erased.

However, cargo outputs a separate object file for every crate you depend on in target/wasm32-unknown-unknown/debug/deps (wrapped up inside an rlib), so you could figure out which crate caused the offending import by looking through all of those to see which one imports it.

I got kind of over-invested in this and created a tool which does that automatically: https://github.com/Liamolucko/find_wasm_import. You have to use wasm2wat to find what the name of one of the offending imports is first, but after that you just point it at the deps folder and it should tell you the crate which is causing the problem:

> find_wasm_import env function target/wasm32-unknown-unknown/debug/deps
"env" "function" is imported by:
  target/wasm32-unknown-unknown/debug/deps/liboffending_crate-037c8cef292eb070.rlib

Also, by the way, the error isn't necessarily cropping up now because of something changing about your dependencies. Imported functions like the one causing this error only get included in the output wasm if they're used, so it might be happening because you started using some new feature of a dependency you already had which relies on some wasm-incompatible import.

[daxpedda]

I got kind of over-invested in this and created a tool which does that automatically: https://github.com/Liamolucko/find_wasm_import.

That's pretty sick @Liamolucko, thank you! That's a very useful tool.

[kalzoo]

Thanks, @Liamolucko , that's awesome! Indeed, this came down to the instant crate, which joined the dependency tree as a dep-of-a-dep-of-a-dep and with which I wasn't yet familiar. Curiously enough, it specifically exists for wasm, but I had to enable its wasm-bindgen feature. Back in business! Would have been hard to solve this without this tool you wrote. Worth adding a note & link in the docs and maybe pulling it into the repo itself?

[frewsxcv]

Thank you for this thread and utility. In my case, it is was instant:

% find_wasm_import env now target/wasm32-unknown-unknown/release/deps
"env" "now" is imported by:
  target/wasm32-unknown-unknown/release/deps/libinstant-84b16be68a676ab1.rlib

[xangelix]

@Liamolucko you saved my life! Really disappointed there isn't any error sooner than runtime. Do you know of any progress that has been made on that front, to error at compile time?

[yunho-c]

I encountered a similar error in pykeio/ort cate and resolved by switching rustc to nightly branch via rustup.