* 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
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
The standard library version of an `RwLock` may get poisoned if a thread
panics that holds a write lock. The `RwLock` from parking_lot [1] does
not get poisoned it instead released the lock on a panic. This allows us
to simplify the `ProgressOutput` API since it no longer returns any
errors. No more panics can occur on `ProgressOutput::drop()`. The
`Error` enum can thus be simplified as well because there is no need to
convert `PoisonErrors` anymore.
[1] https://github.com/Amanieu/parking_lot
This will fix the broken spinners that indicate steps which are
currently in progress. To achieve this the behavior of the progressbar
helper had to be adjusted.
The multibar does not work while a child process is run with
`std::process::Command`. Using multiple spinners without a multibar is
problematic as well because emitting warnings, infos and errors while a
single spinner is active will duplicate the spinners message. The
spinner will also absorb the last warning/error/info. Instead of
publishing warnings, errors and infos immediately they will now be
cached and only output when the current spinner finishes.
To make sure we can output all warnings to the user ProgressBars are no
longer exposed to the caller. Instead the active spinner will be
finished implicitly when a new spinner is allocated with the `message()`
function. Instead of relying on the `done()` function to be called the
progressbar now implements the `Drop` trait which will finish the last
spinner automatically.
Unfortunately, this introduces members that have to be mutable. To not
have to deal with mutable ProgressOutput all over the place the members
were put inside an RwLock. This allows us to use ProgressOutput from
inside multiple threads to emit warnings and errors.
This does two big things:
- We add custom error messages and conversions from other error types
into our own error type. This means we can create or modify more
fine grained errors rather than using whatever `failure::Error` gives
us. The first one we have is a `Cli` error, whereby calls to things
like wasm-bindgen or npm failed.
- We also make it so that `PBAR.error()` is called only on exit. We grab
a reference to whatever error gets passed up the chain, have it
generate a message to be printed as an error to PBAR, close up PBAR
like normal, and then print our actual error message to stderr!
The main benefits of this is that as long as we return an error, PBAR
will print and close itself up and we don't need to call it every time
or forget that we would need to call it, and we put error details
specifically into our error!
Closes#12
This commit allows us to have a global progress bar to write data to
giving us the following benefits:
- Consistent ways to handle types of messages such as errors and
warnings
- Easy interface to add progress bars of various types
- Easy to maintain, add new types of bars, or more while encapsulating
the login in a single module
printfn