Merge pull request #590 from alexcrichton/doc-tweaks

Smorgasboard of doc improvements
master
ashley williams 6 years ago committed by GitHub
commit 5921f1a7ec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
  1. 10
      docs/src/SUMMARY.md
  2. 4
      docs/src/prerequisites/index.md
  3. 24
      docs/src/tutorials/npm-browser-packages/building-your-package.md
  4. 23
      docs/src/tutorials/npm-browser-packages/building-your-project.md
  5. 2
      docs/src/tutorials/npm-browser-packages/getting-started.md
  6. 6
      docs/src/tutorials/npm-browser-packages/getting-started/manual-setup.md
  7. 10
      docs/src/tutorials/npm-browser-packages/project-setup/index.md
  8. 21
      docs/src/tutorials/npm-browser-packages/project-setup/using-a-template.md
  9. 1
      docs/src/tutorials/npm-browser-packages/template-deep-dive.md
  10. 44
      docs/src/tutorials/npm-browser-packages/template-deep-dive/cargo-toml.md
  11. 10
      docs/src/tutorials/npm-browser-packages/template-deep-dive/index.md
  12. 14
      docs/src/tutorials/npm-browser-packages/template-deep-dive/src-lib-rs.md
  13. 39
      docs/src/tutorials/npm-browser-packages/template-deep-dive/src-utils-rs.md
  14. 74
      docs/src/tutorials/npm-browser-packages/template-deep-dive/tests-web-rs.md
  15. 40
      docs/src/tutorials/npm-browser-packages/template-deep-dive/wee_alloc.md
  16. 45
      docs/src/tutorials/npm-browser-packages/testing-your-project.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)

@ -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

@ -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.

@ -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.

@ -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

@ -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`

@ -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

@ -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

@ -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

@ -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)

@ -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`.

@ -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

@ -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.

@ -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"]
```

@ -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
Loading…
Cancel
Save