Strange behavior on first run of `wasm-pack init` #303

TejasQ · 2018-09-13T18:24:12Z

🐛 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)

The text was updated successfully, but these errors were encountered:

ashleygwilliams · 2018-09-13T21:55:57Z

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 · 2018-09-13T22:03:21Z

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 · 2018-09-13T22:06:15Z

Here's the repo.

TejasQ · 2018-09-13T22:06:43Z

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

ashleygwilliams · 2018-09-14T15:30:03Z

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 · 2018-09-14T16:46:49Z

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

ashleygwilliams · 2018-09-14T16:53:59Z

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 · 2018-09-14T17:59:40Z

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 · 2018-09-14T21:22:44Z

@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 · 2018-09-14T22:17:13Z

Ah, I'm sorry y'all – it is so random.

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

cargo new my-wasm-app
cd my-wasm-app
Edit Cargo.toml
- Add wasm-bindgen = "0.2.21" under dependencies
- Add crate-type = ["cdylib"] under lib
Create src/lib.rs with the code from my repro repo.
Save.
Run wasm-pack init
It fails.
Run it again.
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 · 2018-09-18T15:51:31Z

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 · 2018-09-18T16:04:25Z

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 · 2018-09-18T16:05:51Z

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

TejasQ · 2018-09-18T16:41:53Z

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

ashleygwilliams · 2018-09-18T16:44:37Z

@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 · 2018-09-18T16:45:29Z

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 · 2018-09-18T16:46:33Z

@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 · 2018-09-18T17:04:07Z

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

Thanks for the info!

ashleygwilliams · 2018-09-20T20:03:21Z

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 · 2018-09-20T20:14:32Z

OK! 10 more minutes and i have a test that reproduces the error, #322

ashleygwilliams · 2018-09-20T21:17:27Z

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 · 2018-09-20T21:50:27Z

@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 · 2018-09-21T07:30:01Z

Yes! Why would that break things? 🤔

ashleygwilliams · 2018-09-21T14:01:18Z

@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 · 2018-09-21T14:21:57Z

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 · 2018-09-21T14:39:21Z

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 · 2018-09-21T14:47:29Z

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

ashleygwilliams · 2019-02-22T17:30:18Z

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!

ashleygwilliams added user report bug Something isn't working labels Sep 13, 2018

ashleygwilliams self-assigned this Sep 13, 2018

TejasQ pushed a commit to TejasQ/wasm-pack--303 that referenced this issue Sep 13, 2018

Reproduction for rustwasm/wasm-pack#303

d2b80ab

ashleygwilliams mentioned this issue Sep 20, 2018

[WIP] address issue 303 #322

Closed

ashleygwilliams added the PR attached there's a PR open for this issue label Sep 20, 2018

ashleygwilliams mentioned this issue Sep 21, 2018

should we *continue* to enforce cargo build --lib #326

Closed

ashleygwilliams closed this as completed Feb 22, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Strange behavior on first run of `wasm-pack init` #303

Strange behavior on first run of `wasm-pack init` #303

TejasQ commented Sep 13, 2018

ashleygwilliams commented Sep 13, 2018

TejasQ commented Sep 13, 2018

TejasQ commented Sep 13, 2018

TejasQ commented Sep 13, 2018

ashleygwilliams commented Sep 14, 2018

TejasQ commented Sep 14, 2018

ashleygwilliams commented Sep 14, 2018

TejasQ commented Sep 14, 2018 •

edited

Loading

alexcrichton commented Sep 14, 2018

TejasQ commented Sep 14, 2018

ashleygwilliams commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018 •

edited

Loading

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018 •

edited

Loading

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

TejasQ commented Sep 21, 2018 •

edited

Loading

ashleygwilliams commented Sep 21, 2018

TejasQ commented Sep 21, 2018

ashleygwilliams commented Sep 21, 2018

TejasQ commented Sep 21, 2018

ashleygwilliams commented Feb 22, 2019

Strange behavior on first run of wasm-pack init #303

Strange behavior on first run of wasm-pack init #303

Comments

TejasQ commented Sep 13, 2018

🐛 Bug description

🤔 Expected Behavior

👟 Steps to reproduce

🌍 Your environment

ashleygwilliams commented Sep 13, 2018

TejasQ commented Sep 13, 2018

TejasQ commented Sep 13, 2018

TejasQ commented Sep 13, 2018

ashleygwilliams commented Sep 14, 2018

TejasQ commented Sep 14, 2018

ashleygwilliams commented Sep 14, 2018

TejasQ commented Sep 14, 2018 • edited Loading

alexcrichton commented Sep 14, 2018

TejasQ commented Sep 14, 2018

ashleygwilliams commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018 • edited Loading

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018

ashleygwilliams commented Sep 18, 2018

TejasQ commented Sep 18, 2018 • edited Loading

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

ashleygwilliams commented Sep 20, 2018

TejasQ commented Sep 21, 2018 • edited Loading

ashleygwilliams commented Sep 21, 2018

TejasQ commented Sep 21, 2018

ashleygwilliams commented Sep 21, 2018

TejasQ commented Sep 21, 2018

ashleygwilliams commented Feb 22, 2019

Strange behavior on first run of `wasm-pack init` #303

Strange behavior on first run of `wasm-pack init` #303

TejasQ commented Sep 14, 2018 •

edited

Loading

TejasQ commented Sep 18, 2018 •

edited

Loading

TejasQ commented Sep 18, 2018 •

edited

Loading

TejasQ commented Sep 21, 2018 •

edited

Loading