-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add enum types for function parameters and return types #3647
Add enum types for function parameters and return types #3647
Conversation
5199ea0
to
5a3cfa4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@daxpedda Please allow me some questions regarding your release process and testing/using pre-release versions of the crates.
wasm-bindgen = { git = "https://github.com/ChristianIvicevic/wasm-bindgen.git", branch = "2154-enums-in-function-signatures" } Running wasm-pack yielded an error
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? |
See #3530.
You can't without also installing I'm not sure exactly how |
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. |
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. |
Oh - this PR should've bumped the schema version (in This is why you got this cryptic error message rather than a proper 'version mismatch' error. |
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 |
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 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.
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. |
Thanks, this makes sense to me now! So how exactly do we bump the schema version if nothing changes in wasm-bindgen/crates/shared/src/lib.rs Line 9 in bfe644f
It's a bit weird to me to bump the version there without bumping the version in |
Yes, and then update the hash. |
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 inFoo
are merelynumber
s. 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