Accessing Haxe JS compiled classes from TypeScript

[Malek]

Hi,

I'm currently giving a try to TypeScript, but I would like to use a number of Haxe libs I have. They're JS-ready, so I just compiled them to JS with Haxe 3.0.1.

My problem is that I want to use these JS libs from TypeScript. I made definitions for those, only to find out that I forgot a detail: Since it uses --js-modern (which is good), everything is enclosed, and I can't access the classes.

I would like to be able to do things like:

new my.real.package.CoolClass();

...from TypeScript, but my.real.package is not real. How can I do this ?
I've read about coupling @:expose and @:native, although I'm not sure that would fix my concern, but there are too many classes and packages for this to be feasible. And I suck at macros, if that's what you were going to suggest ;)

Any idea how I could achieve this ? Thanks!


By the way, the code example above could be declared in TypeScript as follows to enable type completion and type checking:

declare module my.real.package
{
    export class CoolClass {}
}

...although I wouldn't mind shorter aliases for the package, but I guess that's more of a question for the TypeScript community :)

[Malek]

I was able to partially fix the issue for packages. I just expose them, for example the JS would look like

$hxExpose(haxe, "haxe");

That function being defined by Haxe when there's an @:export somewhere in the code.
And that code supposedly opens automatic access to all of haxe subpackages and classes as well, under their real name. (e.g. haxe.ds.StringMap)

Is that correct ?

Although exposing all of Haxe's "global" types that don't have a package under their real name, like Type and Array, sounds cumbersome. Any idea or a simple macro to achieve this ? (I couldn't write one to save my life, that's why I modify the JS directly with $hxExpose)


Anyway since my libs use Type internally with custom classes made from TypeScript, that means I would have to add a proper __name__ to all such classes and I suppose a __class__ to, and who knows what else. It sounds very bug prone :(