env dependency not provided

[PSeitz]

🐛 Bug description

Error: Cannot find module 'env'
Require stack:

• /Users/d056831/Development/hdbconnect-wasm/pkg/hdbconnect_wasm_bg.js
• /Users/d056831/Development/hdbconnect-wasm/pkg/hdbconnect_wasm.js
• /Users/d056831/Development/hdbconnect-wasm/test.ts
  at Function.Module._resolveFilename (internal/modules/cjs/loader.js:780:15)
  at Function.Module._load (internal/modules/cjs/loader.js:685:27)
  at Module.require (internal/modules/cjs/loader.js:838:19)
  at require (internal/modules/cjs/helpers.js:74:18)
  at Object. (/Users/d056831/Development/hdbconnect-wasm/pkg/hdbconnect_wasm_bg.js:6:18)
  at Module._compile (internal/modules/cjs/loader.js:945:30)
  at Object.Module._extensions..js (internal/modules/cjs/loader.js:962:10)
  at Module.load (internal/modules/cjs/loader.js:798:32)
  at Function.Module._load (internal/modules/cjs/loader.js:711:12)
  at Module.require (internal/modules/cjs/loader.js:838:19)

In the file ./pkg/hdbconnect_wasm_bg.js there is arequire("env"), but it is not in package.json

const path = require('path').join(__dirname, 'hdbconnect_wasm_bg.wasm');
const bytes = require('fs').readFileSync(path);
let imports = {};
imports['./hdbconnect_wasm.js'] = require('./hdbconnect_wasm.js');
imports['env'] = require('env');

const wasmModule = new WebAssembly.Module(bytes);
const wasmInstance = new WebAssembly.Instance(wasmModule, imports);
module.exports = wasmInstance.exports;

I tried a npm install env with no success.

👟 Steps to reproduce

git clone https://github.com/PSeitz/hdbconnect-wasm

wasm-pack build --target nodejs

ts-node test.ts

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: tested with master and 0.8.1
rustc version: rustc 1.40.0-nightly (1423bec54 2019-11-05)

[Kelerchian]

@ashleygwilliams Passing through and dropping a possible clue

env is added in
https://github.com/rustwasm/wasm-bindgen/blame/master/crates/threads-xform/src/lib.rs#L236

printed in
https://github.com/rustwasm/wasm-bindgen/blame/master/crates/cli-support/src/lib.rs#L726

require('env') will actually refer to this 8 years old module https://www.npmjs.com/package/env which I believe is not the intention

Should env be process.env?
If so JsGenerated.generate_node_wasm_import should need a more flexible imports definition, where other modules should be able to imports.add("process.env") instead of imports.add("env")

[d3lm]

I am running into the same issue. Cannot run my binary on node because of require('env').

[cedeber]

Don't know if it helps, but happens only on release. (with target web, so I should be able to run it on the browser as generated - no npm install)

[d3lm]

@cedeber Yea, this is related to the nodejs target. When compiling to web everything works as expected.

[cedeber]

I use the web target, and it's not working as you can see here: https://github.com/cedeber/fluss

[cedeber]

Looks like the culpable is, or one of the optimizations in Cargo.toml (I used lto and opt-level), or wasm-opt I ran after wasm-pack. I didn't check which one exactly yet.

[d3lm]

Hm interesting. It should not be caused by the opt-level nor the lto, cause I am also compiling for web and for the release profile I use

[profile.release]
lto = true
opt-level = "z"

I see here you are simply calling init, shouldn't you pass in a string so that the wasm is internally fetched via instantiateStreaming? At least that's what I am doing.

[cedeber]

I have

lto = true
opt-level = "s"

so s instead of z for opt-level

I tried:

• none: works ✅
• opt-level="s" alone: works ✅
• lto = true alone: fails ❌

[tindron]

If I'm using rustc 1.44.1 I have to remove lto = true to produce a working wasm. With rustc 1.45.0-beta.3 I can leave lto = true and I get a wasm without this error.

[d3lm]

Not sure why but I am using nightly and lto works perfectly fine for me.

[jakearchibald]

This problem went away for me by updating to Rust 1.46

[d3lm]

@jakearchibald Do you know why it's fixed? Cause it still require's env and that package does not exist, cause to me this still seems to be an issue with the glue code generated by wasm-bindgen for the node target.

[jakearchibald]

No idea, sorry 😢

[Bajix]

Any new insights to this? Running into the same issue..

[arik-so]

Same here! Also, do we know what exactly within Rust code triggers whether require('env') gets added to the Javascript output?

[Bajix]

What're the odds of this being fixed in a timely fashion? My options are this being fixed this week or rewriting in JS...

[d3lm]

I personally think this is a bug with wasm-bindgen that generates the require('env') in the binding.

[Bajix]

Perhaps specific versions fo wasm-bindgen don't have this issue and could be used as a stop gap measure?

[rllola]

I have the same issue. I am using rust 1.46. It just appeared and wasn't there before.

