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.

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.}