Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move haxe-js-kit under the Haxe Foundation umbrella #8595

Closed
fullofcaffeine opened this issue Jul 31, 2019 · 13 comments

Comments

@fullofcaffeine
Copy link

commented Jul 31, 2019

Sorry if this is not the right place to discuss this, but I think this is a relevant topic and directly related to Haxe.

The haxe-js-kit (https://github.com/clemos/haxe-js-kit) suite of externs is slowly falling apart, and started failing with Haxe 4. It's a pity because it's got a LOT of useful externs for popular js libraries and frameworks. I'd compare it to TypeScript's https://github.com/DefinitelyTyped/DefinitelyTyped.

Would it be possible for the Haxe Foundation to take ownership of it, together with hxnodejs or even, perhaps, merge both?

@back2dos

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

I don't think that's realistic to expect, as js-kit is barely used by anyone on the team, if at all.

I also believe that the time and energy required for this would better be spent on a proper dts2hx solution, as that means we can effectively outsource the tedious task of creating and maintaining externs.

@ncannasse

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

Haxe Foundation could host an official repository for community-contributed JS externs, so that there is a single point where various efforts are gathered instead of being split among each contributor own's repository.

But we would need a maintainer for this, that takes care of:

  • managing the PR and other contributions
  • inviting current scattered externs authors to contribute their work there
  • promoting the repo to users as a the default option (through changes in haxe.org website, etc.)
  • making releases, through haxelib and other if needed

Regarding dts2hx, given the actual complexity of TS, I think that even when done well this would not result in good quality Haxe externs, the best solution being to write them by hand to get the best out of Haxe own type system.

@nadako

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

BTW there's https://github.com/HaxeFoundation/hxnodelibs basically maintained by two guys, but I think it's only for node.js modules.

@ncannasse

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

@nadako

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

Regarding dts2hx, given the actual complexity of TS, I think that even when done well this would not result in good quality Haxe externs, the best solution being to write them by hand to get the best out of Haxe own type system.

I agree with that. Converting d.ts is possible to some extent, but some TS type system concepts are just not compatible with Haxe (e.g. mapped types, type queries, non-trivial unions/intersections).

@fullofcaffeine

This comment has been minimized.

Copy link
Author

commented Aug 1, 2019

Oh nice, I did not know hxnodejs included externs for Express among other frameworks. I'll look into it.

@fullofcaffeine

This comment has been minimized.

Copy link
Author

commented Aug 2, 2019

Oh nice, I did not know hxnodejs included externs for Express among other frameworks. I'll look into it.

Woopsie, I meant https://github.com/HaxeFoundation/hxnodelibs not hxnodejs. I had no idea hxnodelibs existed. Could we list them somewhere in the manual?

@fullofcaffeine

This comment has been minimized.

Copy link
Author

commented Aug 3, 2019

However, the express externs from js-kit are actually much more elegantly typed (in terms of typing completeness) than the ones in hxnodelibs (which seems to rely on Dynamic too much at the moment, just compare the express' Middleware.use func from both to have an idea of what I'm talking about). I'll keep using the ones from js-kit for now.

@kLabz

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2019

which seems to rely on Dynamic too much at the moment

That's the kind of impression I have (or had, at least) for many externs in js-kit. If it's not a false impression then I don't think I'd want those externs to be "officially promoted" or something.

@fullofcaffeine

This comment has been minimized.

Copy link
Author

commented Aug 3, 2019

@kLabz I haven't used any other externs from js-kit apart from the ones for expressjs and in this case, the externs in js-kit are more complete type-wise than the ones in hxnodelibs.

@kLabz

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2019

Yeah if my impression was (and still is maybe) justified it certainly didn't/doesn't apply to every externs in js-kit. I'm sure there are some (many?) high quality ones in there.

@fullofcaffeine

This comment has been minimized.

Copy link
Author

commented Aug 4, 2019

@ciscoheat used to be an active contributor to js-kit and his Haxe code is top-notch from my experience, so I'm sure there are other good gems there.

We're getting off track here though. From what I see, there's no chance of js-kit being ever moved / maintained by the HF officially. I think this issue could still be useful as a trigger [of further discussion] to either of the following routes, which are not mutually exclusive:

  1. Improve the hxnodelibs, perhaps rename it to js-externs or something and call for volunteers or hire people under the HF umbrella to help;
  2. Focus on getting a d.ts -> hx externs transpiler to generate good-enough externs. Maybe the quirks could be worked upon so that eventually the generated output would be high-quality, but even if it's not, it could still help save time on #1. See: https://community.haxe.org/t/wip-d-ts-hx-project/1761.
@Simn

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

If somebody wants to contribute, I'll be happy to give the required access to repositories. Until then, there's nothing actionable here, so I'll go ahead and close this.

@Simn Simn closed this Aug 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.