npm run start throws: Error: invalid type: sequence, expected a string at line 5 column 11

[haai]

🐛 Bug description

I am try to compile the webpack wasm-pack project and then I get an Rust-Compilation Error:

✅  Your crate has been correctly compiled

10% building 0/3 entries 3/3 dependencies 0/3 modulesError: invalid type: sequence, expected a string at line 5 column 11
Caused by: invalid type: sequence, expected a string at line 5 column 11

But there is no good information where this error is coming from.
Do you know a way how to tackle this down?

Guess there is an issue with wasm-bindgen?

🤔 Expected Behavior

Compilation successful.
wasm-pack build works fine.

👟 Steps to reproduce

unkown .. just run "npm run start".

🌍 Your environment

wasm-pack 0.13.0

[kpreid]

I am seeing the same cryptic error, but with different circumstances and timing, and not using npm at all:

$ wasm-pack build --target web --out-dir <path> --dev <path>
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
    Blocking waiting for file lock on package cache
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.08s
Error: invalid type: sequence, expected a string at line 4 column 19
Caused by: invalid type: sequence, expected a string at line 4 column 19

It occurs randomly, in that if I rerun the same command it will succeed. This is with wasm-pack 0.13.1.

[RossSmyth]

I am experiencing this too.

[SabrinaJewson]

This appears to be caused by a race condition. I can reproduce it reliably with a command like while wasm-pack build --target web --out-dir pkg; do done running in two terminals.

A quick hack to fix it is wrapping all calls to wasm-pack in a global mutex. For example, if one has wasm-pack installed through Cargo, then one can place this shell script higher up in $PATH:

#!/bin/sh
XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-"/run/user/$UID"}"
exec flock "$XDG_RUNTIME_DIR/wasm-pack-lock" "${CARGO_HOME:-"$HOME/.cargo"}/bin/wasm-pack" "$@"

[RossSmyth]

I tried this and it works for me!

[SabrinaJewson]

This is caused by a line in manifest/mod.rs which looks for an existing package.json and decides to deserialize it as a HashMap<String, String>. This line was added in #986 to resolve #606. The actual error is caused because the other instance of wasm-pack also writes out a package.json, which obviously cannot be serialized into a HashMap<String, String> (note that wasm-bindgen does, in fact, output a package.json in the correct format).

Evidently, there are three bugs here:

1. that HashMap<String, String> is used instead of reading the dependencies field as a HashMap<String, String>;
2. that this obviously-wrong code path is seemingly never exercised;
3. that this approach of reading from pkg/package.json to begin with means that parallel execution is always goïng to be somewhat broken, even if the HashMap<String, String> issue is fixed.

There’s also the more concerning issue of how this obviously-wrong code path ended up in codebase to begin with. Did nobody think to test it once? At any rate, I have the following suggestions:

1. Decide whether parallel execution of wasm-pack is supported: if so, take steps to ensure external tools like wasm-bindgen write to temporary directories instead of pkg, ensuring that wasm-pack itself only ever writes to pkg, and if not, implement a file-locking scheme to prevent multiple instances of wasm-pack on the same pkg folder from running concurrently;
2. ascertain why wasm-bindgen is not correctly writing out package.json, and thus why this incorrect code path if left unused.

[ltfschoen]

A quick hack to fix it is wrapping all calls to wasm-pack in a global mutex. For example, if one has wasm-pack installed through Cargo, then one can place this shell script higher up in $PATH:

#!/bin/sh
XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-"/run/user/$UID"}"
exec flock "$XDG_RUNTIME_DIR/wasm-pack-lock" "${CARGO_HOME:-"$HOME/.cargo"}/bin/wasm-pack" "$@"

i tried to do that in this commit maciejhirsz/kobold@4b18a83 but it still gave the error

[ZabelTech]

heya!
I needed to get this working so I patched the parsing up: #1483
please have a look if time permits.

[MikkelPaulson]

@ZabelTech Thank you for the PR, verified working here! 👍

Unfortunately, since I'm using wasm-pack in a build pipeline, it's not practical to build it on demand. I was able to get a successful build with the even messier hack:

mv package.json package.json.bak
echo -n '{}' > package.json
wasm-pack build --release
mv -f package.json.bak package.json

Obviously this wouldn't work if you're using wasm-pack to publish, but since I'm just building, the contents of package.json don't actually matter.

[derekfrye]

This appears to be caused by a race condition. I can reproduce it reliably with a command like while wasm-pack build --target web --out-dir pkg; do done running in two terminals.

A quick hack to fix it is wrapping all calls to wasm-pack in a global mutex. For example, if one has wasm-pack installed through Cargo, then one can place this shell script higher up in $PATH:

#!/bin/sh
XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-"/run/user/$UID"}"
exec flock "$XDG_RUNTIME_DIR/wasm-pack-lock" "${CARGO_HOME:-"$HOME/.cargo"}/bin/wasm-pack" "$@"

Worked for me, too.