This commit adds support for automatically executing the `wasm-opt`
binary from the [Binaryen project][binaryen]. By default `wasm-pack`
will now, in release and profiling modes, execute `wasm-opt -O` over the
final binary. The goal here is to enable optimizations that further
reduce binary size or improve runtime. In the long run it's expected
that `wasm-opt`'s optimizations may mostly make their way into LLVM, but
it's empirically true today that `wasm-opt` plus LLVM is the best
combination for size and speed today.
A configuration section for `wasm-opt` has been added as [previously
proposed][fitzgen], namely:
```toml
[package.metadata.wasm-pack.profile.release]
wasm-opt = ['-Os']
```
The `wasm-opt` binary is downloaded from Binaryen's [own
releases](https://github.com/webassembly/binaryen/releases). They're
available for the same platforms that we download predownloaded binaries
for `wasm-bindgen` on. We'll also opportunistically use `wasm-opt` in
`PATH` if it's available. If we're untable to run `wasm-opt`, though, a
warning diagnostic is printed informing such.
Closes#159
[binaryen]: https://github.com/webassembly/binaryen
[fitzgen]: https://github.com/rustwasm/wasm-pack/issues/159#issuecomment-454888890
As mentioned in #409, some comments mentioned to use `?`
over calling `.unwrap()` and to use a struct
instead of two Strings. This PR leverages `?` and a new struct called
`WasmPackVersion` with a `local` and `latest` field. This PR also
uses `PBAR.warn(warning_msg)` instead of `println!(warning_msg)`
to print the warning message.
When checking for wasm32 target we did check if the sysroot
contained ".rustup". While this covered the most common cases it didn't
work when using Docker. So checking for "rustup" instead covers both
cases.
binary-install has been moved to it's own repository: https://github.com/rustwasm/binary-install.
This means that wasm-pack shouldn't have it in it's repository as well.
This commit fixes the `wasm-pack build --mode no-install` command from
unconditionally panicking as well as `--mode force`. These steps were
calling an `unwrap()` on an internal `Option<T>` which was supposed to
be set during `step_install_wasm_bindgen`, but that step wasn't run in
these modes. The mode configuration of steps has been refactored
slightly to ensure that more steps are shared between these modes to
reduce duplication.
Alex Crichton