Nokdu Posted June 2, 2014 Share Posted June 2, 2014 hi. been busy with work so it's been quite some time since i have checked up on phaser and it seems that a bunch of people have really worked on the typescript defs so i was wondering how complete they are. any ideas? Link to comment Share on other sites More sharing options...
rich Posted June 2, 2014 Share Posted June 2, 2014 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 More sharing options...
jouniii Posted June 2, 2014 Share Posted June 2, 2014 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. clark 1 Link to comment Share on other sites More sharing options...
jouniii Posted August 13, 2014 Share Posted August 13, 2014 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 More sharing options...
clark Posted August 13, 2014 Share Posted August 13, 2014 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 More sharing options...
clark Posted August 13, 2014 Share Posted August 13, 2014 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 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 More sharing options...
jouniii Posted August 24, 2014 Share Posted August 24, 2014 Thanks. As this seems to be "working" way to report errors, I noticed the Phaser.Timer.stop() definition is missing the clearEvents: boolean parameter. Link to comment Share on other sites More sharing options...
jouniii Posted October 24, 2014 Share Posted October 24, 2014 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 More sharing options...
rich Posted October 24, 2014 Share Posted October 24, 2014 It would be much much more helpful to submit fixes as PRs. Clark does an outstanding job on the TypeScript defs, almost entirely on his own, so every bit helps. Link to comment Share on other sites More sharing options...
jouniii Posted October 24, 2014 Share Posted October 24, 2014 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 More sharing options...
clark Posted October 24, 2014 Share Posted October 24, 2014 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 More sharing options...
xerver Posted October 24, 2014 Share Posted October 24, 2014 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 More sharing options...
rich Posted October 24, 2014 Share Posted October 24, 2014 Yes I do think it's something DocGen should handle eventually, but the custom interfaces will be a royal pain in the ass. Link to comment Share on other sites More sharing options...
clark Posted October 25, 2014 Share Posted October 25, 2014 This was a really interesting idea 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 More sharing options...
jouniii Posted October 27, 2014 Share Posted October 27, 2014 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 More sharing options...
Recommended Posts