idea: "Installers" for wasm-pack

[alexcrichton]

Currently one of the main installations methods for wasm-pack is cargo install, and this has a few great benefits to it:

• Users don't have to know what platform they're running on, they just need cargo which is already pretty easy to install.
• Users don't need to set up PATH to get wasm-pack-the-subcommand because Cargo already takes care of those warnings.
• It's a pretty seamless experience where everything is downloaded for you.

The downsides, however, of cargo install are:

• Compilation of Rust code isn't always speedy, so it can take some time. Furthermore as wasm-pack continues to grow in functionality it'll pick up dependencies and slow down to compile.
• Over time wasm-pack may pick up hard-to-compile dependencies. For example it recently picked up curl as a crate, but that needs to compile C code and deals with linkage of C libraries and such. That can often trip up a lot of newcomers who don't always have pristinely configured environments.

I think, though, that we may be able to solve these downsides while still preserving the benefits of cargo install today. We could employ a rustup-like solution to install wasm-pack but leave automatic updates for a future iteration. We've already got precompiled binaries (that are "quite compatible") for wasm-pack, so we just need a better way to get them to users.

I'm imagining something like:

• There's a site like https://rustup.rs/ (hosted on gh-pages most likely) which users visit to install wasm-pack. This website does platform detection to tell users what installer to install.
• On Unix we'd provide a curl | sh solution with a shell script in this repository (similar to rustup.sh). I don't think this'd be too hard to implement, as it'd largely just download a tarball from github (the precompiled release) and then extract the wasm-pack binary into $HOME/.cargo/bin.
• On Windows we'd provide wasm-pack-init.exe (or something like that), which could actually simply be wasm-pack.exe itself. When run for the first time wasm-pack.exe would move itself into .cargo/bin as well, which should already be in PATH.

Overall this would free us from the above two downsides (long build times and sometimes complicated native dependencies) while also keeping wasm-pack as easy to install as it is today. One perhaps snag in this plan is that updates are a bit easier with Cargo ("run this command" vs "visit this website"), but updates with cargo install already aren't that great so it's perhaps not that bad!

[alexcrichton]

FWIW this came up when @fitzgen and I were talking today about the possibility of linking wasm-pack with binaryen directly, but requiring all users to have a C++ compiler (especially new users) can make for a bad first impression pretty easily unfortunately