Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm-pack test <extra_options> does not work as expected #698

Open
alexlapa opened this issue Aug 8, 2019 · 7 comments
Open

wasm-pack test <extra_options> does not work as expected #698

alexlapa opened this issue Aug 8, 2019 · 7 comments

Comments

@alexlapa
Copy link

@alexlapa alexlapa commented Aug 8, 2019

馃悰 Bug description

wasm-pack test does not pass <extra_options> to cargo build --tests --target wasm32-unknown-unknown.

馃 Expected Behavior

wasm-pack test --firefox -- --features some_feature

should invoke

cargo build --tests --target wasm32-unknown-unknown --features some_feature

馃憻 Steps to reproduce

Running

wasm-pack test --firefox -- --features some_feature

Causes error during tested crate compilation, since some_feature is not enabled.

Last log entry:

INFO 2019-08-08T19:58:57Z: wasm_pack::child: Running "cargo" "build" "--tests" "--target" "wasm32-unknown-unknown"

However, running:

cargo test --target wasm32-unknown-unknown --features some_feature

works.

Code example: https://github.com/alexlapa/wasm-pack-698-reproduction

Possible solution

It seems to me that there is no reason to run cargo build --tests --target wasm32-unknown-unknown when running wasm-pack test.

wasm-pack test will run wasm-bindgen-test, which will run cargo test, which will run cargo build --tests correctly propagating all extra options.

i.e. you can just remove step_build_tests

馃實 Your environment

wasm-pack version: 0.8.1
rustc version: 1.36.0 (a53f9df32 2019-07-03)

@alexlapa

This comment has been minimized.

Copy link
Author

@alexlapa alexlapa commented Aug 12, 2019

@najamelan

This comment has been minimized.

Copy link

@najamelan najamelan commented Aug 22, 2019

yes, this is an annoying bug.

@lukidoescode

This comment has been minimized.

Copy link

@lukidoescode lukidoescode commented Mar 17, 2020

@ashleygwilliams is the label needs reproduction still valid?

@najamelan

This comment has been minimized.

Copy link

@najamelan najamelan commented Mar 17, 2020

I am using it with -- --all-features and it works, but I had to remove the .cargo/config with:

[target.wasm32-unknown-unknown]
runner = 'wasm-bindgen-test-runner'

It seems wasm-pack doesn't like this one, so it's not possible to switch between cargo test and wasm-pack test. Maybe @alexlapa could check if that is the issue they have? It would be nice if both were compatible.

Update: sorry for the confusion. I just tested it again and it seems to be working with both --all-features and --features some_feature. Even with the .cargo/config in place. I haven't yet tried with several features.

Update 2: I know what happened now. It doesn't combine with .cargo/config on travis, but it does work at home. Travis log: https://travis-ci.org/github/najamelan/ws_stream_wasm/jobs/663705905

@alexlapa

This comment has been minimized.

Copy link
Author

@alexlapa alexlapa commented Mar 18, 2020

Retested reproduction with latest wasm-pack (0.9.1), it is still reproducible.

wasm-pack test --chrome --headless -- --features some_feature

[INFO]: Checking for the Wasm target...
   Compiling wasm-pack-698-reproduction v0.1.0 (/home/alexlapa/CLionProjects/wasm-pack-698-reproduction)
error[E0432]: unresolved import `wasm_pack_698_reproduction::foo`
 --> tests/integration_tests.rs:9:9
  |
9 |     use wasm_pack_698_reproduction::foo;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `foo` in the root

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `wasm-pack-698-reproduction`.

To learn more, run the command again with --verbose.
Error: Compilation of your program failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
  full command: "cargo" "build" "--tests" "--target" "wasm32-unknown-unknown"

It also prints full command:

"cargo" "build" "--tests" "--target" "wasm32-unknown-unknown"

So features are not propagated properly.

@najamelan

This comment has been minimized.

Copy link

@najamelan najamelan commented Mar 18, 2020

strange:

$ wasm-pack test  --chrome --headless -- --features tokio_io --verbose

    Running `rustc --crate-name ws_stream_wasm --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C debuginfo=2 --test --cfg 'feature="tokio_io"' ...

This is version: wasm-pack 0.9.1. On travis for me this only works if there isn't the .cargo/config with the conf above for me. Don't know what's different on my system.
rustc 1.42.0 (b8cedc004 2020-03-09)

Nightly works too for me, actually looks like wasm-pack runs nightly even if stable is set as default...

@najamelan

This comment has been minimized.

Copy link

@najamelan najamelan commented Mar 18, 2020

@alexlapa I had a look at your reproduction case. It will work as expected if you add this line to the top of your integration test:

#![cfg(feature = "some_feature")]

This will indicate that this test file requires the feature. It will be excluded when running wasm-pack test without the features, and will be included and working if you set the feature.

I also checked wasm-pack build --target web --dev -- --features some_feature and it works fine, including the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can鈥檛 perform that action at this time.