NodeJS Libraries

[eduardo-costa]

Can we create a new repository called hxnodelibs so we can do the same work adapting the most common nodejs libraries? Some like:

• mongodb
• authom (git, google, FB, twitter, OAuth login system)
• express
• NW.js (node desktop apps)
• peerjs (webrtc)
• socket.io (websockets)
• ws (websockets)

I have some work done in those libs, so I'm open to share things like I did in the start of hxnodejs This is something I would advance in the long run. But some help from the community would be cool!

[clemos]

Why don't you just contribute my haxe-js-kit project ;) ?

[eduardo-costa]

Just following the "pattern" of unifying things inside HaxeFoundation, just like what was done with hxnodejs. If you want we can put both our repos inside a hxnodelibs!

[eduardo-costa]

Also we should follow the hxnodejs extern guidelines in this new repo.

[eduardo-costa]

What you think @waneck ?

[clemos]

I don't think it's such a good idea to have an official repo for third parties / NPM library externs. The point of hxnodejs was to officially support node.js as a target, and eventually to provide a basis to implement some kind of standard library on top of it. I think the project should stick to it, at least for now, so it can be released.

[clemos]

Also, about following extern guidelines, I'm trying to follow most of them. BTW, it would be useful to complete the guidelines document.

[eduardo-costa]

I agree too.

What I'm saying is we create a new repo named hxnodelibs. Javascript has externs for JQuery, so we can do the same for nodejs.

2015-06-23 5:30 GMT-03:00 Clément Charmet notifications@github.com:

I don't think it's such a good idea to have an official repo for third parties / NPM library externs. The point of hxnodejs was to officially support node.js as a target, and eventually to provide a basis to implement some kind of standard library on top of it. I think the project should stick to it, at least for now, so it can be released.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/hxnodejs/issues/39#issuecomment-114405770 .

[image: Imagem inline 1]

[Simn]

I don't really mind which repository these externs are in. We started hxnodejs in order to unify existing approaches. I'm fine with @clemos keeping haxe-js-kit as long as we watch out for people starting a similar effort, in which case we should try to channel them towards collaboration.

[eduardo-costa]

I think that moving to Haxe Foundation is valid in order to center core features like nodejs and its libraries around an official channel.

2015-06-23 5:43 GMT-03:00 Simon Krajewski notifications@github.com:

I don't really mind which repository theswe externs are in. We started hxnodejs in order to unify existing approaches. I'm fine with @clemos https://github.com/clemos keeping haxe-js-kit as long as we watch out for people starting a similar effort, in which case we should try to channel them towards collaboration.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/hxnodejs/issues/39#issuecomment-114408571 .

[image: Imagem inline 1]

[clemos]

I don't quite agree with having JQuery (and SWFObject) in the standard library either :)

First, I think it's difficult to keep up-to-date / complete there. Also, the extern has dirty hacks and doesn't comply our guidelines at all.

Secondly, more and more people question the omnipresence of JQuery, these days. IMHO, having the extern in the standard lib, thus encouraging its usage, definitely gives a bad signal to most "modern" JS developers.

Finally, the mechanism of including JQuery / SWFObject using a macro / compiler flag should also be removed / deprecated, in favor of a defacto standard such as npm + browserify, that should be officially encouraged.

[Simn]

@eduardo-costa: Perhaps, but that should really be up to the principal maintainer. There's no point in moving it to HaxeFoundation if there's nobody to properly maintain it.

@clemos: I agree. In fact, I already had a pull request open to remove these files but there was some confusion about that.

[eduardo-costa]

Of course. I'm saying this because I liked to move hxnodejsfrom my repo to the Foundation and I think it makes more available for contribuition.

2015-06-23 5:51 GMT-03:00 Simon Krajewski notifications@github.com:

@eduardo-costa https://github.com/eduardo-costa: Perhaps, but that should really be up to the principal maintainer. There's no point in moving it to HaxeFoundation if there's nobody to properly maintain it.

@clemos https://github.com/clemos: I agree. In fact, I already had a pull request https://github.com/HaxeFoundation/haxe/pull/4074 open to remove these files but there was some confusion about that.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/hxnodejs/issues/39#issuecomment-114410084 .

[image: Imagem inline 1]

[Simn]

I know, but then hxnodejs is moving really slow these days and I think the fact that responsibility is shared between several people is partly to blame. It's no longer "your" project and that can have a drastic effect in the open source world, unfortunately.

[eduardo-costa]

Probably. Still making it more public allowed to reach this stage. I would take months to come up with the externs guidelines and completion of the API.

2015-06-23 5:55 GMT-03:00 Simon Krajewski notifications@github.com:

I know, but then hxnodejs is moving really slow these days and I think the fact that responsibility is shared between several people is partly to blame. It's no longer "your" project and that can have a drastic effect in the open source world, unfortunately.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/hxnodejs/issues/39#issuecomment-114411092 .

[image: Imagem inline 1]

[Simn]

Yes there are always two sides of the coin of course. There was some great initial momentum, but that is gone now and we haven't reached a proper milestone (haxelib release?) yet.

[nadako]

The main reason why I slowed down working on hxnodejs is that I'm not sure how good these externs are from the usage perspective and I'm not sure whether the structure/naming convention/etc is good.

I reckon we don't want to add breaking (from the extern side) changes after we release so we should make sure these externs are designed good before making the first release.

OTOH we could just name it alpha and release into wild to get feedback for further action.

Also, it was kind of waiting for Haxe 3.2.

Since node 0.12 was released, I added some of its API to hxnodejs, but I haven't done a full review.

[eduardo-costa]

@Simn Hey! Can we have the hxnodelibs repo created? I want to transfer and start adapting the libs like we did to hxnodejs!

[Simn]

I have to ask: Shouldn't we finish and release this library before we start something new?

[eduardo-costa]

I don't know what is missing in the hxnodejs right now. But I'm enrolled in a project where I use it and also have npm libs with preliminary extern classes. I would like to transfer them to this hxnodelibs repo while I'm at it and gradually fill it. Considering that this will be an eventual task, we could anticipate it, no?

[Simn]

done

[eduardo-costa]

Thanks @Simn I'll gradually add stuff this week!

[clemos]

I don't think it's a good idea, as we already struggle to merge existing npm externs into one of the existing projects (see https://github.com/clemos/haxe-js-kit/issues/59)

[eduardo-costa]

I know there is haxe-js-kit, as I also have one of mine we should do the same as hxnodejs and put it under Haxe Foundation and standardize the location of these resources. Users then should locate each npm libs as js.node.mongodb js.node.authom js.node.mongoose js.node.multiparty ... But only the externs, without macros or anything. Users themselves should handle the package installation.

[clemos]

I still think this work should remain third-party, until some issues are solved, at least. For instance, I don't agree with js.node namespace, as a lot of npms work on both client and server (socket.io, ...) For the credibility of HF, I think it would be better to not "officialize" things until proven solid enough. I still think it should focus onhxnodejs for now, so we extern maintainers can further clean and standardize our libs.

[eduardo-costa]

Well we don't need to announce and make hxnodelibs available. Even hxnodejs isn't really "available" but the repo is there. We can work on it, letting the users know that it isn't even on alpha. I don't think it will hurt to work in the final location as soon as possible. Regarding namespaces we can settle this before starting.

I agree that some libs can be used on client side. We could agree on something js.npm or use js.html itself e.g. js.html.socket_io

[eduardo-costa]

The kickoff was made here https://github.com/HaxeFoundation/hxnodelibs