[js] support outputting a typescript declaration file along with js output

[nadako]

As discussed in #5840 as well as today on IRC, it appears that there's need to use Haxe-generated modules from TypeScript environment. While it's totally possible (TS can interop with any JavaScript module through its externs mechanism), Haxe could simplify the integration process by generating a .d.ts file along with the .js output that will contain TypeScript declarations for the stuff being @:exposed.

I'm pretty sure this can be easily done with a onGenerate macro, so it probably doesn't even needs to be a part of JavaScript generator, and I'd like to experiment with that someday. Contributions are welcome, as always! :)

[nanjizal]

I would like inline haxe js support within Typescript to be also considered since it might be relatively simple fix.
For users experimenting with adding haxe js to typescript classes. The biggest rule seems to be that Haxe structures such as:

var HxOverrides = function() { };
HxOverrides.__name__ = true;

will error on the direct attaching of name the simple non-ideal but pragmatic workround:

var HxOverrides: any = function() { };
HxOverrides.__name__ = true;

Would this not be relatively simple to fix with addition of flag and some complier tweaks?

-D typescriptFriendly

I also found that I needed to comment out name on base classes.

      //String.__name__ = true;
      //Array.__name__ = true;
      //Math.__name__ = true;

I am not yet sure on the implications but also not sure of other approaches. In js_Boot.__string_rec
I had to change.

if(o.__enum__) {

which I hid using an old as1 trick which seems to work.

if(o['__enum__']) {

and also in the same function commented out initialization of k

//var k = null;

which is later used

for( var k in o ) {

[nanjizal]

In reality it seems putting haxe js in typescript is lot more tricky. Perhaps using this flag:"compilerOptions": {
"allowJs": true,
would have helped. But pretty unknown area at moment.

[nadako]

I still see no reason whatsoever for trying to compile haxe/js output with TypeScript compiler, given that it can already use any JS module in a perfectly typed way. It's pointless for a few reasons:

• haxe outputs js, meaning that the api will be pure js (all functions, all public, all untyped), which is not what one would expect when working from TypeScript.
• even if we manage to compile haxe/js through typescript it would simply be a ton of needless work, since TS compiler would mostly output it as is.

We don't have any resources to this meaningless work, so don't expect any changes regarding this.

What I actually started to work on though, is the typescript declaration generator, which will output a .d.ts file along with generated .js file, containing all exposed APIs in a typed typescript-friendly way.

It just occured to me that it's not only useful for TypeScript users, but also for plain javascript users that are working in Visual Studio Code and IDEA, because IIRC those can use typescript definition to provide IDE features for javascript as well.

[fullofcaffeine]

@nadako I think it does make sense. There are many frameworks that are based off TypeScript or ES6 and while I agree you can still target them with Haxe's ES5 output, it's much easier to just target at the ES6/TypeScript-compatible level. Playing at this abstraction level makes it easier to leverage the community efforts - docs, libraries etc.

A concrete example of that is Ember 2. Yes, Ember 2 can be used without Ember-CLI, but then it becomes a huge pain in the *ss and 99% of what you can find on the web about it is based off Ember CLI, its build system/pipeline, which by default uses Babel/ES6.

So I'd say at least an ES6 compatible target + ability to compile class to separate ES6 files would be great.

I think the work @kevinresol (🎉) did on his fork of modular-js(originally by @explorigin) now allows for easier integration with Ember-CLI, and that might be a good workround, albeit I'd love to see an official ES6 target as well.

Cheers!

[nadako]

I agree we should look into outputting per-module js files (shouldn't be that hard), but that's a different matter than trying to make haxe/js output compatible with typescript compiler.

[jgranick]

I would find this very interesting. It probably would not be possible to extend Haxe types using TypeScript, though, and I presume some argument types (enums, abstracts) might be a rougher?

I wonder about an "openfl.js", used from a TypeScript API if someone preferred

[nanjizal]

openfl.ts would give you lots more users that don't contribute code but ask millions of questions, certainly would not promote Haxe. Having a way to put Haxe created OpenFL ( especially away3d ) easily into Angular4 typescript component is probably important for some corporate take up, currently it's likely a real headache.

[nadako]

Alright, the discussion diverged here, so I'm going to close this:

• ES6 class output is now implemented
• Modular JS output is discussed #5831
• I started the d.ts generator and I think it should stay in a library. I don't have resources to work on this at the moment, but it looks like @elsassph is interested in developing it further \o/