Add rudimentary Typescript typings#116
Conversation
* Doesn't work with inline `/* @type */` docs
|
Thanks for looking into all of this! I'm still not yet sure if I want to incorporate any TypeScript related stuff into the project, but I'll keep this PR open as I continue to consider it. There's a good chance that if I do decide to go the TypeScript route, I'm just going to migrate everything all at once :) |
|
Thanks for considering the PR. This approach retains all of the JS! At the same time acting as a stop gap between now & when the whole project migrates to TS for existing TS ( The only real TS stuff added is in the form of JSDoc comments, & that only covers the user-facing API, enough so that TS is able to extract declarations. |
|
Hey, I would also really like to see types in this. I am currently trying to implement some kind of vr-holodeck application and I am a bit lost without types and without documentation. |
|
Any updates on this? Typescript would be a huge benefit for this library in my eyes... |
|
I wish so too.... Still waiting for it |
|
need Typescript, please |
Hello! Thank you for the project.
Fixes #52
Overview
I noticed discussion over at #52 about typings support, & personally I would benefit a lot from its ease-of-use. So, I went ahead & implemented it into the build process, (& taking note of the discussion thus) without migrating the entire project over to the Typescript language. This was done with some explicit JSDoc types over annonymous functions that TS didn't like, as well as some general improvements such as copying over the in-code explanations out for consumers to read inline.
Notes
_because by default Typescript exports all JSDoc@typedefs. In theory you should be able to assign the types to an unused variable & reference it withtypeof, but I couldn't get it to work.@types/three, which will now have to be tracked to thethreeversion associated with the package. (Maybe consider making it a peer dependency in the future?)valid-jsdoc, since it didn't like doing typings inline within the constructor. I assume this can be workarounded by doing@propon the class's JSDoc, but imo it becomes hard to trace when doing new implementations.