Publish nightly releases as part of the CI, so Ruffle can be easily
integrated into a website using a CDN (such as jsDelivr). It would
also be easier for websites to keep up-to-date, as NPM auto-updates
the `latest` tag to refer to the latest release.
A dedicated `package.json` is used for the published NPM package,
because `ruffle-selfhosted` depends on the private `ruffle-core`
package, which shouldn't be published.
Also, the `version` field must monotonically increase. So Webpack
auto-fills it to be `0.1.0-nightly.YYYY.MM.DD`. This format satisfies
a couple of needs:
* Newer nightly releases should take precedence over older ones.
* Stable releases (e.g. `1.0.0`) should take precedence over nightly
ones.
Use wasm-bindgen's built-in loader instead of relying on Webpack.
In order to still respect the `publicPath` config, set
`__webpack_public_path__` just before fetching the WebAssembly module.
This allows to no longer declare `.wasm` files as resource assets in
each `webpack.config.js`.
Use wasm-bindgen's built-in loader instead of relying on Webpack.
This allows to no longer declare .wasm files as resource assets in
each webpack.config.js.
Also the bundled JS is a bit smaller (e.g. demo is now ~88KB vs.
~90KB before).
* Remove `buildProduction` as it was equivalent to `build`.
* Fix `build:avm_debug` and change it to `build:debug`, which also
disables Webpack optimizations.
* web: Don't load a random SWF Instead, show a prompt to select or drag an SWF.
* web: Refactor webpack.config.js
* demo: Refactor index.js
* demo: Cleanup CSS
Use --target web in wasm-bindgen and file-loader for WASM files,
allowing wasm-bindgen's built-in fallback from
WebAssembly.instantiateStreaming to instantiate.
file-loader spits out the WASM file directly in the output folder,
and imports will resolve to the URL, so that we can load the file
directly, avoiding webpack's built-in wasm loaders.
This allows Ruffle to function on web servers even if they serve
WASM files with the incorrect MIME type, fixing one of our biggest
support requests (#400, #1458). There is some performance impact
on loading with the fallback, but this is preferable to not
working at all.