haxelib release

[nadako]

We should make a release of hxnodejs at some point, but I'm still reluctant to do that because I haven't receive much feedback on general structure and API design of the library which will be harder to change after an official release.

So please guys, speak up now and feel free to mention other people who are already using hxnodejs.

@fponticelli @clemos @ncannasse @ousado @frabbit @eduardo-costa @tong @back2dos

[back2dos]

Well, there's two things.

1. as you have pointed out in #18, there's a couple of TODOs left. Particularly the "make this an abstract enum" stuff should be done before the release, because adding it later would be a breaking change.
2. I think I've talked about this elsewhere but I can't find it anymore. The Fs API could be made more typesafe. You can see a sketch here: http://try.haxe.org/#E9921 Maybe that is a bit over the top, given that one would rarely fiddle around with file descriptors in the first place, but if If you guys are ok with it, I would make a pull request.

---

I haven't looked through the source extensively, but it might be worthwhile detecting other places that lack type safety. We can still get rid of it later on, if it turns out too clunky. The other way round is not possible though.

[eduardo-costa]

I've been using it in a "real world" project.. with Http related features and it is rocking! Can't we release it under a beta or something?

2015-07-21 9:26 GMT-03:00 Juraj Kirchheim notifications@github.com:

Well, there's two things.

1.

as you have pointed out in #18 https://github.com/HaxeFoundation/hxnodejs/issues/18, there's a couple of TODOs left https://github.com/HaxeFoundation/hxnodejs/search?utf8=%E2%9C%93&q=todo. Particularly the "make this an abstract enum" stuff should be done before the release, because adding it later would be a breaking change. 2.

I think I've talked about this elsewhere but I can't find it anymore. The Fs API could be made more typesafe. You can see a sketch here: http://try.haxe.org/#E9921 Maybe that is a bit over the top, given that one would rarely fiddle around with file descriptors in the first place, but if If you guys are ok with it, I would make a pull request.

---

I haven't looked through the source extensively, but it might be worthwhile detecting other places that lack type safety. We can still get rid of it later on, if it turns out too clunky. The other way round is not possible though.

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

[image: Imagem inline 1]

[nadako]

Yeah we should review TODOs but wrt type safety I'm not sure. I remember we wanted to have good balance between typesafe and being able to copy-paste js code with minimal changes.

[fponticelli]

Same experience as Eduardo and I would agree that we can release with a 0.x label for a while.

Il giorno mar 21 lug 2015 alle ore 08:37 Dan Korostelev < notifications@github.com> ha scritto:

Yeah we should review TODOs but wrt type safety I'm not sure. I remember we wanted to have good balance between typesafe and being able to copy-paste js code with minimal changes.

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

[eduardo-costa]

Also me and other member have our own libs for nodejs libs bindings! Can we have a hxnodelibsor similar repository inside the Foundation so we can do a similar work like hxnodejs? It would be great to get some help to finish mongodb and other common libs! @HaxeFoundation/hxnodejs-team @HaxeFoundation/owners

[back2dos]

