Error resolving module specifier “env”

[fosskers]

Describe the Bug

I am working on a Seed application. Adding the following code...

    if let Ok(acc) = account {
        orders.perform_cmd(async move { Msg::TokenReq(auth::get_token(&acc).await) });
    }

... results in this line being added to the top of my package.js (the JS shim portion of the output of wasm-pack):

import * as __wbg_star0 from 'env';

Usually this line isn't present, nor have I seen it in any other WASM project of mine. When I try to run my WASM code in the usual way, the app fails entirely and I'm told this in my console:

Uncaught TypeError: Error resolving module specifier “env”. Relative module specifiers must start with “./”, “../” or “/”.

Indeed there is no env folder or file around (if that's what that import means), so I'm not sure what it's trying to do here.

Forgive me if this is the wrong place to have reported this. I chose this repo due to the wbg in the import line.

Steps to Reproduce

Unfortunately the rest of the code is closed-source, but I can at least say that I'm trying to test the tame-oauth crate. I'm not convinced that's the culprit though, as I have other code (in the same files) using that crate's functions and symbols without issue.

Expected Behavior

The app loads as normal.

Actual Behavior

I see a blank screen and the console complains to me as shown above.

Additional Context

I'm on the latest versions of wasm-bindgen etc.

See also:

• Using wasm target gives error: Error resolving module specifier “env”. Relative module specifiers must start with “./”, “../” or “/”. kellpossible/cargo-i18n#70
• parking_lot_core 0.8.1 wasm link issue Amanieu/parking_lot#269
• Instructions for using with wasm chronotope/chrono#382

[fosskers]

Forgive me, I did a search of the issues beforehand but somehow didn't find #2215 . Looking there now...

[fosskers]

Some debugging notes:

• Using the wasm-bindgen feature of parking_lot as reported elsewhere doesn't work.
• Down-pinning parking_lot_core as reported elsewhere doesn't work.
• Switching to nightly (alone) doesn't fix it.
• Using a proper release profile with lto = true does get rid of the import env issue, but still panics at runtime with:

panicked at 'time not implemented on this platform', library/std/src/sys/wasm/../unsupported/time.rs:39:9

[fosskers]

It turns out that tame-oauth makes a number of Utc::now() calls, which panics under WASM unless chrono is built with the wasmbind flag:

chrono = { version = "0.4", features = ["wasmbind"] }

However, adding that actually reintroduces the env issue 😞

[fosskers]

cc @MartinKavik , I will keep updating here with results of my experiments.

[fosskers]

Reproducing the bug: https://github.com/fosskers/env-bug-test

My current hypothesis is that the source of the issue must be within the call tree of ServiceAccountAccess::get_token.

[fosskers]

Two avenues of exploration in the call stack of get_token:

let issued = chrono::Utc::now().timestamp();

as well as a call to jwt::encode which leads down to this line:

let rng = ring::rand::SystemRandom::new();

SystemRandom? Sounds spooky.

[fosskers]

For the record, using wasm-dis to inspect the text-variant of the built WASM has the following hits for env:

(import "env" "LIMBS_less_than" (func $fimport$63 (param i32 i32 i32) (result i32)))
 (import "env" "LIMBS_select_512_32" (func $fimport$64 (param i32 i32 i32 i32) (result i32)))
 (import "env" "GFp_limbs_mul_add_limb" (func $fimport$65 (param i32 i32 i32 i32) (result i32)))
 (import "env" "GFp_bn_from_montgomery_in_place" (func $fimport$66 (param i32 i32 i32 i32 i32 i32 i32) (result i32)))
 (import "env" "LIMBS_less_than_limb" (func $fimport$67 (param i32 i32 i32) (result i32)))
 (import "env" "LIMB_shr" (func $fimport$68 (param i32 i32) (result i32)))
 (import "env" "LIMBS_sub_mod" (func $fimport$69 (param i32 i32 i32 i32 i32)))
 (import "env" "LIMBS_window5_split_window" (func $fimport$70 (param i32 i32 i32) (result i32)))
 (import "env" "LIMBS_window5_unsplit_window" (func $fimport$71 (param i32 i32) (result i32)))

[fosskers]

EmbarkStudios/tame-oauth#37 solves my personal issue (it pulls out parking_lot entirely), and so I will close this, but there still is something to be noted about these silent linker errors. Those should be getting caught and fail loudly if it knows it can't actually link.

[worikgh]

This is effecting me

Pure Rust building with wasm-pack.

[rukai]

This issue happens to be the highest result on google for uncaught TypeError: The specifier “env” was a bare specifier, but was not remapped to anything so I'm going to post a generic solution I found for tracking down which crate is causing this: #3500 (comment)