Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASM bundle loader #473

Merged
merged 16 commits into from
Jan 6, 2018
Merged

WASM bundle loader #473

merged 16 commits into from
Jan 6, 2018

Conversation

devongovett
Copy link
Member

This refactors the way async bundle loaders work so that custom formats can be registered. Previously, there were only CSS and JS bundle loaders for dynamic import()s hard coded. Now you can call e.g. bundler.addBundleLoader('ext', '/path/to/my/loader.js') to add a bundle loader for some custom type. These will automatically be included in the bundle by the JSPackager if that type is dynamically imported.

This also makes it possible to have other bundles be preloaded prior to a JS bundle being executed. This is for the case of e.g. wasm where we don't want to inline the binary into the JS, but the import was synchronous: e.g. import {add} from './add.wasm'. In this case, the JSPackager notices that the module is in an external file, and adds some code to preload it prior to the JS being run. This is only done for root JS bundles, because for async/dynamic imports the wasm file would be loaded in parallel with the JS already.

This is a somewhat large change, and I ended up refactoring a bunch of other stuff to make it work. Please test out this branch and report any bugs you find! Thanks! 😍

Register custom loaders with `bundler.addBundleLoader`
Enables `bundler.getAsset` method to resolve and process an asset at any time, outside of the normal asset tree construction.
This gives us a separate bundle for each output file.
Allows synchronous import to preload modules in external files, e.g. .wasm file, prior to execution of the JS bundle.

Also processes the HMR runtime like other assets.
No longer returns a URL to the JS bundle if there is a bundle loader defined. This will cause the asset to be preloaded prior to JS bundle execution.
@devongovett devongovett mentioned this pull request Jan 2, 2018
@albizures
Copy link
Contributor

Hi @devongovett great job!

I have been testing it out but I get this error:

in chrome and firefox, in safari works perfectly

and I found that compileStreaming checks the MIME type, so it's a matter of adding the MIME type to the response.
but also I tried changing loadWASMBundle to:

module.exports = function loadWASMBundle(bundle) {
  return fetch(bundle)
    .then(response => response.arrayBuffer())
    .then(bytes => WebAssembly.instantiate(bytes, {}))
    .then(results => results.instance.exports)
};

and it's works on chrome, firefox and safari!
I don't know what the real difference is between this two ways

@devongovett
Copy link
Member Author

Thanks for testing! Ok, I guess we need to use something like https://www.npmjs.com/package/mime to serve correct mime types in the dev server.

@devongovett
Copy link
Member Author

@albizures added the correct mime type for wasm, and it seems to be working for me now in chrome.

@devongovett
Copy link
Member Author

One current issue is with HMR - the port is now injected by an environment variable since the HMR runtime is a normal asset now and not injected by the packager. The problem is that env vars don't currently invalidate the cache when they change, and by default the HMR port changes on every run. Going to fix this as part of #297 hopefully.

@albizures
Copy link
Contributor

albizures commented Jan 5, 2018

the MIME type error is gone but now I'm getting this error
captura de pantalla 2018-01-04 a la s 9 45 24 p m
again in chrome 😞, in firefox and safari it works perfect

btw I'm MacOS

Should fix error “WebAssembly.Instance is disallowed on the main thread, if the buffer size is larger than 4KB”
@devongovett
Copy link
Member Author

@albizures interesting. I've changed it to use WebAssembly.instantiateStreaming and WebAssembly.instantiate instead. Let me know if that works.

@albizures
Copy link
Contributor

it works perfectly! ✨

@devongovett
Copy link
Member Author

Awesome, going to merge this. 💥

@devongovett devongovett changed the title [WIP] WASM bundle loader WASM bundle loader Jan 6, 2018
@devongovett devongovett merged commit a38a6f4 into wasm Jan 6, 2018
@devongovett devongovett deleted the wasm-loader branch January 6, 2018 02:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants