The CLI of wasm-pack build and wasm-pack test is confusing

[not-my-profile]

$ wasm-pack build --help
...
USAGE:
    wasm-pack build [FLAGS] [OPTIONS] [ARGS]

ARGS:
    <path>                The path to the Rust crate. If not set, searches up the path from the current directory
    <extra-options>...    List of extra options to pass to `cargo build`

Firstly it's confusing that the path argument is displayed as <path> since that syntax usually implies that the argument is required ... [path] would be better ... this is apparently a structopt limitation. But since structopt is in maintenance mode (TeXitoi/structopt#525), we probably want to switch to clap anyway, which does display optional positional parameters with [...].

$ wasm-pack test --help
USAGE:
    wasm-pack test [FLAGS] [OPTIONS] [path-and-extra-options]...

ARGS:
    <path-and-extra-options>...    
            Path to the Rust crate, and extra options to pass to `cargo test`.
            
            If the path is not provided, this command searches up the path from the current dirctory
            
            This is a workaround to allow wasm pack to provide the same command line interface as `cargo`. See
            <https://github.com/rustwasm/wasm-pack/pull/851> for more information.

While it may be convenient to receive the arguments as a Vec<String> I don't think lumping path and extra options together into one argument is a good idea ... the --help output is confusing.

But this was all nit-picking the much more worse problem is that wasm-pack build and wasm-pack test handle the paths differently:

• wasm-pack build returns an crate directory is missing a `Cargo.toml` file; is `{}` the wrong directory? error message if {path}/Cargo.toml doesn't exist, so e.g. wasm-pack build -p foo doesn't work
• wasm-pack test since #851 tries to be more clever and automatically disregards the path argument if it starts with a -, falling back to the current directory, so e.g. wasm-pack test -p foo works

I think CLIs should be predictable and consistent and the wasm-pack CLI of those two commands currently is neither of those things. I think the obvious solution would be to make the path argument non-positional but this would of course be a breaking change, so I am afraid we are stuck with having a positional argument that may be a path or a cargo argument.

I think the course of action is:

1. Fix the tests The tests are failing #1212 ... I don't want to contribute feature fixes to a project that has a failing CI.
2. Migrate from structopt to the newest clap.
3. Fix the --help output and make wasm-pack build behave like wasm-pack test in regards to the path handling.