qooxdoo / qooxdoo-compiler

Compiler for Qooxdoo, 100% javascript
MIT License
36 stars 23 forks source link

Add a target for TypeScript type definitions #17

Closed johnspackman closed 7 years ago

johnspackman commented 7 years ago

Qooxdoo works well with TypeScript provided that there is a type definition file for the TypeScript compiler to use to discover the available types. The type definition file is a pretty straightforward dump of the class members with so this should be easy to output.

@pdfisk has provided mappings used by pdfisk/vista-client in qkwidgets/types, which in turn was based on work by @jbaron jbaron/qx-typed (qooxdoo.d.ts)

See also https://github.com/qooxdoo/qooxdoo/issues/9324

tcsaddul commented 7 years ago

Will you also release a similar ready-to-use qooxdoo.js (https://github.com/jbaron/qx-typed/blob/master/script/qooxdoo.js) ? This ready-to-use javascript file together with the definition file has made us work with qooxdoo right in our IDE similar to other javascript frameworks and libraries without ever running generate.py.

johnspackman commented 7 years ago

Yes, that would be the plan - but the compiler would also have to output definitions for other classes - eg contribs or any non-TypeScript classes in your project, so the compile pass would have to output an updated .d.ts file.

tcsaddul commented 7 years ago

Thanks for the info. This will enable qooxdoo to be used easily with Visual Studio and other IDEs.

adrelino commented 7 years ago

@johnspackman Do you mean qxcompiler will output multiple typing files for the whole application, not just for the core qooxdoo library? So in addition to qooxdoo.d.ts there will be one for the application that uses qooxdoo as a library and also for all the contribs it uses as defined in the Manifest file?

johnspackman commented 7 years ago

Yes, that would be necessary to support on the fly editor integration;

tcsaddul commented 7 years ago

As a typescript coder, I only want to be able to use Qooxdoo javascript UI framework just like any other javascript frameworks as a javascript file. Currently, I'm using two (2) files from https://github.com/jbaron/qx-typed namely:

Definition file:

  1. https://github.com/jbaron/qx-typed/blob/master/qooxdoo.d.ts

Javascript file:

  1. https://github.com/jbaron/qx-typed/blob/master/script/qooxdoo.js

The qooxdoo.js is about 1.51 MB which probably contains the basic parts from the qooxdoo library which is probably large but for me it's not a problem nowadays.

The benefits I get from this is that in Visual Studio, I can get intellisense and can use some other tools provided by it like ajaxmin, auto-compile after save (just refresh the browser), etc., It's just so easy to use it there. We Visual Studio users are accustomed to things that are automatically done by the IDE.

It would be nice if there is such an "official" release from the Qooxdoo team for such files. Maybe some kind of javascript file that is ready to use which contains just the basic components then there are other javascript files that can be added when they are needed i.e. for more advanced controls.

johnspackman commented 7 years ago

TypeScript support will be along soon - @JBaron (Peter) has just donated the code in jbaron/qx-parser which generates the definitions required for TypeScript integration. Peter’s qx-parser generates the qooxdoo.d.ts file that is used in his jbaron/qx-typed project and by others - with this integrated into qxcompiler, all classes in contribs and applications (ie not just the Qooxdoo framework) will be processed and automatically available for TypeScript.

Adding TypeScript support will help detect and prevent inconsistencies (ie errors) in the framework too - for example, Peter's found that in qx.core.Object is defined that removeListener returns a boolean, but in qx.html.Element that same method now returns an qx.html.Element. TypeScript will not allow the conflict - we can work around this by changing qx.core.Object.removeListener to return (we could also consider changing qx.html.Element to comply), but it's a conflict that wouldn't have been detected without stronger type checking.

Thank you @JBaron!

johnspackman commented 7 years ago

done in v0.1.19