We've always wanted this to be the deterministic, but usage of `HashMap`
for example can accidentally lead to non-determinism. Looks like one was
forgotten and the bindings were nondeterministic by accident as a
result!
This commit deprecates the `--web`, `--no-modules`, and `--nodejs` flags
in favor of one `--target` flag. The motivation for this commit is to be
consistent between `wasm-bindgen` and `wasm-pack` so documentation for
one is applicable for the other (so we don't have to document everywhere
what the translation is between flags). Additionally this should make it
a bit easier to add new targets (if necessary) in the future as it won't
add to the proliferation of flags.
For now the old flags (like `--web`) continue to be accepted, but
they'll be removed during the next set of breaking changes for
`wasm-bindgen`.
* Note that after the game of life tutorial there's also wasm-pack tutorials
* Ensure that the hello world example is clear that webpack isn't
required inline in addition to the text on other pages.
This commit moves our `links` annotation in the `wasm-bindgen` crate to
the `wasm-bindgen-shared` crate. The `links` annotation is used to
ensure that there's only one version of `wasm-bindgen` in a crate graph
because if there are multiple versions then a CLI surely cannot actually
process the wasm binary (as the multiple versions likely have different
formats in their custom sections).
Discovered in #1373 it looks like the usage in `wasm-bindgen` isn't
quite sufficient to cause this deduplication. It turns out that
`wasm-bindgen-shared`, a very core dependency, is actually the most
critical to be deduplicated since its the one that defines the format of
the custom section. In #1373 a case came up where `wasm-bindgen` was
deduplciated but there were two versions of `wasm-bindgen-shared` in the
crate graph, meaning that a `[patch]` for only `wasm-bindgen` wasn't
sufficient, but rather `web-sys` and/or `js-sys` also needed a `[patch]`
annotation to ensure everyone used the right dependencies.
This commit won't actually fix#1373 to the point where it "just works",
but what it does do is present a better error message than an internal
panic of `wasm-bindgen`. The hope is that by moving the `links`
annotation we can catch more errors of this crate graph duplication,
leading to more `[patch]` annotations locally.
Closes#1373
Trying to use a proc macro from a 2018 edition crate in a 2018 edition crate that reexports wasm bindgen's output failed before this commit with "could not find `wasm_bindgen` in `{{root}}`".
This commit was made with
rg " ::wasm_bindgen::" --files-with-matches | xargs sed -i 's/::wasm_bindgen::/wasm_bindgen::/g'
This allows subverting the checks and resolution performed by the
`module` attribute added as part of [RFC 6] and has been discussed in #1343.
Closes#1343
[RFC 6]: https://github.com/rustwasm/rfcs/pull/6
This commit works around Geal/nom#843 where the API of the `nom` crate
changes based on feature selection, meaning we need to be compatible
even if another crate in the crate graph enables a feature.
Ideally this'd be fixed in upstream `nom`, and it looks like it will in
the next major version! For now a local catch-all directive should help
out.
