Remove USE_ES6_IMPORT_META setting

[sbc100]

This setting was added (IIUC) as a temporary workaround for the lack or support for import.meta in browser and tooling.

However import.meta has been at stage 4 for almost 5 years now: tc39/proposal-import-meta#21

Webback (released in 2020) also has builtin support for import.meta, so I would hope the use case for disabling this setting no longer exists.

See #9234 and #8729

[brendandahl]

Potential follow up: I'm pretty sure closure supports module syntax now. Not sure about terser.

[sbc100]

I looked into this and will try to come up with followup. For now is seems like the eval phase is the one were we still need this.

[kleisauke]

FWIW, Cloudflare Workers doesn't support import.meta at the moment, see: cloudflare/workerd#2963.

That said, I don't think that should block this PR, since users can simply omit -sEXPORT_ES6 if they need to deploy there.

[sbc100]

FWIW, Cloudflare Workers doesn't support import.meta at the moment, see: cloudflare/workerd#2963.

That said, I don't think that should block this PR, since users can simply omit -sEXPORT_ES6 if they need to deploy there.

Or presumably one could just use a bundler before deploying to cloudflare? Which seems like a likely/good choice anyway, right?

[JoeOsborn]

This fix breaks cross-origin workers via mainScriptUrlOrBlob. Since the worker script is now hard-coded as the URL, we don't have the ability to use an inline worker to importScripts or use a downloaded blob.

[dlemstra]

I was using this option for a use case that was probably not the intention of this option. I used this option to avoid a bundler from embedding the wasm file. And without this option I now need to find a way in the tooling that uses the output to avoid inlining new URL('{{{ WASM_BINARY_FILE }}}', import.meta.url).href as new URL("data:application/wasm;base64,. I am using Module['locateFile'] and Module['wasmBinary'] to give control to the user of my library where to load the .wasm from. So for me it would still be nice to have an option to disable this or only allow the usage of locateFile and wasmBinary. But I can also understand that this would not be something that the team wants to maintain.

For those who are reading this in the future I use the following "hack" to work around this issue. Replace new URL('myfile.wasm', import.meta.url).href with new URL('myfile.wasm.empty', import.meta.url).href after the output is generated and add an empty file myfile.wasm.empty (replace myfile with the name of your wasm file). This will of course prevent that part from working so you will need to either set locateFile or wasmBinary to fix the loading of the wasm data.

[sbc100]

Interesting. It does sounds odd that this would be the option used to prevent the bundler from embedding the wasm. Can I ask what bundler you are using? Have you looked for a blunder setting that might avoid this?

[dlemstra]

I am using vite 6 that is using rollup as it's bundler and I have tried using several of the suggested options for this but none of them seemed to work for my project.

[sbc100]

Is there an open bug again vite for that? It certainly seems like a bundler bug/feature, rather than something emscripten should be having to deal with.

[dlemstra]

I have not found a bug about that so I will probably need to report one. But that will probably take me some time to create something that can be used to reproduce it. And the work around can be a possible "fix/hack" when someone else also has a problem with their bundler.

[Sec-ant]

I have exactly the same use case as what @dlemstra mentioned above for USE_ES6_IMPORT_META in one of my project, I also let users to use locateFile to override the wasm serve path. I ended up patching the preamble.js file to restore the old behavior, which is far from graceful but yields the expected output. I also use vite 6 to bundle my project.

[jinwuwu001]

Removing USE_ES6_IMPORT_META will result in library users being unable to customize the loading location of .js when using multi-threaded .wasm.
The multi-threaded .js code obtained when USE_ES6_IMPORT_META=0 is as follows:

// emsdk 4.0.1
allocateUnusedWorker() {
  var worker;
  var workerOptions = { type: "module", name: "em-pthread" };
  var pthreadMainJs = _scriptName;
  if (Module["mainScriptUrlOrBlob"]) {
    pthreadMainJs = Module["mainScriptUrlOrBlob"];
    if (typeof pthreadMainJs != "string") {
      pthreadMainJs = URL.createObjectURL(pthreadMainJs);
    }
  }
  worker = new Worker(pthreadMainJs, workerOptions);
  PThread.unusedWorkers.push(worker);
}

Users can set the loading location through mainScriptUrlOrBlob

const moduleConfig = {
  locateFile: (file: string) => {
    const path = `${demoDir}.wasm`;
    return path;
  },
  mainScriptUrlOrBlob: `${demoDir}.js`
};

The multi-threaded .js code obtained when USE_ES6_IMPORT_META=1 is as follows:

// emsdk 4.0.4
allocateUnusedWorker() {
  var worker;
  worker = new Worker(new URL("demo.js", import.meta.url), { type: "module", name: "em-pthread" });
  PThread.unusedWorkers.push(worker);
}

At this time, users can only load files from the following path

`{import.meta.url}/demo.js`

Cannot load files from the specified location unless manually modifying demo.js
for example:

`{import.meta.url}/dir1/demo.js`
`{import.meta.url}/dir1/dir2/demo.js`
`{import.meta.url}/dir1/dir2/dir3/demo.js`

How to customize the loading location after removing USE_ES6_IMPORT_META
It is necessary to customize the loading position in the scenario of dynamically loading .wasm

[kleisauke]

@jinwuwu001 Could you re-test with Emscripten 4.0.6 or later? I think your use-case was fixed via commit 9e21488.