p5.js
p5.js copied to clipboard
processing
2.0: Add Typescript type exporting
This is based off of https://github.com/processing/p5.js/pull/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, solib/p5.rollup.jsdoesn't output any types, butlib/p5.rollup.esm.jsdoes.
@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.
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.
@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?
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.
