binary-install has been moved to it's own repository: https://github.com/rustwasm/binary-install.
This means that wasm-pack shouldn't have it in it's repository as well.
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
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 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.
This commit kicks off the addition of installers for wasm-pack, with the main
goals of being:
* Users should have a one-click (ideally) solution to download and install
wasm-pack.
* We should ideally not have to worry about picking up "heavy" dependencies in
wasm-pack like C++ or C code (if necessary).
The general idea here is very similar to rustup (and in fact a good deal of code
is copied from them!). The installation worklow for wasm-pack in theory after
this commit looks like:
1. First, a users visits the installer landing page. A preview is available at
https://alexcrichton.github.io/wasm-pack/installer/. Clearly this page needs
a better stylesheet!
2. The user performs the instructions presented on the page. The website
automatically detects what platform you're running on, basically giving you a
curl/sh script or a Windows installer. There's various options for seeing
other installers as well, and the fallback of `cargo install` is presented if
we don't recognize the platform (or if we don't think we have precompiled
binaries).
3a. On Unix, users execute a curl/sh script like:
```
curl https://alexcrichton.github.io/wasm-pack/installer/init.sh -sSf | sh
```
This command will download the shell script included in this PR, which will
in turn do some further platform detection (like OSX vs Linux) and then
download the most recent version of `wasm-pack` from GitHub releases. This
is then extracted, the `wasm-pack` binary is renamed to `wasm-pack-init`,
and then that binary is run. The binary will refuse by default to overwrite
a previous installation, but that can be overridden with the `-f` flag.
3b. On Windows users download a binary. This binary, when run, will pop up a
console window. This window will have the same output as the shell script
installer, and will wait at the end of its execution to ensure the user has
time to read everything.
And... that's it! The deployment process for all this looks like so:
* All CI builds will update the website and shell script (published to
gh-pages). A small script at `docs/installer/build-installer.rs` fills in the
current version number inferred from `Cargo.toml`.
* Tagged CI builds will publish releases, as usual.
* "Pushing a release" is done by bumping the version number in `Cargo.toml`.
When bumped all online installers will now point to the new release. There
will be a window of time, though, when the version number is bumped and the
release hasn't finished building on CI. In this case users will get errors
(unfortunately).
This is all still a work-in-progress and feedback is definitely appreicated and
welcome on all this!
If a test is going to do a potentially destructive operation, instead of
mutating shared fixtures, it should copy the fixture to its own unique directory
and then mutate that copy (doesn't this sound like Rust's borrowing and
ownership rules?! ^.^)
Jesper Håkansson