[str4d]

I'm encountering this problem (currently observable in this commit) in the WASM file itself:

This dependency was not found:

* env in ./node_modules/wage/wage_bg.wasm

I do not have lto enabled, and I get this problem with opt-levels of s, z, and commented out.

$ rustc --version
rustc 1.50.0 (cb75ad5db 2021-02-10)
$ wasm-pack --version
wasm-pack 0.9.1

[str4d]

rustwasm/wasm-bindgen#2160 is a promising-looking thread.

[str4d]

In my case, Amanieu/parking_lot#269 was the root cause; an errant cargo update bumped my Cargo.lock to a version of parking_lot_core that triggers the problem. The workaround for me was to manually pin:

parking_lot_core = "=0.8.0"

[rishflab]

We were having this issue when trying to build rust-secp256k1 on MacOS (we did not experience this issue on ubuntu).

We were able to work around it by installing llvm and using clang from the new install instead of the default provided by MacOS and setting the env variables

brew install llvm

CC=/usr/local/opt/llvm/bin/clang
AR=/usr/local/opt/llvm/bin/llvm-ar

before running

wasm-pack build
wasm-pack test --node

[vovacodes]

Still reproducible on MacOS, Rust 1.56, parking_lot_core = "0.8.5" and the following cargo profile.

opt-level = "z"
lto = true

Fixed following @str4d 's advice, thanks!

[EdgeKing810]

FYI, this problem still exists. Opened up a new issue to get more attention and with more details.
@PSeitz have you been able to find a solution please?

#1100

[d3lm]

For those using parking_lot you should update to the latest version 0.11.2. The timer issue, which in some cases caused the missing env, has been addressed.

[MatthewHerbst]

I'm getting a similar issue when targeting web. Specifically, the generated .js file has the line import * as __wbg_star0 from 'env'; at the top, and then in the init function does imports['env'] = __wbg_star0;. When trying to load the script on an HTML page I get the error Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".

Build command: wasm-pack build --target web --release

I have all optimizations and such turned off. I've tried enabling them in different combinations based on advice in this and other threads but nothing has worked so far.

[package.metadata.wasm-pack.profile.release]
# wasm-opt = true

[lib]
crate-type = ["cdylib"]

[profile.release]
# lto = true
# opt-level = "s"
# opt-level = "z"
# panic = "abort"

$ rustup show
...
active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.60.0-nightly (89b9f7b28 2022-01-10)

parking_lot is not in our dependency tree at all.

[FineKe]

is there any progress or solution

[Soecka]

I'm getting a similar issue when targeting web. Specifically, the generated .js file has the line import * as __wbg_star0 from 'env'; at the top, and then in the init function does imports['env'] = __wbg_star0;. When trying to load the script on an HTML page I get the error Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".

Build command: wasm-pack build --target web --release

I have all optimizations and such turned off. I've tried enabling them in different combinations based on advice in this and other threads but nothing has worked so far.

[package.metadata.wasm-pack.profile.release]
# wasm-opt = true

[lib]
crate-type = ["cdylib"]

[profile.release]
# lto = true
# opt-level = "s"
# opt-level = "z"
# panic = "abort"

$ rustup show
...
active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.60.0-nightly (89b9f7b28 2022-01-10)

parking_lot is not in our dependency tree at all.

I had the same problem and then solved it by doing the following

// Remove the next line
// import * as __wbg_star0 from "env";

const __wbg_star0 = {
    global: {},
    env: {
        memory: new Memory({ initial: 10, maximum: 100 }),
        table: new Table({ initial: 0, element: "anyfunc" }),
        abort: () => {
            console.error("abort in wasm!");
            throw new Error("Unsupported wasm api: abort");
        },
        // Any other functions you need to inject with  WebAssembly.instantiateStreaming(module, importObject)
    },
};

My wasm project requires some functions to be injected via the env object, you can upload your wasm file via this website and see which functions need to be injected via the env object

https://webassembly.github.io/wabt/demo/wasm2wat/

Trying to figure out why this line of code is being created
import * as __wbg_star0 from "env"

[DougAnderson444]

The solution should not be to have to manually edit the bindgen files.

@alexcrichton attempted a fix of this years ago, yet many of us are still seeing this error under certain wasm-pack build --target web conditions.

The most robust workaround I have seen to this so far is from: Amanieu/parking_lot#269 (comment)

[features]
# `instant/wasm-bindgen` makes sure it will use `js_sys` for getting the system time
# `instant/inaccurate` uses `Date.now()` instead of `performance.now()`
default = ["instant/wasm-bindgen", "instant/inaccurate"]

[dependencies]
instant = "0.1.12"

[zeitlinger]

This is the workaround I'm currently using: https://gist.github.com/nicolas-sabbatini/8af10dddc96be76d2bf24fc671131add#file-wasm-bindgen-macroquad-L132-L135

Apparently it helps to just remove the imports - at least for some cases.