Migrate output towards the 1.0 strategy

[alexcrichton]

fixes #520 #419

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 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!

[fitzgen]

Nice! Thanks for getting us started down the road towards the ideal output we agreed upon :)

[ashleygwilliams]

looks like we have tests failing here, 1 because of a wasm-bindgen test and 1 because cargo fmt isn't able to be downloaded

[alexcrichton]

@ashleygwilliams that should be easy enough to fix up, do you have comments on the PR contents?

[alexcrichton]

Still waiting on AppVeyor, but Travis should be green now

[ashleygwilliams]

could you supply a gif of the how the new output appears? this is not only for ease of review but also because we'll need to replace the demo.gif in the readme if this makes significant changes to the output (which i believe it does?) let me know if you need help doing it! i can also pull down this branch and add it myself if you prefer (i have asciinema all set up so it would not be too difficult). if we can get this done by end of day i could probably get this into the 0.7.0 release.

[alexcrichton]

To be clear, I'd prefer that more changes were landed in succession after this to ensure that the motivation for this change is fully realized. For example this doesn't yet being to take advantage of compiler colors. Each aspect of the current UI will need a separate refactoring and will take some time to move towards this "1.0 status".

I'm hesitant to add too much to one PR though because it ends up not working out well historically. Additionally the pace here is somewhat slow which means it's difficult to iterate quickly and land incremental changes.

All that to say that the current output, which looks like the gif below, is not something I'd want to release. This is one incremental step and I would ideally like to move much more quickly on the future incremental steps.

[alexcrichton]

In the interest of time I've gone ahead and implemented a number of other changes moving us to where I believe is almost where we want to end up modulo final tweaks. The output now looks like this:

[ashleygwilliams]

one thing i'm noting about the newest demo.gif is that there are no "header sections". by this i mean, that if there is a long running task that dumps to stdout, it should have a header- e.g. cargo build - so i would expect to see a message above "updating crates.io" that says something to the effect of "compiling wasm..."

[alexcrichton]

That's correct yes, but that's intentional.

If cargo blocks you know what Cargo is doing, and otherwise wasm-pack doesn't need to print out what it's doing before each step because it's redundant.

[ashleygwilliams]

hey @alexcrichton ! finally got to pull this locally and i think for the most part it's great, i have a few nits. if you can get to them today that's awesome, but we could potentially land this and fix nits for the next release since i think it is really close.

this is the output i got for build:

i think the difference between the ℹ️ logs that show a step and the ones that show ℹ️ [INFO] are a little weird. perhaps we can have them all say [INFO] ? there's something there that feels a little weird to me, but i'm super open to suggestions. what do you thin?

[ashleygwilliams]

also i am extremely ok fixing this in a separate PR but the pack command looks like this:

i would expect a ℹ️ emoj on the success message but it's bare. perhaps we can just have the success messages and step messages not have the ℹ️ ? it might be simplest and i think it'd look less cluttered

[ashleygwilliams]

happy to merge this and do the emoji tweaks in a separate PR, lemme know!

[ashleygwilliams]

per chat, @alexcrichton is working on some updates and will post more soon!

[alexcrichton]

@ashleygwilliams ok I believe I've applied your suggestions, and I don't have too many thoughts about the particulars of the output, so I'm down for w/e you feel looks good. For perfect output we may want to take a fresh look at the output again after the next release as it feels a little inconsistent right now (e.g. hasn't caught up with all the features added over time), but that's all future work for later

[ashleygwilliams]

strong agree! i'll merge when green. thanks for the hard work!!