Add some typescript type definitions

[Jarred-Sumner]

The majority of this was auto-generated by running the following command:

npx typescript --build tsconfig.json

Then I went through and converted some of the any to a more specific type.

These are not exhaustive types, but it makes VSCode autocomplete much better.

Examples:

Before this, it wouldn't show me inline autocomplete for anything in noa and I had to check the API.md docs a lot

Might be nice to remove all the definitions for noa in the classes and then anything prefixed with an _. I sometimes use the _ functions though.

[fenomas]

Hi, this looks really useful! Way back in the day I used to get full autocomplete suggestions like this from VSCode even without typings, but it stopped working at some point and would be great to get back. Let me take this for a spin in my own env and check that I get the same results.

BTW: I generally keep all new dev in the #develop branch, so I'll edit this PR to base against that. Never tried changing the base of a PR before; hopefully it won't mess things up.

[Jarred-Sumner]

I think VSCode’s automatic autocomplete stuff works a little better with ES6 classes than Classname.prototype.methodName style - not sure why though.

I based it on master because there are no functional code changes but I can see why develop makes more sense

Feel free to edit as you see fit, though I’d feel bad if this just creates work for you

For types to be really nice, would also need to do it for ECS and the physics engine — but it would get pretty tricky with custom components. There’s probablyyy a way to do that in TypeScript but often being fancy with TypeScript or Flow ends up causing issues later. I personally only care about nice autocomplete and figured some types was better than not having them

As a side note, I briefly explored moving the terrain mesher stuff to a worker but it’s really complicated to do that. The best approach I can think of involves SharedArrayBuffer but Firefox / Safari wont like that. I might explore doing that later

On Thu, May 28, 2020 at 9:42 PM Andy Hall notifications@github.com wrote:

Hi, this looks really useful! Way back in the day I used to get full autocomplete suggestions like this from VSCode even without typings, but it stopped working at some point and would be great to get back. Let me take this for a spin in my own env and check that I get the same results.

BTW: I generally keep all new dev in the #develop branch, so I'll edit this PR to base against that. Never tried changing the base of a PR before; hopefully it won't mess things up.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andyhall/noa/pull/113#issuecomment-635755164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFNGS2SMMPW6UK7OMAMNJ3RT44MJANCNFSM4NJDWNWA .

[fenomas]

Yeah, we're in agreement. Getting good code hints is definitely worth adding a build step, but while somebody could certainly add manual annotations to say that e.g. ents.getPhysicsBody returns such and such a signature, I think it's the nature of the beast that the ECS is going to prevent automated tools from finding that signature automatically. Unless, say, there's a TS-specific way to declare such things in a function's jsdoc comment, or similar? As I'm not currently using TS I'm hazy on the details.

As for the mesher, yeah it should be possible in principle, but it's hairy (since there are already a lot of async steps in that process), and it's not obvious that it would wind up being a performance win. (Assuming the perf issue you were seeing with array merges is fixed, I mean.) So for those reasons I've been figuring it's best for meshing to stay synchronous for now.

[fenomas]

Sorry for the delay on this, for some reason I can't seem to get the nice code hints to show up in my local environment but I'll go ahead and merge this on the assumption that it's working somewhere, maybe it can be fixed later.