Cannot load wasm files; compiling stucks at 98%

[AndyBitz]

Bug report

Describe the bug

I tried to load a wasm module with a dynamic import.
The module was created with wasm-bindgen and works when used with webpack alone.
Here is the wasm-bindgen example

To Reproduce

The included zipfile contains the precompiled wasm file from the wasm-bindgen example.
It should be enough to run npm i, npm run dev and then open localhost:3000 in the browser.

next-wasm.zip

Expected behavior

The wasm module should be loaded dynamically and return an object with the function greet.

Error

Here is the terminal output.
It will just stay at 98%.
The error message came only after waiting for some minutes and then hitting Ctrl+C,
if you don't wait and just hit Ctrl+C it, it won't show anything.

WAIT  Compiling...                                                                                  
[hardsource:e5a00840] Using 4 MB of disk space.


Compiling

● client █████████████████████████ after emitting (98%) write-file-webpack-plugin


● server █████████████████████████ after emitting (98%) write-file-webpack-plugin


^CError: Invalid arguments
    at filesize (/home/andy/projects/web/next-wasm/node_modules/filesize/lib/filesize.js:57:10)
    at /home/andy/projects/web/next-wasm/node_modules/write-file-webpack-plugin/dist/WriteFileWebpackPlugin.js:198:132
    at /home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:4911:15
    at baseForOwn (/home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:2996:24)
    at /home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:4880:18
    at Function.forEach (/home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:9344:14)
    at handleAfterEmit (/home/andy/projects/web/next-wasm/node_modules/write-file-webpack-plugin/dist/WriteFileWebpackPlugin.js:160:24)
    at _err1 (eval at create (/home/andy/projects/web/next-wasm/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:26:1)
    at /home/andy/projects/web/next-wasm/node_modules/next/dist/build/webpack/plugins/unlink-file-plugin.js:100:18
Error: Invalid arguments
    at filesize (/home/andy/projects/web/next-wasm/node_modules/filesize/lib/filesize.js:57:10)
    at /home/andy/projects/web/next-wasm/node_modules/write-file-webpack-plugin/dist/WriteFileWebpackPlugin.js:198:132
    at /home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:4911:15
    at baseForOwn (/home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:2996:24)
    at /home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:4880:18
    at Function.forEach (/home/andy/projects/web/next-wasm/node_modules/lodash/lodash.js:9344:14)
    at handleAfterEmit (/home/andy/projects/web/next-wasm/node_modules/write-file-webpack-plugin/dist/WriteFileWebpackPlugin.js:160:24)
    at _err1 (eval at create (/home/andy/projects/web/next-wasm/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:26:1)
    at /home/andy/projects/web/next-wasm/node_modules/next/dist/build/webpack/plugins/unlink-file-plugin.js:100:18
got signal SIGINT, exiting

System information

• OS: macOS and Bash on Windows
• Version of Next.js: 7.0.0

Additional context

Building and exporting seem to work, however, if it tries to load the wasm file it will return a 404 response.

[AndyBitz]

Found out that the filesize error comes from webpack/webpack-sources.
As soon as webpack/webpack-sources#42 gets merged it should disappear and the compiling won't stuck at 98% anymore.

However, the import will now return a 404 code as well.

GET http://localhost:3000/_next/24c3009c365c8fdcc4bd.module.wasm 404 (Not Found)

Even though the file exists in .next and .next/server.

The file inside .next is also just around 20 Bytes, were as the original file is around 38 kB.

[AndyBitz]

The next versions of gajus/write-file-webpack-plugin and webpack/webpack-sources should fix the filesize error.

Looking through the sources of next.js I found this:

// server/index.js
routes['/_next/:path*'] = async (req, res, params, parsedUrl) => {
  await this.render404(req, res, parsedUrl)
}

So, every request to /_next/, if it's not a subdirectory, will return a 404.
But the wasm file is in this directory, unlike the dynamic imported js files that are in /_next/static/chunks/.

This is a workaround, but I guess there is a better solution:

routes['/_next/:path*'] = async (req, res, params, parsedUrl) => {
  if (/\.wasm$/.test(parsedUrl.pathname)) {
    const p = join(this.distDir, ...(params.path || []))
    res.setHeader('Content-Type', 'application/wasm')
    await this.serveStatic(req, res, p)
    return
  }

  await this.render404(req, res, parsedUrl)
}

Maybe something in the webpack config or an extra case for the server?

[timneutkens]

As you can see here the route should be served: https://github.com/zeit/next.js/blob/canary/server/index.js#L127-L141

But, it doesn't serve it with that specific mime type for wasm, as the mime-types in the send lib probably don't have it

[AndyBitz]

But this path only applies only for /_next/static/, doesn't it? The wasm file is actually in /_next/.
I guess it should be in static, but it somehow gets written to the wrong location, even though the the dynamic import tries to load the location it got written to.

Not in static:

GET http://localhost:3000/_next/24c3009c365c8fdcc4bd.module.wasm 404 (Not Found)

mime, which is used by send seems to support wasm.
https://github.com/broofa/node-mime/blob/master/src/test.js#L234

[timneutkens]

Check this example https://github.com/zeit/next.js/tree/canary/examples/with-webassembly

[AndyBitz]

Ahh, I see.
Adding config.output.webassemblyModuleFilename solved the 404 issue.

Wouldn't it make more sense to add it as a default?
At least when pillarjs/send#154 gets merged, to support the wasm mimetype.

PS: I'v actually searched for an example but just cmd+f -> wasm and totally skipped the webassembly one 😅.

[timneutkens]

We might rename with-webassembly to with-webassembly-wasm, or create with-wasm which links to the other example.

[timneutkens]

I think it makes sense to add the webassemblyModuleFilename option when Next.js can also serve that specific mime type

[timneutkens]

Actually we probably should add this as per the issue:

send.mime.define({ 'application/wasm': ['wasm'] })

And then add the webassemblyModuleFilename as per the example. Could you create a PR doing this? 🙌