Passthrough changes Response to be not compliant with WebAssembly.instantiateStreaming

First of all, we are using Mirage with an Ember project and it works fine 😊thanks for the awesome work. Since we really like Mirage we also tried to get it running for a Vue project which was scaffolded with vue-cli.

Currently, we are struggling to get Cypress running. We use the following plugin @vue/cli-plugin-e2e-cypress. I tried several things but I’m just not able to get our WebAssembly module running.

We start our WebAssembly module with WebAssembly.instantiateStreaming and also if I passthrough the wasm file Chrome complains the following way:

Mirage: Passthrough request for GET /static/artifacts/wasm/kernel.wasm
TypeError: Failed to execute 'compile' on 'WebAssembly': An argument must be provided, which must be a Response or Promise<Response> object

After some investigation, I think that Mirage wraps every Response in its own Response class? Is this true? For some reason, I wasn’t able to figure out why the type-check on instantiateStreaming fails. When searching the internet for this error message I only found the following source code: https://doss-gitlab.eidos.ic.i.u-tokyo.ac.jp/kevin/chromium/blob/ad3841a1e47cd90bba10f271a8495d4040490b07/third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc#L283

I’m a little bit lost (also because debugging is super hard with the vue-cli setup since Cypress is running somewhere else etc).

Any ideas what I could try to get the WebAssembly module running? Basically I followed those two quickstarters:

• https://miragejs.com/quickstarts/vue/development/
• https://miragejs.com/quickstarts/cypress/

Let me know if you need further info

[tschoartschi]

I found a workaround which works at least for us, what I do now is the following:

new Server({
  environment: 'development',
  logging: true,
  routes() {
    // Needed because Chrome recognizes that the Mirage Response is not a real response
    // with setting instantiateStreaming to null we fallback to legacy WebAssembly instantiation
    // this works with the Mirage Response, therefore the app can start
    // for more details see: https://github.com/miragejs/miragejs/issues/339
    Object.defineProperty(window.WebAssembly, 'instantiateStreaming', {value: null});
    const oldPassthroughRequests = (this.pretender as any).passthroughRequest.bind(this.pretender);
    (this.pretender as any).passthroughRequest = (verb: 'GET' | 'POST' | 'PUT' | 'DELETE', path: string, request: any) => {

      // Needed because responseType is not set correctly in Mirages passthrough
      // for more details see: https://github.com/miragejs/ember-cli-mirage/issues/1915
      if (verb === 'GET' && path.match(/\.wasm$/)) {
        console.log('Set responseType for wasm correctly');
        request.responseType = 'arraybuffer';
      }
      return oldPassthroughRequests(verb, path, request);
    };
    this.passthrough();
  },
});

@samselikoff maybe you could have a look at this workaround and let me know if this is OK or if it’s a stupid idea to do it like this 😉 thanks a lot

[tschoartschi]

@ryanto thanks for the response and sorry for the late reply but yesterday was a national public holiday in Austria. I created a repo which demonstrates the issue: https://github.com/miragejs/miragejs/issues/339#issuecomment-596625395

Let me know if this is enough our if you need further information 🙂

I think it’s a bug 🐛 in FakeXMLHttpRequest because I think FakeXMLHttpRequest does not set the responseType correctly. When debugging I found no sane way to tell FakeXMLHttpRequest to set the responseType. The only way I found was to set the rsponseType based on the file extension. This is what I outlined above in the passthrough hack