Jump to content

How complete are the typescript defs?


Nokdu
 Share

Recommended Posts

Extremely complete. Clarke and others have done a stellar job on them, and continue to do so. I couldn't put a percentage on it, but I'd say right now finding mistakes or missing defs is the exception, certainly not the norm.

Link to comment
Share on other sites

Fairly good coverage. I've found some bugs or missing things. Although having some issues with WebStorm that it says "cannot find" something (and flags code red) even though the code browsing redirects correctly to d.ts and definitions are in place. Possibly something to do with the code checking and the phaser.d.ts has something WebStorm chokes with. Tried to invalidate WebStorm cache multiple times, but no luck. TypeScript compiler is happy, so haven't had time to investigate more.

 

Atleast one thing WebStorm doesn't like is the overriding of PIXI.Point with Phaser.Point.

Link to comment
Share on other sites

  • 2 months later...

I suppose the Typescript definitions for PIXI in Phaser are based on some other definitions? I upgraded 2.0.4 to 2.0.7 and remembered that I had to change the PIXI.Graphics definition as it's extending from wrong class. It is defined to extend from Texture, but correct is DisplayObjectContainer. This causes several properties (such as alpha and visible) to cause errors for typescript compiler.

 

Just asking, as not sure where such changes should be put to get into Phaser at somepoint.

Link to comment
Share on other sites

Yeah the Pixi Definitions were always external but obviously were required, but PIXI has no official.

 

 I originally added one by xperiments, but that was long outdated, and Nate Long who took over those Defs have been getting pull requests which are just broken plus when Pixi updates, only bits and pieces are added (vs just going to compare).   I took the last good Nate Long version and then went through Pixi (3 weeks ago) and updated it to match the newer Pixi and then added them to the TS definitions.  

Your fixed mistake probably ended up erased in this process.  I will take a note of this and try to fix it asap. 

If you find any troubles with the Defs, you can feel free to make a pull request on the dev/phaser.d.ts file.  You can even do this directly on the Edit page for quickness. 

https://github.com/photonstorm/phaser/blob/dev/build/phaser.d.ts

 

Link to comment
Share on other sites

Also please always grab the dev/ version (of the def)  

There has been a surprising lack of reported bugs these past few weeks so we are getting there :D

 

In this case, it appears I already caught this on the dev/ version 

 

export class Graphics extends DisplayObjectContainer

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

More missing/incomplete things. The Phaser.Game constructor does not allow to use the object config syntax and the IGameConfig is incomplete. Noticed this as I switched to the object config to pass enableDebug directly to constructor.

Link to comment
Share on other sites

Yes I though about it, but I try to avoid poking the code, as it would require testing and using the changed/dev code to which I have no resources right now. I dumped the custom mini phaser build idea (which I mentioned in email to you) because it will just deviate from the frequent release cycles and I'd rather just use the "official" release.

 

I'll look into PRs later.

Link to comment
Share on other sites

Thanks for letting me know.  I try to update every few days by looking at the commit history, and then updating as required.  I test against 5-6 games at work the next day and see if it builds and eventually it becomes a PR but I have not covered the entirely of the framework. (for example, I do not use the config object) so these things can slip by and I could do with some advice. 

 

 

When reviewing the code, I came up with this, is this pretty much correct?

interface IGameConfig {        enableDebug?: boolean;        width?: number;        height?: number;        renderer?: number;        parent?: any;        transparent?: boolean;        antialias?: boolean;        preserveDrawingBuffer?: boolean;        physicsConfig?: any;        seed?: string;        state?: Phaser.State;    }

Also I guess that the game should have 2 constructors but possibly even 3?
 

constructor(width?: number, height?: number, renderer?: number, parent?: any, state?: any, transparent?: boolean, antialias?: boolean, physicsConfig?: any); <-- currentconstructor(config: IGameConfig);//hmm not sure?constructor(args: ...any[]);

In any case, for sure it would still be helpful to PR on the dev branch any time you see an issue where the defs do not support your workflow correctly as it will all end up in the master within a couple of weeks.  This can be as simple as just using the GitHub edit button which I do sometimes to apply a patch for a few properties. 

Link to comment
Share on other sites

How easy would it be to generate the definition file at build time based on the json docs your tool generates? That way the work of documenting the library isn't duplicated in two places it all comes from one source, the doc comments. It also will stay as in sync as all the other docs are.

 

I guess the challenge would the the custom interface/enums that are written in the def file, but are just properties in the docs.

Link to comment
Share on other sites

This was a really interesting idea :D Especially with Richards latest work on the docs. 

But I thought about it lastnight and I think it would be a nightmare for a list of reasons. The bottom line just being that the process turns from a flat signature update once a week, to a big living parsing thing full of logic?

 

Any time saved and accuracy gained from using that process, would be quickly offset by the amount of "Any" types left by the process and those any types destroy the benefit of working with TS in the first place.  Especially when you consider that maybe 2 months from now, we will have Union Types which will get rid of the remaining "any" types in the definition.  These small TS improvements would result in pretty mammoth changes to a parser which would already take surely ages to write?

I think the likes of me and Jouniii need to do our part in a manual process as I can see no quicker way without the quicker way taking longer or being less accurate :(

Link to comment
Share on other sites

There aren't that many errors, although I seem to stumble across those all the time.. Sorry to bother your time clark for those. The proposed IGameConfig seems fairly complete. The open constructor arguments is interesting idea, but I think it may be a problem and make compiler to allow anything and then loose the type check benefits.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...