wasm-bindgen-cli_0_2_104: init at 0.2.104

[insipx]

Added wasm-bindgen-cli version 0.2.104 package
closes #443144

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[Aleksanaa]

Why are we keeping every version in the tree? @rizary

[insipx]

@Aleksanaa not sure, maybe something to do with #374179? Personally not familiar with the conventions for this, though. Also #377534

[vivax3794]

wasmbindgen requires a exact match between the cli version and the library version, generally that isn't that bad as it should always be safe to update to the latest patch version of a library (but ofc when reproduciblity and outdated lock files are in the mix that complicates stuff, which is why I assume multiple versions are kept)
It's a case of upgrading a patch version technically being breaking change unless you also update the library versions alongside it.

[insipx]

additionally added myself as maintainer for wasm-bindgen-cli, happy to keep doing these updates and maybe figure out a better way to manage versions then keep every package in-tree. also noticed @rizary hasn't been too responsive for these updates

[philiptaron]

I'd love to have someone from the greater Rust team in Nixpkgs review this.

[vivax3794]

considering 0.2.102 and 0.2.103 were also released a few days ago I feel like maybe we should look into a better solution here, whether it be a community flake or a built-in function in nixpkgs.

[fusion44]

I've created a flake for v0.2.103:
https://github.com/fusion44/wasm-bindgen-cli-flake

I do not intend to support this flake forever if we can find a more permanent nixpkgs based solution.

[NotAShelf]

0.2.104 has been released 6 days ago. Any chance we could update and merge this?

[insipx]

updated to 0.2.104

[NotAShelf]

LGTM

[mksafavi]

I think this line needs to be updated:
wasm-bindgen-cli = wasm-bindgen-cli_0_2_100;

Also the docs link is not valid anymore:

homepage = "https://rustwasm.github.io/docs/wasm-bindgen/";
#to:
homepage = "wasm-bindgen.github.io/wasm-bindgen/";

[insipx]

fixed @mksafavi didn't know about the alias list!

[vivax3794]

Could we just overrideAttrs on packages that need it and patch ones that don't? That seems like the best solution to me, as we don't have multiple versions in the tree, and are only overriding it at specific places. Especially if versions are only used once or twice in-tree.

In tree, we avoid overrideAttrs.

I do want to see a case that needs a specific version and understand why that is. I've seen the assertions above in the thread, but I don't really understand them. An example would help.

The issue isnt that projects dont work with newer versions, the issue that theres two packages at play, wasm-bindgen-cli and wasm-bindgen and for a project to build their versions need to match.
Tbh I haven't looked at how nixpkgs handles cargo dependencies, and whether its easy to just bump all of them at once or not.

[philiptaron]

I don't see a wasm-bindgen derivation in the tree. What I understand you to mean:

1. There's a crate called wasm-bindgen. It lets you annotate Rust code with #[wasm_bindgen] to expose functions, types, and methods to JavaScript (and sometimes vice versa). When you compile with --target wasm32-unknown-unknown, the crate inserts the necessary glue code into the .wasm so that JS can call your Rust functions (and so that Rust can call JS APIs).
2. There's a command-line tool called wasm-bindgen-cli. It processes the raw .wasm file produced by cargo build and generates JavaScript (or TypeScript) bindings that know how to talk to your wasm module, as well as the cleaned-up .wasm binary with exports/imports wired correctly.

In Nixpkgs, there's no 1:1 mapping of crates to derivations, and by and large the Cargo lock files from upstream are respected. So some packages use a version of wasm-bindgen (the crate) in their lock file and also need to run wasm-bindgen-cli during the build, and these need to be the same version.

Is that correct?

[mksafavi]

Adding more to @vivax3794's comment, the main issue is that cargo build downloads the wasm-bindgen version that's defined in a project's cargo.lock file. Then for creating the js glue, it is using the wasm-bindgen-cli from nixpkgs.

If the versions don't match it returns this error:

wasm-bindgen --target web --no-typescript --out-dir ./target/wasm-bind ./target/wasm32-unknown-unknown/release/main.wasm
error: 

it looks like the Rust project used to create this Wasm file was linked against
version of wasm-bindgen that uses a different bindgen format than this binary:

  rust Wasm file schema version: 0.2.104
     this binary schema version: 0.2.100

Currently the bindgen format is unstable enough that these two schema versions
must exactly match. You can accomplish this by either updating this binary or
the wasm-bindgen dependency in the Rust project.

You should be able to update the wasm-bindgen dependency with:

    cargo update -p wasm-bindgen --precise 0.2.100

don't forget to recompile your Wasm file! Alternatively, you can update the
binary with:

    cargo install -f wasm-bindgen-cli --version 0.2.104

if this warning fails to go away though and you're not sure what to do feel free
to open an issue at https://github.com/rustwasm/wasm-bindgen/issues!

error: Recipe `build-wasm` failed on line 14 with exit code 1

