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
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.
Also introduces testing of our CLI's output via `assert_cmd`. Expect some follow
ups to get more of our testing infrastructure using this incredible crate!
Fixes#511
This commit replaces the `slog` family of crates used by `wasm-pack`
with the `log` crate plus `env_logger`. This also means that by default
`wasm-pack` also won't create a `wasm-pack.log` file in the current
directory. Enabling logging will now be done through
`RUST_LOG=wasm_pack` instead of `-v` flags.
Closes#425
This commit removes the internal `Error` type in favor of exclusively
using the `failure::Error` type, simplifying error construction in a
number of locations and reducing the number of error types in play.
This commit fixes an issue where if a library is renamed via the `name`
key in the `[lib]` section of the manifest then `wasm-pack` would try to
generate bindings for an noexistent wasm-file, generating an error.
The fix was to internally use `cargo_metadata` more aggressively and
move around where this data is generated. This ended up refactoring a
few locations, but this should also bring improved error messages for
`cargo metadata` as well as caching the resulting data more aggressively
to avoid recalculating it too much.
Closes#339
This commit switches wasm-pack to using a global cache for all download
binaries, living typically in a user's home directory. The intention
here is to aovid creating a `bin` folder in all wasm-pack projects and
additionally share downloads between projects to ensure that you're
downloading a minimal number of binaries from the network.
Along the way the downloading code was restructured to support a global
cache, but everything should largely be as it was before!
Closes#292
This lets us leverage `cargo` for semver finding and then ensure that we get the
exact same version of the CLI that cargo selected. It also lets us support fuzzy
dependencies like "0.2" instead of exact dependencies like "0.2.21" again.
Alex Crichton