It should be possible to specify custom paths for multiple WASM binaries.

[annxingyuan]

Currently setWasmPath accepts a full path to the vanilla WASM binary. Now that we are shipping multiple WASM binaries to support experimental features, users need the ability to specify multiple custom paths.

One way to do this would be to change setWasmPath to something like setWasmPrefix, which would specify a custom directory with multiple WASM binaries.

[tafsiri]

Just a thought, we should also consider whether ppl will want flexibility on where the different binaries are or even what they are named (should more emscripten options pop up that are worth testing). While not strictly necessary it makes me think of this issue #3631.

[annxingyuan]

Oh good point, yeah I can imagine that coming up. So maybe we could have two functions:

function setWasmPrefix(prefix: string) // this would define a global wasmPrefix variable

function setWasmFileMap(fileMap: {path: pathOverride}) // this would define a global wasmFileMap variable

So we would check in locateFile whether fileMap is defined, and if so check whether an override is defined for whichever asset we are fetching. So if fileMap were something like {'tfjs-backend-wasm-simd.wasm': 'https://whatever/simdbinary.wasm'}, then we would use 'https://whatever/simdbinary.wasm' for the fetch URL of the SIMD binary.

Does that make sense?

[tafsiri]

Yep, but maybe just one public function that either takes a string (and then generates a fileMap internally) or a fileMap (that probably has keys for each supported module type?). I'm also not sure why it wouldn't use the full url in your example at the end (but maybe you meant that it would and it just rendered funky)?

Do you ever see wanting to try out other JS loaders/initializers for wasm that might not be built in? It may be that this isn't possible, but i'm just thinking about the kind of changes you are making now and whether you will likely have more experiments in the same vein.