Add enum types for function parameters and return types

[ChristianIvicevic]

The adjusted typescript-tests unfortunately aren't great to assert the correctness of the generated types because a generated (a: number) => void could still be assigned to a (a: Foo) => void as the enum values in Foo are merely numbers. Therefore the tests currently only asserts that something structurally compatible is generated, but there is no check whether the expected enum is referenced. Classic TypeScript...

Fixes #2154

[daxpedda]

As far as I can tell our testing suite actually doesn't verify the TS output against something we write.

In any case, LGTM!

Could you add a changelog entry?

[ChristianIvicevic]

@daxpedda Please allow me some questions regarding your release process and testing/using pre-release versions of the crates.

1. What is your typical release cadence and is there any plans on when to release next?
2. I wanted to give my new changes a try and replaced my local dependency in my project with a path to my fork

wasm-bindgen = { git = "https://github.com/ChristianIvicevic/wasm-bindgen.git", branch = "2154-enums-in-function-signatures" }

Running wasm-pack yielded an error

thread 'main' panicked at 'unknown descriptor: 66', /Users/christian.ivicevic/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-bindgen-cli-support-0.2.87/src/descriptor.rs:164:22

This made me realize that there might be some mismatch with my globally installed version of wasm-pack. Is this expected? How can I properly use my fork until a proper release is available?

[daxpedda]

1. What is your typical release cadence and is there any plans on when to release next?

See #3530.

2. I wanted to give my new changes a try and replaced my local dependency in my project with a path to my fork

You can't without also installing wasm-bindgen-cli from the same custom fork.
cargo install wasm-bindgen-cli --git https://github.com/ChristianIvicevic/wasm-bindgen --branch 2154-enums-in-function-signatures -f (not sure if that -f is needed)

I'm not sure exactly how wasm-pack functions, but if it directly depends on a wasm-bindgen-* crate, it might need to be forked as well.

[ChristianIvicevic]

I'll give that manual override a try and if it doesn't work I'll wait until either the user in the linked issue has opened a release PR; otherwise, I'll look into it myself 😅 Thanks for pointing me to that issue.

[ChristianIvicevic]

Alright, your proposal to override the globally installed CLI (even I didn't had it installed previously) has worked and the output is correct. I'll stick with that until an official release has been pushed.

Thanks again for the support.

[Liamolucko]

Running wasm-pack yielded an error

thread 'main' panicked at 'unknown descriptor: 66', /Users/christian.ivicevic/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-bindgen-cli-support-0.2.87/src/descriptor.rs:164:22

Oh - this PR should've bumped the schema version (in wasm-bindgen-shared), since adding the name field to Descriptor::Enum means that wasm-bindgen's now incompatible with the previous version.

This is why you got this cryptic error message rather than a proper 'version mismatch' error.

[daxpedda]

Oh - this PR should've bumped the schema version (in wasm-bindgen-shared), [..]

I'm not totally familiar with how this works. I know that when we bump the version for a new release this will get a new schema version anyway.

As far as I understand it though, this PR didn't update the shared/lib.rs file, which is why the schema version was not bumped. Is there some other way to update the schema version or how is this supposed to be done?

[Liamolucko]

I'm not totally familiar with how this works. I know that when we bump the version for a new release this will get a new schema version anyway.

No, it's done manually. In principle, it's possible for the interface between the macro and the CLI to stay the same between two versions of wasm-bindgen, in which case the schema version shouldn't be bumped: it should be left as the previous version of wasm-bindgen.

Then you would be able to freely use, for example, version 0.2.87 of the CLI with version 0.2.88 of the macro. However since changes to the interface between the macro and CLI are very common, this hasn't happened in a long time - not since I've been involved, at the very least.

EDIT: never mind, this actually happened in 0.2.86! It still had had a schema version of 0.2.85, and so was compatible with the previous CLI/macro. There weren't any changes to the interface between 0.2.86 and 0.2.87 either, so it could have theoretically continued using 0.2.85 as well, but it got bumped anyway.

As far as I understand it though, this PR didn't update the shared/lib.rs file, which is why the schema version was not bumped. Is there some other way to update the schema version or how is this supposed to be done?

Yeah, in principle the schema version is supposed to just keep track of changes to the schema in that file (hence the name). But since the version mismatch system is built on top of it, it's morphed into a general way of keeping track of changes in the interface between the macro and the CLI.

[daxpedda]

Thanks, this makes sense to me now!

So how exactly do we bump the schema version if nothing changes in shared/lib.rs? Do we just bump this:

wasm-bindgen/crates/shared/src/lib.rs

Line 9 in bfe644f

pub const SCHEMA_VERSION: &str = "0.2.87";

It's a bit weird to me to bump the version there without bumping the version in wasm-bindgen in general.

[Liamolucko]

So how exactly to we bump the schema version if nothing changes in shared/lib.rs? Do we just bump this:

wasm-bindgen/crates/shared/src/lib.rs

Line 9 in bfe644f

pub const SCHEMA_VERSION: &str = "0.2.87";

Yes, and then update the hash.