Make the WASM location configurable

So far we have been working on the assumption that the WASM file is in the root directory of the project. However, this may not always be the case, and it would be interesting if the user could define where their WASM file is. I’ve had to set this up by hand for the Three.js IFC Loader, and I think it would be interesting to incorporate it into web-ifc.

The path to the WASM file resides in the wasmBinaryFile variable generated by Emscripten.

The solution provided for Three.js was to add a global variable containing the relative path of the WASM that could be set through a function of the API. Something like:

var WasmPath = "";

//...

var wasmBinaryFile = WasmPath + "web-ifc.wasm";

//...

var IfcAPI = class {
   //...
   SetWasmPath(path){
     WasmPath = path;
   }
};

export {
  IfcAPI,
  ms
};

This setter function will be also present in web-ifc-three. This way, we will be able to use the Loader like this:

   const IfcLoader = new IfcLoader();
   ifcLoader.SetWasmPath("./whatever/path/");
   ifcLoader.load();

A minimal example of how this looks can be found here.

I suppose that the SetWasmPath can be added to web-ifc-api.ts. As for the global variable and the wasmBinaryFile initialization, we can probably write a JS file with a script to add these two lines to the bundled file.

[tomvandig]

Would vote against this, the WASM file as a standalone web resource enables browsers to cache the compiled code, reducing subsequent startup times by skipping compilation. More info here: https://v8.dev/blog/wasm-code-caching

I am by no means a chrome expert, but I expect this caching to break if we somehow bundle the wasm inside the js resource, they specifically mention:

Cached compiled code is associated with the URL of the .wasm resource, which makes it easy to look up without having to scan the actual resource. This means that changing the URL of a resource (including any query parameters!) creates a new entry in our resource cache, which also requires a complete recompile and creates a new code cache entry.

Could be this info is out of date though, no idea.

[agviegas]

Hum, might be. Feel free to dig into this, could be nice if it removes the WASM file handling!