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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm-pack does not find installed wasm-bindgen #308

Closed
coproduto opened this issue Sep 16, 2018 · 10 comments
Closed

wasm-pack does not find installed wasm-bindgen #308

coproduto opened this issue Sep 16, 2018 · 10 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists user report
Milestone

Comments

@coproduto
Copy link

coproduto commented Sep 16, 2018

🐛 Bug description

On MacOS, wasm-pack will always take 4 to 5 minutes to run, stopping at the "[7/8] Installing wasm-bindgen..." stage.

🤔 Expected Behavior

wasm-pack should use an existing wasm-bindgen install instead of redownloading every time.

👟 Steps to reproduce

On a Mac, install wasm-pack, NPM, the wasm rustc backend, and cargo-generate.
Run the following commands:

cargo generate --git https://github.com/rustwasm/wasm-pack-template

In the generated project, run:

wasm-pack init
rm -rf pkg
wasm-pack init

Both runs of wasm-pack will take the same time.

🌍 Your environment

Late 2015 MacBook Pro
MacOS High Sierra v10.13.6
wasm-pack version: 0.4.2
rustc version: 1.30.0-nightly

@xmclark
Copy link
Contributor

xmclark commented Sep 16, 2018

What version of wasm-bindgen is shown in your Cargo.toml?

@coproduto
Copy link
Author

@xmclark

[dependencies]
wasm-bindgen = "0.2"

@xmclark
Copy link
Contributor

xmclark commented Sep 16, 2018

I had the exact same issue before. The easiest way to fix is setting the patch version. e.g. wasm-bindgen = "0.2.19"

The wasm-bindgen version has to match the one you have installed exactly. You have a wasm-bindgen v 0.2.19 or something installed, and it is matching on 0.2, so it always fails the check.

There is a little blurb with more explanation on the issue:
#272

@ashleygwilliams ashleygwilliams added bug Something isn't working duplicate This issue or pull request already exists user report labels Sep 18, 2018
@ashleygwilliams
Copy link
Member

ideally, when #270 is fixed (there is an open PR right now for it) this will also be fixed. our next release is blocked until that PR lands- but hopefully we should be able to get it done this week. sorry you ran into this @pcstl and thanks @xmclark for helping respond! super appreciate you both 🤗

@coproduto
Copy link
Author

Hey, I changed the version in my Cargo.toml to wasm-bindgen = "0.2.21" (which is the same version as the CLI I have installed) and it still does a full install every time. The problem here does not seem to be what you are assuming it to be.

@ashleygwilliams
Copy link
Member

@pcstl wasm-pack will do a full install everytime to ensure that the correct version exists. if you are sure you have the correct version you can run the command with --no-installs and avoid the installation steps. verison 0.5.0 will mitigate all of this, hopefully we can release it this week.

@coproduto
Copy link
Author

Hi Ashley,

thanks for the help, but if I try using --no-installs it says this argument was not expected. I'm on wasm-pack 0.4.2 right now.

For what it's worth, I'm just doing a cargo build and copying stuff into the right places so I can get a decent edit-build loop time. The reason I was using wasm-pack init for this is that the Rust + WASM tutorial tells users to use wasm-pack for building.

@fitzgen
Copy link
Member

fitzgen commented Sep 19, 2018

@pcstl it's -m no-install, not --no-install (when in doubt, run --help for a full listing of flags)

@coproduto
Copy link
Author

@fitzgen I see. Thanks. I had ran --help, but since -m was hidden down there in the OPTIONS section and no-install was even further hidden in the description for -m, I didn't figure it out at first. It might be a nice UX change to make the no-install option more visible.

@ashleygwilliams ashleygwilliams added this to the 0.5.0 milestone Sep 24, 2018
@ashleygwilliams
Copy link
Member

this should be solved by the latest 0.5.0 release, closing. if it is not fixed please comment with more details and i will reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists user report
Projects
None yet
Development

No branches or pull requests

4 participants