Smorgasboard of doc improvements

* Add deep dive documentation for `tests/web.rs` of the `wasm-pack-template`
* Add docs for testing a project in addition to building
* Touch up other documentation int he deep dive and setup
* Fix a few dead links and moved pages and such

docs/src/SUMMARY.md

@@ -3,25 +3,25 @@
 - [Prerequisites](./prerequisites/index.md)
   - [npm (optional)](./prerequisites/npm.md)
 - [Commands](./commands/index.md)
-  - [`init` (DEPRECATED)](./commands/init.md)
   - [`build`](./commands/build.md)
   - [`test`](./commands/test.md)
   - [`pack` and `publish`](./commands/pack-and-publish.md)
+  - [`init` (DEPRECATED)](./commands/init.md)
 - [Tutorials](./tutorials/index.md)
   - [Hybrid applications with Webpack](./tutorials/hybrid-applications-with-webpack/index.md)
     - [Getting started](./tutorials/hybrid-applications-with-webpack/getting-started.md)
     - [Using your library](./tutorials/hybrid-applications-with-webpack/using-your-library.md)
   - [npm browser packages](./tutorials/npm-browser-packages/index.md)
     - [Getting started](./tutorials/npm-browser-packages/getting-started.md)
-      - [Project setup](./tutorials/npm-browser-packages/project-setup/index.md)
-        - [Using a Template](./tutorials/npm-browser-packages/project-setup/using-a-template.md)
-        - [Manual Setup](./tutorials/npm-browser-packages/project-setup/manual-setup.md)
+      - [Manual Setup](./tutorials/npm-browser-packages/getting-started/manual-setup.md)
     - [Template deep dive](./tutorials/npm-browser-packages/template-deep-dive/index.md)
       - [`Cargo.toml`](./tutorials/npm-browser-packages/template-deep-dive/cargo-toml.md)
       - [`src/lib.rs`](./tutorials/npm-browser-packages/template-deep-dive/src-lib-rs.md)
       - [`src/utils.rs`](./tutorials/npm-browser-packages/template-deep-dive/src-utils-rs.md)
       - [`wee_alloc`](./tutorials/npm-browser-packages/template-deep-dive/wee_alloc.md)
-    - [Building your project](./tutorials/npm-browser-packages/template-deep-dive/building-your-project.md)
+      - [`tests/web.rs`](./tutorials/npm-browser-packages/template-deep-dive/tests-web-rs.md)
+    - [Building your project](./tutorials/npm-browser-packages/building-your-project.md)
+    - [Testing your project](./tutorials/npm-browser-packages/testing-your-project.md)
     - [Packaging and publishing](./tutorials/npm-browser-packages/packaging-and-publishing.md)
     - [Using your library](./tutorials/npm-browser-packages/using-your-library.md)
 - [`Cargo.toml` Configuration](./cargo-toml-configuration.md)

docs/src/prerequisites/index.md

@@ -10,10 +10,10 @@ Next, since `wasm-pack` is a build tool, you'll want to make sure you have
 
 [rust]: https://www.rust-lang.org/tools/install
 
-Finally, if you're using `wasm-pack` to install to publish to NPM, you'll want
+Finally, if you're using `wasm-pack` to publish to NPM, you'll want
 to [install and configure `npm`][npm]. In the future, we intend to rewrite the
 npm registry client bits so that the need for a Node runtime is eliminated. If
 you're excited about that work- you should reach out to the maintainers and get
 involved!
 
-[npm]: npm.html
+[npm]: prerequisites/npm.html

docs/src/tutorials/npm-browser-packages/building-your-package.md

