Wasm-pack: Strange behavior on first run of `wasm-pack init`

[TejasQ]

🐛 Bug description

So in a new Rust project, I have my code written and sitting pretty and everything works. I am then ready to compile to wasm. I run wasm-pack init and get an error (described below). If I run the same command again, _everything works as expected_. 🤔 So weird.

Error:

$ wasm-pack init --scope tejaskumar

  [1/8] 🔧  Checking crate configuration...
  [2/8] 🎯  Adding WASM target...
  [3/8] 🌀  Compiling to WASM...
  [4/8] 📂  Creating a pkg directory...
  [5/8] 📝  Writing a package.json...
  ⚠️   [WARN]: Field description is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field repository is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field license is missing from Cargo.toml. It is not necessary, but recommended
  [6/8] 👯  Copying over your README...
  ⚠️   [WARN]: origin crate has no README
  [7/8] ⬇️  Installing WASM-bindgen...
| [8/8] 🏃‍♀️  Running WASM-bindgen...
wasm-bindgen failed to execute properly. stderr:

error: failed to read `target/wasm32-unknown-unknown/release/my_wasmp.wasm`
    caused by: No such file or directory (os error 2)

🤔 Expected Behavior

What should have happened?
It should have created a pkg folder with my npm package ready to go.

👟 Steps to reproduce

Clear steps describing how to reproduce the issue, including commands and flags run. If you are seeing an error, please include the full error message and stack trace.

Unfortunately, this is completely random and hard to reproduce. :(

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: 0.4.2
rustc version: rustc 1.28.0 (9634041f0 2018-07-30)

[ashleygwilliams]

hi @TejasQ - thank you for the thoughtful report, and so sorry you are running into this! due the unpredictable nature of the bug, i'll do my best to figure this out as soon as possible for ya, though it may take a bit to track down.

since it's only happening some of the time, i imagine there is a race condition... somewhere? is there any chance you could point me to the source code? or share a bit of it? would love to get this fixed for you and the source would def make it easier for me :)

[TejasQ]

Oh, the source code is just a reproduction of the README for a demo I'm doing at an event to get people fired up about this project.

Here's the code. I could even push up a repo if it helps. I'll do that shortly.

extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    fn alert(message: &str);
}

#[wasm_bindgen]
pub fn say_hello() {
    alert("Hello from wasm");
}

[TejasQ]

Here's the repo.

[TejasQ]

Thanks so much for your willingness to help, Ashley! 🎉

[ashleygwilliams]

hey @TejasQ thanks for the materials- i wasn't able to recreate the bug. one thing i can note- it looks like the binary created in your error case was called my_wasmp.wasm:

error: failed to read `target/wasm32-unknown-unknown/release/my_wasmp.wasm`
    caused by: No such file or directory (os error 2)

however, the name in your Cargo.toml is my-wasm-app. did you change the name in your Cargo.toml at all? If not, that would suggest that wasm-pack is doing that, though I find that a bit surprising... (still not out of the question though!). Let me know and I'll keep poking in the meantime!

[TejasQ]

Oh no, I totally changed the name so it's more readable.

[ashleygwilliams]

ah! ok- so perhaps changing the name was the issue... can you try again? that may have been the culprit. if you run wasm-pack and then change the name and run it again, it will look for the name in the Cargo.toml but i don't think it will always rebuild the binary (this is cargo- not wasm-pack). generally (and this is not ideal, but can guarantee no issue)- if i change anything in Cargo.toml rm -rf target and rm -rf pkg. this ensures that everything is rebuilt.

@alexcrichton am i right in observing that sometimes changes in Cargo.toml don't trigger a rebuild of the binary (if no other rust src files are touched?)

[TejasQ]

Okay, so for context:

The name of the app was my-wasmp in the beginning. I ran the compiler, and it failed with that error (which could be because of underscores instead of hyphens? 🤔). I ran it again, and it passed.

I then opened this issue, and renamed the project from my-wasmp to my-wasm-app _after_ the bug report for y'all's reading pleasure.

For that reason, I don't think changing the name was the culprit. I can try to reproduce it though, but now it's just working without breakages 🤔. I'll continue exploring and update this soon.

As an aside, I just demoed this great tool and it worked, so that's pretty great. I hope more people get fired up about the incredible doors this could open. 🙂

[alexcrichton]

@ashleygwilliams correct yeah, some metadata in Cargo.toml doesn't affect the final artifacts so it doesn't recompile, but things like changing the package name should recompile.

I was unable to reproduce this using the repo link above too :(

[TejasQ]

Ah, I'm sorry y'all – it is _so random_.

Here's _exactly_ what I do to reproduce this on a semi-consistent basis:

1. cargo new my-wasm-app
2. cd my-wasm-app
3. Edit Cargo.toml
   
   
   
   • Add wasm-bindgen = "0.2.21" under dependencies
   
   
   • Add crate-type = ["cdylib"] under lib
   
   
4. Create src/lib.rs with the code from my repro repo.
5. Save.
6. Run wasm-pack init
7. It fails.
8. Run it again.
9. It succeeds.

I also use the --scope flag sometimes. Could _that_ be what breaks it? 🙈 I am so confused by this.

Thanks for trying to figure it out with me.

[ashleygwilliams]

testing this out- but one thing to note! you'll probably want to pass --lib to the cargo new command :) the default changed a bit ago (it creates a binary project by default now, and you'd want a lib for this)

