-
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
Getting the no-modules
TypeScript *.d.ts
Files Working
#2396
Conversation
This aims to be the first step at getting the d.ts file working. The reason for this is that the TypeScript (3.8.3) compiler ignores "declare" statements if it sees "export" statements. Not sure if that's a bug in TypeScript. Either way, all I really did here was scan through all changes to `self.typescript` and see if it could add an "export". The only big wild-card I found was the `typescript_custom_sections`, which I think exists just to let `wasm_buildgen` annotations to add extra typescript to the document?
This is a bit crude, basically anything before the "init" block is put in this namespace. Hopefully this works in general. I'm not 100% sure yet.
Based on the output JavaScript this seems to be how it works.
Then traced through the other instances where I'd switched `export` to `declare` and switched them over if they were going to end up in the same `wasm_bindgen` namespace.
Thanks for this! Would it be possible to add tests for this specifically too? I believe Other than that the changes look great here! |
Ok, I'll see if I can setup some tests. |
I'm hoping that `run.sh` is what the CI runs.
Ok, the tests should now try to build with |
Thanks! For the test though it looks like this just asserts that it parses correctly, but could some JS be written which consumes the wasm-bindgen generated JS? That way we can ensure the expected idioms all typecheck and information is all listed as we'd expect. |
…TypeScript. So now the `*.d.ts` files will actually be build against (modified) `*.ts` files. This should be a better check than only verifying TypeScript doesn't fail when given just the `*.d.ts` files (what it did before). Note that the `*.ts` files are generated from the `*.ts` files in `src` using some fairly simple Regular Expressions. This skips checking the `typescript_tests_bg.wasm.d.ts` file, as I have no experience using that.
@alexcrichton The tests now build the (no-modules) |
Any chance this will get merged? It should be ready to review. |
Er apologies I missed that this was ready! I'm not sure what the test is doing though, what's with all the |
The testing changes try to re-use the existing typescript testing that have been setup for the "--target web" case. The
I was aiming to re-use the existing tests rather than writing up new ones, as I'm not too well versed in all of the binding generation functionality. (The project that got me to set this up really only used "call Rust from JS" and "call JS from Rust" with fairly simple argument/return types.) I also figured it'd be nice to not have separate files for testing "--target web" vs "--target no-modules". |
Ah I see, thanks for clarifying! Sounds good to me! |
Partially based on #693.
The current
--target no-modules
TypeScript declaration files don't correctly describe what the JS interface looks like:extern {
and#[wasm_bindgen]
are stored in thewasm_bindgen
namespace, but the TypeScript declaration files don't put them in any namespace.export
d. As of TypeScript 3.8.3, that meant it wasn't visible. So those were switched over todeclare
statements.This tries to fix the above by adjusting the output for just
no-modules
. It also removes the bunch of extra spaces at the end of the declaration file.As an example, the output went from:
To:
Testing
When I ran
cargo test
andcargo test --target wasm32-unknown-unknown
on my local setup, it reported all passes.