@@ -1,24 +0,0 @@
-# Building your package
-
-We've written our code so now we need to package it all up.
-
-We are writing a package that should be used in the browser, so we run this in our terminal:
-
-```bash
-$ wasm-pack build --scope MYSCOPE
-```
-
-If you were writing a package that should be used in Node.js (with CommonJS modules, e.g. `require`),
-you would run this in your terminal:
-
-```bash
-$ wasm-pack build --scope MYSCOPE --target nodejs
-```
-
-where `MYSCOPE` is your npm username. Normally you could just type `wasm-pack init` but since
-other people are doing this tutorial as well we don't want conflicts with the `wasm-add` package
-name! This command when run does a few things:
-
-1. It'll compile your code to wasm if you haven't already
-2. It'll generate a pkg folder with the wasm file, a JS wrapper file around the wasm, your README,
-   and a `package.json` file.

docs/src/tutorials/npm-browser-packages/building-your-project.md

@@ -0,0 +1,23 @@
+# Building your project
+
+We've written our code so now we need to build it.
+
+We are writing a crate that should be used in the browser, so we run this in
+our terminal:
+
+```bash
+$ wasm-pack build
+```
+
+If you were writing a package that should be used in Node.js (with CommonJS
+modules, e.g. `require`), you would run this in your terminal:
+
+```bash
+$ wasm-pack build --target nodejs
+```
+
+This command when run does a few things:
+
+1. It'll compile your code to wasm if you haven't already
+2. It'll generate a `pkg` folder with the wasm file, a JS wrapper file around
+   the wasm, your README, and a `package.json` file.

docs/src/tutorials/npm-browser-packages/getting-started.md

@@ -25,4 +25,4 @@ further in this guide.
 ⚠️ If you'd rather not use a template, or are having trouble with the template, you can
 do a manual setup by following [these instructions].
 
-[these instructions]: ../project-setup/manual-setup.html
+[these instructions]: ./getting-started/manual-setup.html

docs/src/tutorials/npm-browser-packages/getting-started/manual-setup.md

@@ -1,9 +1,9 @@
 # Manual Setup
 
 ⚠️ This is not the recommended way to start a `wasm-pack` project! If you ended up
-here by mistake, go check out our recommended project start, [Using A Template].
+here by mistake, go check out our [recommended project start][template].
 
-[Using A Template]: using-a-template.md
+[template]: ../getting-started.html
 
 ### Step 1: Create a New Rust Library Project
 
@@ -25,7 +25,7 @@ section. `wasm-bindgen` is a tool that facilitates interoperability between
 wasm modules and JavaScript.
 
 ⚠️ If you are coming from JavaScript, you might note that when we add the dependency
-there is no `^` or `~` symbol- it looks like we're locking to the `0.2` version. 
+there is no `^` or `~` symbol- it looks like we're locking to the `0.2` version.
 However, that's not the case! In Rust, the `^` is implied.
 
 #### Add `crate-type`

docs/src/tutorials/npm-browser-packages/project-setup/index.md

@@ -1,10 +0,0 @@
-# Project Setup
-
-In this section, how to setup a `wasm-pack` project.
-
-There are a few things you need to do to setup a project for `wasm-pack`.
-We strongly recommending [using a template], but you can also set the project
-up [manually].
-
-[using a template]: ./using-a-template.html
-[manually]: ./manual-setup.html

docs/src/tutorials/npm-browser-packages/project-setup/using-a-template.md

@@ -1,21 +0,0 @@
-# Using a Template
-
-You can create a new Rust-WebAssembly project by using the [rustwasm wasm-pack-template].
-
-To so do, you'll need the `cargo-generate` tool. To install `cargo-generate`:
-
-```
-cargo install cargo-generate
-```
-
-Then run:
-
-```
-cargo generate --git https://github.com/rustwasm/wasm-pack-template
-```
-
-You will be prompted to give your project a name. Once you do, you will have a directory
-with a new project, ready to go. We'll talk about what's been included in this template
-further in this guide.
-
-[rustwasm wasm-pack-template]: https://github.com/rustwasm/wasm-pack-template

docs/src/tutorials/npm-browser-packages/template-deep-dive.md

@@ -1 +0,0 @@
-# Template Deep Dive

docs/src/tutorials/npm-browser-packages/template-deep-dive/cargo-toml.md

