* 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
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.
In 'license' field of package.json, it's ok to say 'license is written in
some file' as follows:
```
{ "license" : "SEE LICENSE IN <filename>" }
```
This notation is useful when 'license' field is missing in `Cargo.toml`
but `license-file` field is provided.
Ref:
https://docs.npmjs.com/files/package.json#license
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
Issue #277 - Affects running login, pack, and publish on Windows.
`Command::new("npm")` launched `npm` with quotes, `"npm"`, causing a
run-time error on Windows. Now, `Command::new` is wrapped by
`child::new_command(program: &str)`. This prepends `cmd /c` to the
program name if `cfg!(windows)`.
See rustc: #42436, #42791, #44542
`child::run` overrides the stdout config, so is misleading to to set it
differently beforehand. `child::run` uses `spawn()`, which inherits
stdin by default. So, no need to set stdin to default beforehand,
particularly when the spawned program is non-interactive.
All arguments were passed to `arg` inside one string when building a
`Command`. However, using the `arg` function, "only one argument can be
passed per use." This caused all arguments accidentally to be appended
to the registry URL. For example: After a successful login with a
provided `--auth_type`, the success message incorrectly displayed:
"Logged in as asf on https://registry.npmjs.org/%20--auth_type=Basic."
The space (%20 in hex) was caused by adding a fixed space before each
additional argument.
This commit pushes all arguments onto a `Vec<String>`. Then, the `args`
function adds the arguments separately to the command. This removes the
need to prepend spaces to each argument. Alternatively, `arg` could have
been used throughout to build the command argument-by-argument. However,
using `args` partitions the code more neatly into two distinct sections.
Issue #484.
PR392 inadvertantly replaced the `login` interactive process spawner
with
`child::run`, which is hard-coded to buffer stdout/stderr. This caused
`login` to become essentially unusable; the user could no longer see
interactive input prompts or error messages displayed by `npm adduser`.
The code was not directly reverted because the previous version:
1. Returned Error instead of failure::Error. (Updated to use
`bail!`, which is consistent with `publish`.)
2. Displayed all stderr only upon exit, rather than interactively
displaying it. This led to repeated interactive prompts without
informing the user why. (Updated to use `status()` which inherits
stdin/stdout/stderr by default.)
3. Did not provide logging. (Now duplicates the logging in
`child::run`.)
Alex Crichton