Add no-modules to --target flag's help text

[fitzgen]

Fixes #416

[ashleygwilliams]

test result: ok. 34 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
   Doc-tests wasm-pack
error[E0460]: found possibly newer version of crate `itoa` which `cargo_metadata` depends on
 --> C:\projects\wasm-pack-071k0\src\lib.rs:5:1
  |
5 | extern crate cargo_metadata;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `itoa`: \\?\C:\projects\wasm-pack-071k0\target\release\deps\libitoa-cb012311ce8053ac.rlib
          crate `cargo_metadata`: \\?\C:\projects\wasm-pack-071k0\target\release\deps\libcargo_metadata-dc42b0938c512d43.rlib
error: test failed, to rerun pass '--doc'
Command exited with code 1

appveyor is failing because of this. maybe a cargo update would help? not sure what's happening here exactly, would need to dig into those specific deps

[ashleygwilliams]

once we are green this is good to go.

[fitzgen]

Did a carog update and hopefully that will fix the issue

[ashleygwilliams]

looks like it didn't :/ you also need a cargo fmt fyi

[fitzgen]

@alexcrichton says this is a compiler/cargo bug somewhere and that we should pin to a nightly from a couple days ago until he has a chance to investigate further.

[ashleygwilliams]

this seems to be still failing- do we have a sense as to why? i'm still not clear on the original error, entirely.

[fitzgen]

It is a cargo bug that we are waiting on a fix for -- all I did was rebase to keep up with changes.

[alexcrichton]

What might be happening here is something like this:

• Wasm-pack is built
• Wasm-pack's tests then run
• Some of wasm-pack's test build further things with Cargo. These compilations share the same target directory as wasm-pack itself. These compilations then overwrite and/or recompile libraries in-place
• Later when doctests run the newer libraries cause issues because libraries depending on them aren't rebuilt.

I haven't confirmed this yet locally, but that's my suspicion at this time. Looking through the history we see this is the first failing build which is connected to this PR which does seem to be adding tests which build more things. Maybe that test could be temporarily commented out to see if it passes?

[fitzgen]

Running the tests with --test-threads 1 does not seem to solve the problem.

[fitzgen]

Running cargo test --tests and cargo test --doc separately seems to do the trick.