@@ -23,20 +23,21 @@ crate-type = ["cdylib", "rlib"]
 A Rust-`wasm` crate is a bit different from a normal crate, and as a result, we need to note
 this in our `Cargo.toml`.
 
-When `cargo` is told to build a project, or compilation is otherwise done on a Rust project,
-the Rust compiler will need to link crates together, using a particular method, either
-staticly or dynamically. The two types of crate that you are likely most familiar with are
-`#[crate_type = "bin"]` and `#[crate_type = "lib"]`, which are the crate types that largely
-represent the difference between Rust application projects and Rust libraries.
-
-`#[crate_type = "cdylib"]` signifies that you'd like the compiler to create a dynamic system
-library. This type of library is suited for situations where you'd like to compile Rust code
-as a dynamic library to be loaded from another language. In our case, we'll be compiling to a
-`.wasm` file, but this output type will create `*.so` files on Linux, `*.dylib` files on
-macOS, and `*.dll` files on Windows in non-`wasm` circumstances.
-
-`#[crate_type = "rlib"]` signifies that an intermediate "Rust library" file will be produced. 
-This allows tests to use the main crate.
+This `[lib]` annotation is typically not needed in Cargo projects, and if you're
+familiar with other Rust crates you'll remember that the most common crate types
+are `rlib` (the default) or `bin` for binaries (which don't need a `crate-type`
+annotation).
+
+Here though `crate-type = ["cdylib"]` typically signifies that you'd like the
+compiler to create a dynamic system library, but for WebAssembly target it
+simply means "create a `*.wasm` file without a `start` function". On other
+platforms this output type will create `*.so` file on Linux, `*.dylib` on
+macOS, and `*.dll` Windows.
+
+We also specify `crate-type = ["rlib"]` to ensure that our library can be unit
+tested with `wasm-pack test` (which we'll see later). Without this we wouldn't
+be able to test our library because the `cdylib` crate type is incompatible with
+`wasm-pack`'s style of unit tests.
 
 You can read more about linking and crate types, [here](https://doc.rust-lang.org/reference/linkage.html).
 
@@ -56,7 +57,7 @@ wasm-bindgen = "0.2"
 We'll see more about how to use this library when we discuss what has been generated in `lib.rs`.
 
 ⚠️ If you are coming from JavaScript, you might note that when we add the dependency
-there is no `^` or `~` symbol- it looks like we're locking to the `0.2` version. 
+there is no `^` or `~` symbol- it looks like we're locking to the `0.2` version.
 However, that's not the case! In Rust, the `^` is implied. You can read more about this in the
 [cargo documentation on specifying dependencies].
 
@@ -64,13 +65,14 @@ However, that's not the case! In Rust, the `^` is implied. You can read more abo
 
 ## 3. `[features]` and [`wee_alloc`], [`console_error_panic_hook`] dependencies
 
-[`wee_alloc`]: https://github.com/rustwasm/wee_alloc
-[`console_error_panic_hook`]: https://github.com/rustwasm/console_error_panic_hook
+[`wee_alloc`]: https://crates.io/crates/wee_alloc
+[`console_error_panic_hook`]: https://crates.io/crates/console_error_panic_hook
+[`cfg-if`]: https://crates.io/crates/cfg-if
 
 As part of our effort to design a template that helps people discover useful crates
 for their particular use case, this template includes two dependencies that can be
-very useful for folks developing Rust-`wasm` crates: `console-error-panic-hook` and
-`wee-alloc`.
+very useful for folks developing Rust-`wasm` crates:[ `console_error_panic_hook`] and
+[`wee_alloc`].
 
 Because these dependencies are useful primarily in a specific portion of the Rust-`wasm`
 crate development workflow, we've also set up a bit of glue code that allows us to include
@@ -99,13 +101,13 @@ wee_alloc = { version = "0.4.2", optional = true }
 ```
 
 [`cfg-if`] allows us to check if certain features are enabled on a Rust crate. We'll
-use this crate later to optionally enable `console_error_panic_hook` or
+use this crate later to optionally enable [`console_error_panic_hook` or
 `wee_alloc`.
 
 By default, only `console_error_panic_hook` is enabled. To disable either
 feature, we can remove its name from the `default` vector.
 
-To learn more about these features, we discuss them in-depth in the [`src/lib.rs`] and 
+To learn more about these features, we discuss them in-depth in the [`src/lib.rs`] and
 [`src/utils.rs`] sections.
 
 [`src/lib.rs`]: src-lib-rs.html

docs/src/tutorials/npm-browser-packages/template-deep-dive/index.md

@@ -9,8 +9,10 @@ may look slightly different than what is described here.
 
 ### What the Template Gave Us
 
-Let's start by taking a look at what the template generated for us. 
+Let's start by taking a look at what the template generated for us.
 
-- [`Cargo.toml`](./cargo-toml.html)
-- [`src/lib.rs`](./src-lib-rs.html)
-- [`src/utils.rs`](./src-utils-rs.html)
+- [`Cargo.toml` - the Cargo manifest](./cargo-toml.html)
+- [`src/lib.rs` - main library module](./src-lib-rs.html)
+- [`src/utils.rs` - a utility module](./src-utils-rs.html)
+- [`wee_alloc` - a tiny memory allocator](./wee_alloc.html)
+- [`tests/web.rs` - running headless browser tests](./tests-web-rs.html)

docs/src/tutorials/npm-browser-packages/template-deep-dive/src-lib-rs.md

@@ -46,7 +46,7 @@ This is all you need to know to interface with JavaScript, at least to start! Yo
 
 If you are curious about the rest, read on.
 
-## 2. Crate imports
+## 2. Crate Organization
 
 ```rust
 mod utils;
@@ -74,7 +74,6 @@ With this in mind, this `use` allows us to call the macro `cfg_if!` inside the c
 ```rust
 cfg_if! {
     if #[cfg(feature = "wee_alloc")] {
-        extern crate wee_alloc;
         #[global_allocator]
         static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;
     }
@@ -83,7 +82,11 @@ cfg_if! {
 
 We immediately notice that `cfg_if!` is a macro because it ends in `!`, similarly to other Rust macros such as `println!` and `vec!`. A macro is directly replaced by other code during compile time.
 
-During compile time, `cfg_if!` evaluates the `if` statement. This tests whether the feature `wee_alloc` is present in the `[features]` section of `Cargo.toml` (among other possible ways to set it).
+At compile time this will test if the `wee_alloc` feature is enabled for this
+compilation. If it's enabled we'll configure a global allocator (according to
+[`wee_alloc`'s docs][wee-alloc-docs]), otherwise it'll compile to nothing.
+
+[wee-alloc-docs]: https://docs.rs/wee_alloc/0.4.3/wee_alloc/
 
 As we saw earlier, the `default` vector in `[features]` only contains `"console_error_panic_hook"` and not `"wee_alloc"`. So, in this case, the `cfg_if!` block will be replaced by no code at all, and hence the default memory allocator will be used instead of `wee_alloc`.
 
@@ -91,7 +94,10 @@ As we saw earlier, the `default` vector in `[features]` only contains `"console_
 use wasm_bindgen::prelude::*;
 ```
 
-Many modules contain a prelude, a list of things that should be automatically imported. This allows common features of the module to be conveniently accessed without a lengthy prefix. For example, in this file we can use `#[wasm_bindgen]` only because it is brought into scope by the prelude.
+Many crates contain a prelude, a list of things that are convenient to import
+all at once. This allows common features of the module to be conveniently
+accessed without a lengthy prefix. For example, in this file we can use
+`#[wasm_bindgen]` only because it is brought into scope by the prelude.
 
 The asterisk at the end of this `use` indicates that everything inside the module `wasm_bindgen::prelude` (i.e. the module `prelude` inside the crate `wasm_bindgen`) can be referred to without prefixing it with `wasm_bindgen::prelude`.
 

docs/src/tutorials/npm-browser-packages/template-deep-dive/src-utils-rs.md

@@ -22,7 +22,6 @@ This allows us to write `cfg_if!` instead of `cfg_if::cfg_if!`, identically to t
 ```rust
 cfg_if! {
     if #[cfg(feature = "console_error_panic_hook")] {
-        extern crate console_error_panic_hook;
         pub use self::console_error_panic_hook::set_once as set_panic_hook;
     } else {
         #[inline]
@@ -31,36 +30,52 @@ cfg_if! {
 }
 ```
 
-As described in the preceding section, the macro `cfg_if!` evaluates the `if` statement during compile time. This is possible because it is essentially testing whether `"console_error_panic_hook"` is defined in the `[features]` section of `Cargo.toml`, which is available during compile time.
-
-The entire macro block will either be replaced with the statements in the `if` block or with those in the `else` block. These two cases are now described in turn:
+As described in the preceding section, this invocation of the `cfg_if!`
+tests whether the `console_error_panic_hook` feature is enabled at compile time,
+replacing with the statements in the `if` block or with those in the `else`
+block. These two cases are:
 
 ```rust
-extern crate console_error_panic_hook;
 pub use self::console_error_panic_hook::set_once as set_panic_hook;
 ```
 
-Due to the `use` statement, the function `self::console_error_panic_hook::set_once` can now be accessed more conveniently as `set_panic_hook`. Due to `pub`, this function will be publicly accessible outside of the `utils` module as `utils::set_panic_hook`.
+This `use` statement means the function
+`self::console_error_panic_hook::set_once` can now be accessed more conveniently
+as `set_panic_hook`. With `pub`, this function will be accessible
+outside of the `utils` module as `utils::set_panic_hook`.
 
 ```rust
 #[inline]
 pub fn set_panic_hook() {}
 ```
 
-An inline function replaces the function call with the contents of the function during compile time. Here, `set_panic_hook` is defined to be an empty inline function. This allows the use of `set_panic_hook` without any run-time or code-size performance penalty if the feature is not enabled.
+Here, `set_panic_hook` is defined to be an empty inline function. The inline
+annotation here means that whenever the function is called the function call is
+replaced with the body of the function, which is for `set_panic_hook` nothing!
+This allows the use of `set_panic_hook` without any run-time or code-size
+performance penalty if the feature is not enabled.
 
 ## 2. What is `console_error_panic_hook`?
 
-The crate `console_error_panic_hook` enhances error messages in the web browser. This allows you to easily debug WebAssembly code.
+The [crate `console_error_panic_hook`][ceph] allows debugging Rust panic
+messages in a web browser, making it much easier to debug WebAssembly code.
 
-Let's compare error messages before and after enabling the feature:
+Let's compare what happens when Rust code panics before and after enabling the
+feature:
 
 **Before:** `"RuntimeError: Unreachable executed"`
 
 **After:** `"panicked at 'index out of bounds: the len is 3 but the index is 4', libcore/slice/mod.rs:2046:10"`
 
-To do this, a panic hook for WebAssembly is provided that logs panics to the developer console via the JavaScript `console.error` function. 
+To do this, a [panic hook] is configured that logs panics to the
+developer console via the JavaScript `console.error` function.
+
+Note though that `console_error_panic_hook` is not entirely automatic, so you'll
+need to make sure that `utils::set_panic_hook()` is called before any of our
+code runs (and it's safe to run `set_panic_hook` many times).
 
-Note that although the template sets up the function, your error messages will not automatically be enhanced. To enable the enhanced errors, call the function `utils::set_panic_hook()` in `lib.rs` when your code first runs. The function may be called multiple times if needed.
+For more details, see the [`console_error_panic_hook`
+repository](https://github.com/rustwasm/console_error_panic_hook).
 
-For more details, see the [`console_error_panic_hook` repository](https://github.com/rustwasm/console_error_panic_hook).
+[ceph]: https://crates.io/crates/console_error_panic_hook
+[panic hook]: https://doc.rust-lang.org/std/panic/fn.set_hook.html

docs/src/tutorials/npm-browser-packages/template-deep-dive/tests-web-rs.md

@@ -0,0 +1,74 @@
+# tests/web.rs
+
+`web.rs` is an integration test [defined with Cargo][cargo-tests] that is
+intended to be run in a headless web browser via the `wasm-pack test` command.
+
+[cargo-tests]: https://doc.rust-lang.org/cargo/guide/tests.html
+
+It contains three key parts:
+
+1. [`#[wasm_bindgen_test] functions`](#a1-wasm_bindgen_test-functions)
+2. [Crate Configuration](#a2-crate-configuration)
+3. [`#![cfg]` directives](#a3-cfg-directives)
+
+---
+
+## 1. `#[wasm_bindgen_test]` functions
+
+The `#[wasm_bindgen_test]` is like the [normal Rust `#[test]`
+attribute][rust-test], except it defines a test accessible to WebAssembly and
+headless web browser testing.
+
+> **Note**: Eventually `#[test]` will work with WebAssembly as well! Currently
+> though [custom test frameworks][ctf] are not stable.
+
+[rust-test]: https://doc.rust-lang.org/book/ch11-01-writing-tests.html
+[ctf]: https://github.com/rust-lang/rust/issues/50297
+
+```rust
+#[wasm_bindgen_test]
+fn pass() {
+    assert_eq!(1 + 1, 2);
+}
+```
+
+Here the `pass` function is a unit test which asserts that arithmetic works in
+WebAssembly like we'd expect everywhere else. If the test panics (such as the
+`assert_eq!` being false) then the test will fail, otherwise the test will
+succeed.
+
+The [reference documentation for `#[wasm_bindgen_test]`][wbg-test] should have
+more information about defining these tests.
+
+[wbg-test]: https://rustwasm.github.io/docs/wasm-bindgen/wasm-bindgen-test/index.html
+
+## 2. Crate Configuration
+
+Other than the test in this module, we'll also see:
+
+```rust
+use wasm_bindgen_test::*;
+
+wasm_bindgen_test_configure!(run_in_browser);
+```
+
+Like we saw earlier in `src/lib.rs` the `*` import pulls in everything from
+`wasm_bindgen_test`, notably the `wasm_bindgen_test_configure` macro and the
+`wasm_bindgen_test` attribute.
+
+The `wasm_bindgen_test_configure` macro (denoted by ending in `!`) is used to
+indicate that the test is intended to execute in a web browser as opposed to
+Node.js, which is the default.
+
+## 3. `#![cfg]` directives
+
+The last part we'll notice about this crate is this statement at the top:
+
+```rust
+#![cfg(target_arch = "wasm32")]
+```
+
+This statement means that the test is only intended for the `wasm32`
+architecture, or the `wasm32-unknown-unknown` target. This enables `cargo test`
+to work in your project if the library is also being developed for other
+platforms by ensuring that these tests only execute in a web browser.

docs/src/tutorials/npm-browser-packages/template-deep-dive/wee_alloc.md

@@ -6,17 +6,22 @@
 
 ## What is `wee_alloc`?
 
-Reducing the size of compiled WebAssembly code is important, since it is often transmitted over the Internet or placed on embedded devices.
-
-*Want to learn more about code sizein the rustwasm toolchain? Check out this [documentation](https://rustwasm.github.io/docs/book/reference/code-size.html).
+WebAssembly code is frequently transmitted over the wire to users, so compiled
+code size is often important to ensure an application loads quickly and is
+responsive.
 
 > `wee_alloc` is a tiny allocator designed for WebAssembly that has a (pre-compression) code-size footprint of only a single kilobyte.
 
 [An analysis](http://fitzgeraldnick.com/2018/02/09/wee-alloc.html) suggests that over half of the bare minimum WebAssembly memory footprint is required by Rust's default memory allocator. Yet, WebAssembly code often does not require a sophisticated allocator, since it often just requests a couple of large initial allocations.
 
-`wee_alloc` trades off size for speed. Although it has a tiny code-size footprint, it is relatively slow if additional allocations are needed.
+`wee_alloc` trades off size for speed. It has a tiny code-size
+footprint, but it is is not competitive in terms of performance with the
+default global allocator, for example.
 
-For even more details, see the [`wee_alloc` repository](https://github.com/rustwasm/wee_alloc).
+For even more details, see the [`wee_alloc`
+repository](https://github.com/rustwasm/wee_alloc), or
+[general documentation](https://rustwasm.github.io/docs/book/reference/code-size.html) about
+shrinking code size of WebAssembly binaries.
 
 ## Enabling `wee_alloc`
 
@@ -25,32 +30,23 @@ In `lib.rs`, we have the configuration for `wee_alloc` inside a `cfg_if!` macro:
 ```rust
 cfg_if! {
     if #[cfg(feature = "wee_alloc")] {
-        extern crate wee_alloc;
         #[global_allocator]
         static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;
     }
 }
 ```
 
-This code block is intended to initialize `wee_alloc` as the global memory allocator, but only if the `wee_alloc` feature is enabled in `Cargo.toml`.
-
-To do so we need to append `"wee_alloc"` to the `default` vector in `Cargo.toml`. Then, the `cfg_if!` block is replaced with the contents of the `if` block, shown above.
+This code block is intended to initialize `wee_alloc` as the global memory
+allocator, but only if the `wee_alloc` feature is enabled at compile time. The
+feature can be enabled by passing extra options while building:
 
-```toml
-[features]
-default = ["console_error_panic_hook", "wee_alloc"]
 ```
-
-## Rust nightly
-
-`wee_alloc` currently relies on features only available in Rust nightly. As such it requires you to use the nightly toolchain for compilation. If you have [Rustup](https://rustup.rs/) set up, you can install the nightly toolchain as follows:
-
-```
-rustup toolchain add nightly
+$ wasm-pack build -- --features wee_alloc
 ```
 
-To use `wasm-pack` with Rust nightly run:
+or alternatively you could turn it on by default in `Cargo.toml`:
 
-```
-rustup run nightly wasm-pack build
+```toml
+[features]
+default = ["console_error_panic_hook", "wee_alloc"]
 ```

docs/src/tutorials/npm-browser-packages/testing-your-project.md

@@ -0,0 +1,45 @@
+# Testing your project
+
+Now after writing and building code, let's actually execute it! You can execute
+tests with:
+
+```bash
+$ wasm-pack test --firefox
+[INFO]: Checking for the Wasm target...
+    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
+     Running target/wasm32-unknown-unknown/debug/deps/web-9e7d380f8600b08e.wasm
+Interactive browsers tests are now available at http://127.0.0.1:8000
+
+Note that interactive mode is enabled because `NO_HEADLESS`
+is specified in the environment of this process. Once you're
+done with testing you'll need to kill this server with
+Ctrl-C.
+```
+
+The console won't finish just yet, but as indicated you can visit
+http://127.0.0.1:8000 in your web browser to see the test output:
+
+```
+running 1 test
+
+test web::pass ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored
+```
+
+and we've now executed our first tests in a web browser!
+
+If you'd like to execute tests in a headless web browser (you don't need to
+manually visit a page) you can do:
+
+```bash
+$ wasm-pack test --headless --firefox
+```
+
+and similarly if you're developing a project for Node.js you can also execute
+`wasm-pack test --nodejs` to run tests in Node.
+
+Be sure to see the [testing reference documentation][testing-reference] for
+other supported features as well!
+
+[testing-reference]: https://rustwasm.github.io/docs/wasm-bindgen/wasm-bindgen-test/index.html