[ashleygwilliams]

OK! can reproduce! here's the output i get

Ashleys-MacBook-Pro-2:my-wasm-app ag_dubs$ wasm-pack init

  [1/8] 🔧  Checking crate configuration...
  [2/8] 🎯  Adding WASM target...
  [3/8] 🌀  Compiling to WASM...
  [4/8] 📂  Creating a pkg directory...
  [5/8] 📝  Writing a package.json...
  ⚠️   [WARN]: Field description is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field repository is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field license is missing from Cargo.toml. It is not necessary, but recommended
  [6/8] 👯  Copying over your README...
  ⚠️   [WARN]: origin crate has no README
  [7/8] ⬇️  Installing WASM-bindgen...
| [8/8] 🏃‍♀️  Running WASM-bindgen...
wasm-bindgen failed to execute properly. stderr:

error: failed to read `target/wasm32-unknown-unknown/release/my_wasm_app.wasm`
    caused by: No such file or directory (os error 2)

and here's the repo with all assets, generated included: https://github.com/ashleygwilliams/303-repro

[ashleygwilliams]

looks like it's a -/_ issue, and i should be able to fix it today

[TejasQ]

WOAH how'd you reproduce it? Was it following my steps?

[ashleygwilliams]

@TejasQ yes! though i had to change a few things in your instructions :) i think i know what the issue is (we do account for the -/_ but i guess there's a bug in it! gonna try to have a patch today)

[TejasQ]

Thanks!

you'll probably want to pass --lib to the cargo new command

Thanks for the shorthand! So far, I've been manually making lib.rs and adding lib to Cargo.toml. 😅

[ashleygwilliams]

@TejasQ so that generally works, but you'll note that Cargo.lock is not ignored for binary projects, but is ignored for library projects! if you keep doing it manually don't forget to add Cargo.lock to the .gitignore :)

[TejasQ]

Hah! I really shouldn't keep doing that manually. Always trust the abstraction, as they say. ¯\_(ツ)_/¯

Thanks for the info!

[ashleygwilliams]

just so you know- i haven't forgotten about this.. the issue is that i cannot figure out how to test this successfully. you are very right that it fails the first time, and then works the second! with no changes at all. this is a very interesting bug- still working on it!

[ashleygwilliams]

OK! 10 more minutes and i have a test that reproduces the error, https://github.com/rustwasm/wasm-pack/pull/322

[ashleygwilliams]

ok so this is pretty weird. first run produces what is on the left, second+ subsequent runs, what is on the right

cc @alexcrichton @fitzgen you have any ideas? i am... baffled. these aren't even files that wasm-pack generates.

[ashleygwilliams]

@TejasQ so- i think that you may have run into this because you were running cargo new which generated a main.rs- did you have one when u ran the wasm-pack init command?

[TejasQ]

Yes! Why would that break things? 🤔

[ashleygwilliams]

@TejasQ so the best i can tell, this is the sitch we have (i'm gonna be way way way more methodical today so that i can really nail it down...):

• when a lib.rs is compiled, it produces a wasm and a d file that always inflect - to _
• when a main.rs is compiled, it produces a wasm and a d file that maintain the pkg name, regardless of hyphen usage
• when both are present, both sets of files should be compiled and there is no conflict. HOWEVER, in your case (which i have reproduced, but then struggle to re:reproduce) it generates the main scenario (with hypens) but only half the lib scenario (with underscores). wasm-pack looks for the lib wasm which has underscores. because it doesn't fine the underscore wasm, it fails. on the second run (why??? i have no idea), it seems to finally make the underscore wasm.

there's clearly some questions still here, HOWEVER, i think if you never have main.rs it will avoid this entirely. that doesn't mean that we have nothing to fix of course (we should warn or error, and also figure out why it's behaving this way) but for you, i can practically suggest that if you remove the main.rs before any compilation steps you shouldn't bump into this (if you do, please let us know!)

[TejasQ]

Thanks, Ashley! 🙌

While I'm happy to have a way to make it work, my inner engineer is _dying_ to either: a) answer the questions to which we have no idea, or b) find the answer. Can I help y'all look? Can we look together? Ah, this is my favorite part about coding!

[ashleygwilliams]

oh i promise you i continue to dig :) a thing that would certainly help is to see if you can reproduce without a main.rs. also- one thing i noted is the rustc version you listed is actually a stable rust, wasm-pack enforces nightly at the moment, so i'm trying to figure out what version of nightly rust and cargo you ended up using the day you ran this. if you have any further ideas about that please let me know!

[TejasQ]

FOR SURE! I'll get on it and report back with anything interesting that might come up.

[ashleygwilliams]

it's been a second since this has been updated- do you continue to see this behavior with the latest releases? i'm going to close, but please comment/reopen if you continue to have trouble!