* Renamed set_crate_path to get_crate_path
* If the path isn't specified in the call then use the current_dir and walk up the path try to find the manifest file.
* Specify the cwd for the build test so it doesn't walk up the path. The test needs to specify the path to build, otherwise because fixtures are run in a subdirectory of the source tree it will find the Cargo.toml from the wasm-pack source repository.
Change the return type of the child run commands so it can return a CommandError that also captures the stderr if the process fails.
See if the returned output contains the 'Unknown flag: --web' error message and if so provide an alternative error that suggests upgrading
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.
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.
* All messages are now printed onto stderr instead of some on stdout and
some on stderr
* All messages uniformly are prefixed with an emoji with consistent
spacing.
This commit moves wasm-pack further along the spectrum towards the 1.0
output previously discussed at the last work week. The changes here are:
* Steps which execute near instantaneously no longer print informational
messages by default.
* Long-running steps like downloading chromedriver/geckodriver now only
print if they actually perform a download.
* The "add wasm target" step now prints nothing if the wasm target is
already installed.
* Child process output is no longer captured and is redirected natively
to the terminal, granting colors from rustc/Cargo as well as Cargo's
progress bar during a build.
This commit is the first in what is hopefully a series to help move
`wasm-pack`'s CLI output and interactions to a "1.0 status". This was
[discussed at the recent Rust All Hands][discussion] where the salient
points we ended up extracting were:
* At all times if a user is waiting for `wasm-pack` to finish it should
be clear what's being waited on.
* As an example, Cargo's own output shows what crate is being built.
* As another example, something that always takes only a handful of
milliseconds to complete doesn't need an informational message.
* The final output products of a command should always be clear and
printed. For example the output location of artifacts should always be
printed.
* The `wasm-pack` CLI tool should use "progressive enhancement" to
incrementally detect features of the output it can use (like colors,
emoji, etc) but always work in the absence of these features. This'll
help us support a wide range of use cases and terminals.
The goal of this commit is to not get us all the way there but start us
down the path to satisfying these goals. To that end the major change
here is to remove the dependency on `indicatif`. Using `indicatif`
requires that all output is piped through the `indicatif` crate itself,
which causes the third item here to not work for one of the main parts
of `wasm-pack build`, the `cargo` pieces. Cargo (and the Rust compiler)
are unable to use thir own tools for progressive enhancement when the
output is captured and sent through `indicatif`.
Lots more refactoring will be needed internally to fully polish off the
input/output to a "1.0 status", but this is hopefully a good start!
[discussion]: https://gist.github.com/fitzgen/23a62ebbd67574b9f6f72e5ac8eaeb67#file-road-to-wasm-pack-1-0-md
First check if wasm32-unknown-unknown is present in rustc's
sysroot and if it is, then we're fine. Otherwise check if we're using
rustup and add the wasm32 target and if we're not using rustup, then
bail with an error stating that the wasm32 target couldn't be found.
This commit adds support for the new `--web` flag in `wasm-bindgen`
under the flag name `--target web`. To ensure that it was plubmed around
the stringly-typed `target` type was switched to an `enum Target` to
ensure that all cases it's looked at are handled appropriately for the
new `web` target.
Ashley Williams