I don't have enough experience on rust+wasm to know if updating wasm-bindgen causes any issues, but on my personal projects I didn't have any problems by upgrading and matching the versions.

[vivax3794]

I don't have enough experience on rust+wasm to know if updating wasm-bindgen causes any issues

Updating the patch versions (which is the most common, considering we are on patch version 100+ now) should always be safe (again referring back to my earlier comment, if you consider updating the crate and cli together.)

It's a case of upgrading a patch version technically being breaking change unless you also update the library versions alongside it.

[insipx]

it looks like people beat me to the error message, but here's a minimal example of this occurring in a cargo project: https://github.com/insipx/wasm-bindgen-cli-nix-example

if wasm-bindgen in the flake and in Cargo.toml aren't both matched, wasm-bindgen will fail with the error pasted into the readme

In Nixpkgs, there's no 1:1 mapping of crates to derivations, and by and large the Cargo lock files from upstream are respected. So some packages use a version of wasm-bindgen (the crate) in their lock file and also need to run wasm-bindgen-cli during the build, and these need to be the same version.

this is correct. if users have a cargo project on 0.2.100 and run nix flake update to 104, their builds will break until they update to 0.2.104 in their cargo project.

[alyssais]

Trying to remember the thoughts I had last time I looked into this: I think it's fine to package multiple versions, but we should only package versions of wasm-bindgen-cli that are used in Nixpkgs. Otherwise we have no obvious path to removal.

[insipx]

it sounds like a workflow that only updates wasm-bindgen if its used in nixpkgs would look something like this:

one package on the latest version, then everytime wasm-bindgen-cli is updated to the next latest there needs to be a check if any nix package has been pushed with that latest version,at which point the "latest" is updated and a wasm-bindgen package with the version being used is left in tree, until that package updates to the latest?

mostly I'm using wasm-bindgen in a dev environment rather than packages, so I am overall unfamiliar with how such a process could work with nixpkgs, but sounds reasonable if there is a way to do that check

[insipx]

Sorry I accidentally re-requested a review from NotAShelf when exiting the tab 😬

[alyssais]

one package on the latest version, then everytime wasm-bindgen-cli is updated to the next latest there needs to be a check if any nix package has been pushed with that latest version,at which point the "latest" is updated and a wasm-bindgen package with the version being used is left in tree, until that package updates to the latest?

I don't really understand this. What I mean is that we can add should versions of wasm-bindgen-cli when we're updating or adding a package that needs that new version.

[philiptaron]

One change requested for the homepage URL.

I have an idea about how to unify all these versions into one derivation, but it can wait for later.

[insipx]

@philiptaron happy to work on a PR to unify all the versions! If you know a good design, feel free to be assign me a ticket for it. my goal is to have a faster/better way to keep up with wasm-bindgen-cli updates, since nixpkgs has lagged behind in recent months which can sometimes be inconvenient for rust/wasm projects

[NotAShelf]

Thanks everyone, this makes a lot of headache disappear for me :)

[alyssais]

Was I just completely ignored on this PR? I'm sure there's an argument to be made for packaging new versions before we have a use for them, but it would have been nice to actually have that discussion…

[mksafavi]

Was I just completely ignored on this PR? I'm sure there's an argument to be made for packaging new versions before we have a use for them, but it would have been nice to actually have that discussion…

@alyssais
I was under the impression that we don't need a new separate version either. I guess we can focus on removing the unnecessary versions. What do you think?
Should we approach it per package? We can migrate each package that is using wasm-bindgen to the latest version in separate PRs. If a version is not used anymore we can remove it.

happy to work on a PR to unify all the versions! If you know a good design, feel free to be assign me a ticket for it. my goal is to have a faster/better way to keep up with wasm-bindgen-cli updates, since nixpkgs has lagged behind in recent months which can sometimes be inconvenient for rust/wasm projects

@insipx
I'm happy to help with that. If you want to split the task let me know. I can look into the packages that are using wasm-bindgen and see if we can patch them to use the latest.

[SuperSandro2000]

Backported this at #461408

[philiptaron]

Was I just completely ignored on this PR? I'm sure there's an argument to be made for packaging new versions before we have a use for them, but it would have been nice to actually have that discussion…

Hey Alyssa, sorry I missed this message in October. I didn't get the sense that you were blocking this PR based on not having a use in Nixpkgs, just expressing a preference. This is because of the wording in CONTRIBUTING.md:

nixpkgs/CONTRIBUTING.md

Line 553 in d2c031c

Comments on Pull Requests are considered non-blocking by default.

My sense was that you were speaking about a future world, and that the out-of-tree uses that prompted this PR were enough to not block it.

[flokli]

Bumping a project to wasm-bindgen[-cli] 0.2.104 showed this error for me:

"failed to find the __wbindgen_externref_table_dealloc function"

I don't have enough context into rust wasm world, but being able to simply use the _0_2_100 variant of this package got me unblocked on that front, so a +1 on keeping some versions in nixpkgs 😄