[WASM] Module not found: Error: Can't resolve

[suyoshi]

🐞 bug report

Description

wasm-pack creates a bundle which ends up doing this:
import * as wasm from './my_wasm' (my_wasm is in reality my_wasm.wasm, notice the absence of the .wasm extension.)

When I import the package in my angular project I get the following error during ng build:
Module not found: Error: Can't resolve './my_wasm' in 'my_package'.

While it is supposed to work with Webpack. As far as I can tell one solution is to add resolve.extensions: ['.wasm'] to the webpack configuration, but Angular doesn't expose that option.

🌍 Your Environment

Angular Version:
8.0.3

Anything else relevant?

[alan-agius4]

@suyoshi currently to apply custom webpack config using ngx-build-plus.

[Pauan]

Webpack adds in the .wasm extension by default, so Angular's behavior violates the expected Webpack behavior.

[filipesilva]

It's true that Webpack adds the .wasm extension to their resolve options, but Angular CLI does not have as a goal to expose Webpack semantics or default configuration. We try to maintain our own list of extensions and mainfields that the default build system of Angular CLI uses and only explicitly support those.

In fact we do our best to keep anything that is webpack-specific away from project source-code, because at some point in the future we might decide to change our build system.

Is it problematic to just import my_wasm.wasm instead? This is a valid import.

[Pauan]

Is it problematic to just import my_wasm.wasm instead? This is a valid import.

And what about a library which internally uses WebAssembly and imports it without the .wasm extension? In that case you cannot modify the code, so you're stuck.

This is a common use case, there are already several npm libraries which internally use WebAssembly to speed up their internal algorithms, and the usage of WebAssembly will only go up over time.

You cannot expect all library authors to explicitly import .wasm, especially since importing without .wasm works fine with Webpack, and Webpack is the de-facto bundler (and thus most code is written for it).

[filipesilva]

I think you're giving Webpack a bit too much importance in this topic. Webpack is very popular, but that doesn't mean everyone uses Webpack.

For instance, a lot of toolchains use Rollup instead. The WASM rollup plugin shows an example of importing a .wasm file with the extension. Parcel is popular as well, and their WASM support also lists an example of using the extension. I couldn't actually find a page in the Webpack docs showing how to use WASM, but there is an example in the repository that also shows imports with the extension. Aside from bundlers, Both browsers and NodeJS show examples of loading WASM files with an extension. So from this admittedly short survey of the package and runtime landscape, I saw none that directed users to import WASM without extensions.

If you have a library and you package it in a way that assumes Webpack, then you are limiting how consumers can use your library. The limitations are both that consumers must use webpack, and that webpack must be configured in a certain way to use the library. This is a serious limitation because it gets passed on transitively to both your direct and indirect consumers. A user might not use a library directly and still run into these problems because of an indirect dependency.

The specific case of changing the an extension resolver also has performance implications. That's the list of extensions the resolver will try to load before it gives up on loading a file. So each extension added there increases total file system operations by a factor relative to its position in the priority array. In Webpack's case, .wasm is the first one, followed by .mjs, then .js, then .json. If I ask Webpack to bundle a .js file without an extension, it will first try to load .wasm and .mjs. So for the case of .js files, this triples file reads for existing files. For nonexistent files, it adds 1/4 more reads. This cost is incurred for all resolutions, so a large project that uses a single library with a .wasm import must pay the cost on all attempted resolutions.

I'm sure Webpack has great reasons for listing .wasm on their default extension resolver. But like I said before, it was never a goal for Angular CLI to expose Webpack semantics. Another example of not exposing Webpack semantics is not using require in user code for .html and .css files, or not exposing Node globals. We avoid Webpack-specific semantics because it creates coupling of the CLI and user code to Webpack. If in the future we want to migrate to another setup, this couple would create problems. If a user wants to move away from the CLI to another bundler, the same coupling will also create problems for them.

If importing .wasm files without an extension was indeed a standard in platforms (like NodeJS or Chrome), it would make sense for Angular CLI to do it. If it was common practice among bundlers, it would make sense to consider the pros and cons and perhaps do it as well. But as far as I can tell it's neither.

If you have a library that assumes the .wasm extension will automatically be attempted by the consumers toolchain, I urge you to adopt a more consumer friendly packaging approach. Coupling your library to the semantics of a specific tool (be it Webpack, or any other) is harmful for the JS ecosystem.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}