@nadako I understand what you are saying. There is of course no reason to make copy pasting particularly hard. That being said, the differences between Haxe and JS are there. Node's module system certainly doesn't make it easier (although I will say that it's module philosophy also decreases the need compared to frontend JS). My broader stance is that we can only seek that balance walking one way through the spectrum, so I think that it might be wiser to get all the room to maneuver we can get (with reasonable effort) and then let user feedback govern how far we go back. But I trust you on making that decision.

One thing I will add though is that in future versions we should be able to use @:from macro to allow consuming string literals as well, to reduce friction in copy pasting (and please the code golfers).

[clemos]

So I was cleaning up my repo today, and I've been trying to add hxnodejs as a git dependency in my haxelib.json. Unfortunately, it doesn't seem to be supported right now (see https://github.com/HaxeFoundation/haxelib/issues/238) Meaning that publishing a first version to haxelib is (at least IMHO) necessary for any third-party to rely on these nodejs externs. So it may be nice to publish a 0.0.1 to nodejs on haxelib (as @dionjwa proposed, in my understanding). BTW it would also be cool to ask similar project authors for removal / deprecation ? See http://lib.haxe.org/search/?v=node

[nadako]

With regard to version, I thought we agreed on syncing major/minor versions with node.js API version and using patch versions for hxnodejs releases (see https://github.com/HaxeFoundation/hxnodejs/issues/26#issuecomment-75970983)

[clemos]

I'm not too sure about syncing with node.js API versions ? It is very likely that we will need our own versionning for breaking changes, if only in case the compiler requires it ? For now, I think it's safer to start with 0.0.1, at least until we reach an "official" release.

[ncannasse]

I have just switched my only NodeJS project (CastleDB) from nodejs-std to hxnodejs, it works very well. I have commit js.node.webkit package and started sys package + Sys class implementation. If anyone (@dionjwa ?) wants to contribute to complete these that would be nice.

Also, @nadako, before releasing we should decide on the library name on haxelib. If I remember correclty, @dionjwa proposed that we take over http://lib.haxe.org/p/nodejs/ instead of adding one more nodejs library. That seems like a good idea. We could also ask @eduardo-costa if we wants to contribute to hxnodejs instead of his own nodehx lib.

Let's all join efforts into one single nodejs lib !

[eduardo-costa]

We that would be great! We hxnodelibs repo now! Em 05/09/2015 09:25, "Nicolas Cannasse" notifications@github.com escreveu:

I have just switched my only NodeJS project (CastleDB) from nodejs-std to hxnodejs, it works very well. I have commit js.node.webkit package and started sys package + Sys class implementation. If anyone (@dionjwa https://github.com/dionjwa ?) wants to contribute to complete these that would be nice.

Also, @nadako https://github.com/nadako, before releasing we should decide on the library name on haxelib. If I remember correclty, @dionjwa https://github.com/dionjwa proposed that we take over http://lib.haxe.org/p/nodejs/ instead of adding one more nodejs library. That seems like a good idea. We could also ask @eduardo-costa https://github.com/eduardo-costa if we wants to contribute to hxnodejs instead of his own nodehx lib.

Let's all join efforts into one single nodejs lib !

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

[dionjwa]

Yes, please use the 'nodejs' haxelib, that makes the most sense I think. Let me know who needs access and I'll add you as a contributor.

When that's in, I'll definitely help with filling in the stdlib.

[eduardo-costa]

Wouldn't delay even more we closing and releasing hxnodejs? Em 05/09/2015 12:33, "Dion Whitehead Amago" notifications@github.com escreveu:

Yes, please use the 'nodejs' haxelib, that makes the most sense I think. Let me know who needs access and I'll add you as a contributor.

When that's in, I'll definitely help with filling in the stdlib.

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

[eduardo-costa]

Guys! We already have the repo! https://github.com/HaxeFoundation/hxnodelibs

I proposed days ago we merge all our work there. My non-canon hxnodejs modules (like mongoor express) @dionjwa nodejs and other people partial work.

We should create each packages matching the npm name, like:

js.node.mongodb js.node.express js.node.multiparty js.node. ...

[eduardo-costa]

ok guys the kickoff was made! I transferred all libs I've made so far.. obviously all of them aren't following the established pattern.. but we will steadily correct it!

https://github.com/HaxeFoundation/hxnodelibs

[eduardo-costa]

@clemos @dionjwa Feel free to transfer the nodejs libs you have made externs and delete any of mine you think isn't complete enough versus your versions!

@ncannasse The syspackages really makes sense to be added in the canon hxnodejs haxelib. Regarding other npm libraries it is best to use this hxnodelibs project affiliated with the HaxeFoundation.

[dionjwa]

I like the distinction @clemos makes between e.g. 'js.node.Fs' and 'js.npm.Express'. There's a clear distinction at the package level between packages that are part of the Node.js distribution, and npm packages.

[eduardo-costa]

I'm ok with that too.. Em 05/09/2015 21:50, "Dion Whitehead Amago" notifications@github.com escreveu:

I like the distinction @clemos https://github.com/clemos makes between e.g. 'js.node.Fs' and 'js.npm.Express'. There's a clear distinction at the package level between packages that are part of the Node.js distribution, and npm packages.

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

[nadako]

@ncannasse I thought we've all agreed on the idea that hxnodejs (or whatever name we choose) should only contain core node.js api, so I'm not sure whether placing webkit externs there is a good decision, maybe it should be contained in our hxnodelibs repo? (also, those node-webkit externs are incomplete and undocumented unlike core node.js externs).

As for the name, to be honest anything is fine with me, but IIRC we named it hxnodejs to be in line with hxcpp, hxjava and hxcs, so I thought we'll have our nodejs based sys implementation in the std lib, but to use it, one would have to install hxnodejs (similarly to how one installs hxcs to target C#).

Anyway, I love the fact that hxnodejs is getting some attention and sorry I'm a little distracted right now (as I'm on vacation).

[ncannasse]

@nadako sorry for webkit, but I think it will be necessary anyway to make some specific changes in hxnodejs wrt node webkit implementation.

The reason is that in a pure NodeJS context you might want to have haxe.io.Bytes.BytesData be a NodeBuffer, so you don't have to copy from/to UInt8Array. OTOH if you're using NWJS (node webkit) you want to keep the bytesdata as UInt8Array because of the native browser APIs which uses it (WebGL etc.)

But I'll leave the decision to you and other maintainers, if you want to keep it there or have it into hxnodelibs.

WRT the name, choose also what is the best for you, I just want to make sure that the most complete/maintained library get first results when searching on haxelib :)

[eduardo-costa]

I think that NodeWebkit falls into the hxnodelibsrepo. I cloned and started it on the weekend, so those who have new NPM libs or better ones in comparison to the ones I have, feel free to start transfering there.

[clemos]

Anything new regarding the release ? I would like to clean my repo of all the js.node part very soon...

[nadako]

I don't know. I was working on updating externs to node.js 4.0.0 and it's not done yet, but I have a feeling that we'll never catch up to it, so maybe we should just make a "alpha" release and then update it with fixes/changes.

I'm still not sure what to do with the Bytes situation (Buffer vs Uint8Array as @ncannasse described), maybe we could make a define flag for that, however that way we have to duplicate original Uint8Array implementation from Haxe, which sucks. I'm still thinking whether the best way to handle it is to just move the haxe.io/sys implementation into Haxe std lib like this:

#if js
#if nodejs // or some other flag
...nodejs impl...
#else
...browser impl or error...
#end
#end

[clemos]

Yeah I still think it would be cool to make a release of the current pre-node 4.0.0 version, so we can all link to it. Also, it would certainly bring back some new attention to the project.

[back2dos]

On Thu, Sep 17, 2015 at 2:24 PM, Dan Korostelev notifications@github.com wrote:

I'm still not sure what to do with the Bytes situation (Buffer vs Uint8Array as @ncannasse https://github.com/ncannasse described), maybe we could make a define flag for that, however that way we have to duplicate original Uint8Array implementation from Haxe, which sucks.

Maybe using 4.0.0 is a good idea then? There release notes ( https://nodejs.org/en/blog/release/v4.0.0/ ) say "(Node's Buffer is now backed by Uint8Array)".

Best, Juraj

[ncannasse]

@back2dos ah, great news ! problem solved :) hopefully NodeWebkit will upgrade to node 4.0 soon as well

[nadako]

@ncannasse Have you tried Electron btw? How does it compare to NW?

[ncannasse]

@nadako didn't knew about it, might be better I'll give it a try one day

[tong]

Here is a comparison: https://github.com/atom/electron/blob/master/docs/development/atom-shell-vs-node-webkit.md Franco has already written externs for electron: https://github.com/fponticelli/hxelectron

[eduardo-costa]

Just remembering.. Let's focus the externs of nodejs libs in this repository https://github.com/HaxeFoundation/hxnodelibs So we keep hxnodejs only with canon stuff

[ncannasse]

Up ?

[kevinresol]

I really wish to see a release. Currently using Haxe/Nodejs and js-kit lib for a professional project.

[tong]

I am currently using it a lot and good with a release.

[ncannasse]

42 is definitely a show stopper for a release, we can either release without haxe.io/sys packages, or find a way to fix this.

[kevinresol]

I prefer a release first, even just 0.0.1, so that other lib can start using it

[nadako]

Okay, it's on haxelib now.

[fponticelli]

YAY!

[kevinresol]

:+1:

[clemos]

gg wp :)