Skip to content
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

2.0: Add Typescript type exporting #6972

Open
wants to merge 2 commits into
base: dev-2.0
Choose a base branch
from

Conversation

davepagurek
Copy link
Contributor

@davepagurek davepagurek commented Apr 14, 2024

This is based off of #6777, so you can see just the new Typescript bits here: https://github.com/davepagurek/p5.js/compare/initial-conversion-script..tsc

So it adds an npm run types command which generates, currently, types/p5.rollup.esm.d.ts. The reason for the name is that:

  • Typescript does not work on our regular source files since we add to the same prototype across multiple files, and this does not seem to be something Typescript supports. However, the prototype syntax isn't bad on its own, so our rollup files are ok!
  • Typescript doesn't seem to export anything if there aren't any exports, so lib/p5.rollup.js doesn't output any types, but lib/p5.rollup.esm.js does.

@davepagurek
Copy link
Contributor Author

TODO: make a thing to generate global mode types

@limzykenneth
Copy link
Member

@davepagurek Just trying this and found a rather significant roadblock. The generated d.ts file does not include types for the math module because of the new module syntax encapsulating the class methods in a function that tsc assumes is not public, so its documentation was not read nor its types generated.

I'm trying to find ways to work around it but couldn't find any so far. It would be great if there is a way to generate directly from JSDoc only and for tsc to not try to read the code itself.

@davepagurek
Copy link
Contributor Author

Manually generating the .d.ts format from Documentation.js and bypassing tsc entirely would work. It's similar to what the current external p5.js types project is doing, but maybe a bit easier because of the more structured output we're getting now.

@limzykenneth
Copy link
Member

@davepagurek Do you think it is worth writing this conversion or a conversion that goes directly from Documentation.js to zod for FES would be a better approach? Also I have less than perfect confidence in the longevity of Documentation.js as a project, we don't need to review things now especially we have a working Documentation.js -> YUIDoc converter, but to consider a bit of future proofing, would anything change in this case?

@davepagurek
Copy link
Contributor Author

For FES probably Documentation.js output to Zod is easiest? I talked to @sproutleaf some more about it this week and that seems like maybe the easiest way forward. If in the future we also add .d.ts generation, if we do that from the Documentation.js output too, it's still kind of nice having everything come from the same source, but we aren't blocked on having that.

@limzykenneth
Copy link
Member

Yeah, sounds good. Let's go with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Proposal
Development

Successfully merging this pull request may close these issues.

3 participants