This commit adds a new attribute to `#[wasm_bindgen]`: `start`. The
`start` attribute can be used to indicate that a function should be
executed when the module is loaded, configuring the `start` function of
the wasm executable. While this doesn't necessarily literally configure
the `start` section, it does its best!
Only one crate in a crate graph may indicate `#[wasm_bindgen(start)]`,
so it's not recommended to be used in libraries but only end-user
applications. Currently this still must be used with the `crate-type =
["cdylib"]` annotation in `Cargo.toml`.
The implementation here is somewhat tricky because of the circular
dependency between our generated JS and the wasm file that we emit. This
circular dependency makes running initialization routines (like the
`start` shim) particularly fraught with complications because one may
need to run before the other but bundlers may not necessarily respect
it. Workarounds have been implemented for various emission strategies,
for example calling the start function directly after exports are wired
up with `--no-modules` and otherwise working around what appears to be
a Webpack bug with initializers running in a different order than we'd
like. In any case, this in theory doesn't show up to the end user!
Closes#74
Some examples have been failing to load in some browsers, and this
ensures that whenever the promise to load Rust code fails we log any
errors happening instead of accidentally failing silently.
This helped debug a bit in #897
* Changed eslintrc to be JSON file (Most projects use JSON version)
* Added .eslintignore to ingore node_modules from subdirectories such as examples
* Ran eslint --fix examples to fix all examples
* Added npm script for running eslint against examples
* Added npm script for running eslint against generated *out* code
* Hooked npm scripts into travis ci to prevent examples from becoming inconsistent with future PR's
