Explicitly add ".wasm" extension when importing wasm file in bundle target

[qt911025]

💡 Feature description

When Parcel resolves generated pkg as a dependency, it cannot recognize "generated_pkg_bg" as a wasm file like what Webpack can do. Adding wasm extension explicitly can archive the compatibility.

There are plugins and built-in support in Parcel to resolve rs file or "Cargo.toml" directly, but this is fit for building components in a project, not for using package. Besides, Parcel encapsulate the pack so WebAssembly memory cannot be manipulated (I can still come back and import the generated bindgen file).

💻 Basic example

In generated "my_pkg.js" (bundle target)

import * as wasm from './my_pkg_bg';

⬇️

import * as wasm from './my_pkg_bg.wasm';

[alexcrichton]

Thanks for the report! This has historically been brought up in #1133 and #1059, but it's unfortunately pretty tricky to do for various reasons. In any case I've moved this issue over to the wasm-bindgen repo as I think the issue is with wasm-bindgen, not wasm-pack.

[ibaryshnikov]

@alexcrichton are there any blockers for this update? There are situations when it's hard or impossible to modify weblack.config.js, and if .wasm is not explicitly mentioned as an allowed extension, the module would fail to load with an error like can't resolve 'my_module_bg'. We would fix a number of problems if use explicit extension

[Pauan]

@ibaryshnikov What version of Webpack are you using? It's not necessary to change the webpack.config.js, because Webpack already includes .wasm by default.

[ibaryshnikov]

@Pauan angular 8, webpack 4.35.2
It doesn't work out of the box in angular, my bet is that they overload resolve.extensions somehow, and there's no access to webpack.config.js there

[ibaryshnikov]

@Pauan as it was mentioned by @marienz in this comment, here's a possible reason:

extensions: ['.ts', '.tsx', '.mjs', '.js'],

[Pauan]

@ibaryshnikov Ah, right, Angular uses its own config, and hides webpack.config.js, quite annoying.

This should of course be fixed on Angular's side, but I'm also in favor of fixing it on our side too.

If I remember correctly, the reason we didn't do this earlier is because it was causing issues with tests, or something like that. So if all of that is resolved (and @alexcrichton gives the OK), then yeah let's fix this.