nodejs 6.x is here

[nadako]

Update externs to node 6.9 API and release hxnodejs 6.9.0

• assert
• buffer (also add tests for hx(To/From)Bytes methods)
• child_process
• cluster
• console
• crypto
• dns
• domain (deprecated)
• errors (most of them probably should be defined in haxe stdlib, not in hxnodejs)
• events
• fs
• globals (js.Node)
• http
• https
• net
• os
• path
• process
• punycode (deprecated)
• querystring
• readline
• repl
• stream
• string_decoder
• timers (those are actually global, but it may make sense to use proper haxe module/package)
• tls
• tty
• dgram
• url
• util
• v8
• vm
• zlib

[kevinresol]

Maybe wrap the functions in some #if (node_ver >= 6.0) so users can define the node version they are using with something like -D node_ver=4.24?

[nadako]

Yeah, I thought about it, but didn't really want to introduce a new define for that... Also, node.js docs aren't clear about what version introduced a function, so it's not that easy.

[back2dos]

I suggest doing this after v6 gets its LTS support (scheduled for October), unless there's some awesome API change that we could actually benefit from?

[mikicho]

Theres new about this? Somebody working on it? I can somehow help with that?

[back2dos]

Uhm, is there any reason to adapt to v6? Did it remove anything we should be aware of? Did it add anything useful?

[mikicho]

@back2dos This is LTS version, haxe version is 2 major versions behind and there is a tons of commits in the change log, IMHO we should update it.
How much time you estimate it will take to update it? maybe somehow generate a simple externs without and haxe optimization?

[nadako]

Alright, I'm gonna try updating externs to node 6.9.4 (latest LTS) and make a new release. A lot of stuff is already done in the master branch, but I need to go through the whole API and check if I forgot to add something. For that I'm going to make a checkbox list in the original issue, containing standard node modules and check them after updating externs.

[nadako]

maybe somehow generate a simple externs without and haxe optimization?

I don't think it's feasible to autogenerate externs of this quality, so we still have to maintain them by hand anyway, however we should research if we can use node.js API docs JSON file to generate "ugly externs". This would ease determining added/changed stuff by looking at diffs between generated externs as well as save some typing/copy-pasting if there'll some "almost ready" extern definition generated. I used that technique for Defold externs and it's really handy (https://github.com/hxdefold/hxdefold-extern-gen).

[back2dos]

I think it's still not clear why we'd want to do this. It puts us in the position of having to either ditch v4 or increase maintenance efforts and there should be a good reason to do either one of them. Having v4 in production is not uncommon.

It is certainly true that many of the things that were deprecated in v4 were removed in v6. In the end you can write Haxe code against this lib and so long as it gives you no warnings it will run on v6 just fine.

The question that remains open is whether or not there are any new APIs that one would want to use and glossing over the change logs there is nothing that struck me as crucial. But if there is anything in particular anyone might want or need, then let's please hear about it.

Otherwise I suggest not doing anything for the moment. According to nodejs' LTS plans v4 will have support until April 2018 by which time v8 will most likely have reached active LTS.

[nadako]

It is certainly true that many of the things that were deprecated in v4 were removed in v6.

Is it? I don't remember removing a lot of stuff while updating API, mostly adding which shouldn't be a problem.

[back2dos]

@nadako Can't find it again, but last I looked for migration guides I saw a lot of stuff being removed.

[nadako]

Ok, at this point it's time to upgrade to 8.x, as even 6.x will reach EOL this April.

[terurou]

#143

[nadako]

Let's close this then!