Support init function without parameters

[ibaryshnikov]

Motivation

When used without a bundler, there is a need to call init with a .wasm file name:

await init('../pkg/my_project_bg.wasm');

and again

await init('../pkg/another_project_bg.wasm');

Proposed Solution

Make it possible to use

await init();

which will default to path with generated .wasm file

[fitzgen]

Do you have an idea of how to implement this?

While we know that the wasm is next to the JS glue by default, and we know how to go from the JS glue to the wasm with a relative URL path, we don't know where the whole pkg directory is hosted relative to the web page. And, IIUC, all requests are relative to the web page, not relative to the JS script's source that is making the request.

[ibaryshnikov]

@fitzgen what about import.meta?

function init(module) {
    let result;
    const imports = { './webgl_engine': __exports };

    if (typeof module === "undefined") {
        module = import.meta.url.replace(/\.js$/, '_bg.wasm');
    }

    if (module instanceof URL || typeof module === 'string' || module instanceof Request) {

[alexcrichton]

I think that's just a node-ism and wouldn't work in other locations? (and it's also only an es6 node-ism I think which is still somewhat experimental)

[ibaryshnikov]

What is node-ism? It's a part of es-modules, browser support according to MDN is Chrome 64, Firefox 62, Opera 51, Safari 11.1 (no information about Edge, but it will be based on Chromium anyway soon). It's possible to use import.meta for <script type="module" and document.currentScript otherwise. Inside <script type="module" document.currentScript is always null

[fitzgen]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta

Looks like it is stage 3 right now. Yeah, with import.meta we could do this for the --web target.

[alexcrichton]

Oh nice! I didn't realize that and that sounds reasonable to me!

[jljorgenson18]

I'm running into problems parsing the module with import.meta. If you are using target --web but still using babel to compile (like if you want to pass the url yourself for the wasm dist inside of a Webpack dist), then this fails. Babel prompts you to install a syntax plugin but it still fails in Webpack. Ideally, there would be an option to turn the import.meta fallback off since it is not fully supported yet and it may cause parsing errors for a feature that may not even be used.

[jljorgenson18]

I was able to get around this by adding

@babel/plugin-syntax-import-meta and babel-plugin-bundled-import-meta (with the importStyle set to cjs)

[Pauan]

@jljorgenson18 The web target is intended to be used without a bundler.

I think you want the bundler target instead.

[jljorgenson18]

@Pauan The bundler option doesn't work at the moment because it relies on Webpack's internal Wasm parsing (which is extremely buggy and I have yet to see it work). Nearly all of the workarounds I've seen for Webpack failing to parse the wasm file end up using file-loader and then they pass the url to WebAssembly.instantiate themselves. If you opt for a solution that loads in a wasm distribution via url, then the web target is the best bet since you can just pass in the url string. I think ideally, there would be a middle ground target that is more agnostic to pure web modules and pure bundler options.

[Pauan]

I haven't had any issues with Webpack + Wasm. There used to be some bugs in the past, but they've been fixed. Make sure everything is up to date (Webpack, wasm-bindgen, wasm-pack, etc.)

If you're still running into issues, then you should file a bug report.

[jljorgenson18]

The initial issues I ran into on the wasm-bindgen side had to do with #1246 and #1564 which seemed to be fixed by webpack/webpack#8786.

However, with using tools like Emscripten, Webpack cannot handle the wasm files webpack/webpack#7352. So the solution is just to instantiate the module yourself with a bit of glue code and to use file-loader. If you are using wasm files generated from various tools, chances are at this stage that Webpack won't work well with all of them. You could dynamically change the loader using inline loader syntax or a combination of oneOf + resourceQueries, but at that point, what is the point of using Webpack to instantiate the wasm modules? If you want to have greater control over how the wasm bytes are imported while still using some of the nice javascript bindings, then the web option actually works really well other than the import.meta condition.