Registering the wasm folder vs JavaScript bundlers

[andy-wrks]

What is your idea?

Currently the wasm file is registered via a path:
...settings.wasm.path = wasmPath;

This is problematic when using bundlers, which usually rely on bundling specific files and resolving a file path (rather than a folder path).
For example, it's not possible to use the cache busting feature of esbuild with webifc.wasm. How this usually works: esbuild includes a hash in the file name when bundling the file to the "dist" folder. It then resolves the file path to the new file name, like dist/webifc-1f67a5.wasm
However, since webifc looks for a hard coded file name inside a folder, this cache-busting technique can't work.
(In the case of esbuild, cache busting is the default bevahiour and it has to be turned off manually. Then the file name has to be deleted from the resolved path to provide a folder path for webifc.)

So to make web-ifc more compatible with common bundling workflows, I'd suggest to register the wasm file rather than the folder. Since there's only one wasm file anyway, it shouldn't make much of a difference.

Thanks for taking this into consideration and thanks for providing this great library!

[beachtom]

So we don't want to loose the ability for people to set the WASM path in the JS code, because quite a few fetch the wasm from CDN. There is also a different wasm in node - and a multi thread WASM that is used if the browser supports it. Can this deal with this situation?

[andy-wrks]

Sorry, I wasn't aware that there are different wasm files for different use cases. Please ignore what I said about there being only 1 wasm file...

I can refer to the DuckDB WASM port, which looks to be in a similar situation. It features 2 wasm files, where one seems to be for legacy browser environments (if I understand correctly) and they have a routine for picking the appropriate wasm file. They have examples on how to use it via CDN, Webpack and Vite here:

https://duckdb.org/docs/clients/wasm/instantiation

I mentioned esbuild in my original post, but their Webpack and Vite examples follow the same principle: you explicitly import both wasm files, so both paths can later be resolved to wherever they are bundled. The rest of their boiler plate seems to be quite custom, like pairing the wasm files with the worker files and automating which one to use.

It's probably not worth getting a headache about this feature request. I thought it could make life easier for people using bundlers. A bundled webifc can definitely be brought to life by disabling cache-busting and an extra line of code to turn the resolved file path into a folder path. If you come to the conclusion that changing the current behaviour would negativerly affect other scenarios, then it is what it is :-)