Avoid informational output that may become boilerplate

[alexcrichton]

💡 Feature description

One of the CLI designs of Cargo that I think has worked out well is that Cargo only emits messages on the console if something is likely to be "long running". The precise definition of what's long running changes over time, but it generally is "user perceptible" from what I've seen. For example Cargo will print out whenever it downloads something from the network or executes rustc, but it doesn't print out information about parsing Cargo.toml or looking for workspaces (which is generally quite fast).

It'd be nice if wasm-pack could suppress informational messages as well for steps that have already been completed or are known to complete very quickly. For example if the wasm32-unknown-unknown target is already installed the message about installing it doesn't need to be printed (as nothing slow is happening). Similarly moving files around and/or parsing manifests is pretty cheap, so that can probably be avoided too.

wasm-pack would certainly continue to print warnings unconditionally, though! I'm just thinking that in the case that the various steps are known to execute quickly an informational step isn't necessarily needed

[ashleygwilliams]

ah yeah- i've thought about this a bit as well. one of the reasons i enjoyed printing every step regardless of how long it took was because it helped inform the user of what was happening. i think your example of the target is a good one tho- i'd love to see a design for "deciding" what to show!

[alexcrichton]

FWIW the original design of Cargo would print "Fresh foo v0.0.1" for all crates you already had compiled locally, meaning you'd always see your dependencies either as "fresh" or "now it's recompiling". I was personally a bit dismayed when we started hiding "Fresh" by default, but nowadays I can't imagine Cargo going back to that again.

I personally like knowing what's going on under the hood in the tools I'm using, but in general I don't think new users mind too much. So long as they get an idea of what's going on for long-running steps (like installing a target, etc), they don't necessarily need to keep being reminded that it happened over time. From what I've seen tools like cargo build everyone just wants to either know (a) is it done yet or (b) why isn't it done yet, and so long as the current output always indicates that it most of the remaining output quickly becomes "noise that's overlooked"

[ashleygwilliams]

this is now being address by #298 - closing