hxnodejs distribution

[nadako]

how are we going to distribute this?

as a part of std lib:

• out-of-the-box support which is very appealing to users (just install haxe and write stuff)
• more support because (because we have to maintain our std lib)
• inability to provide timely updates because haxe releases so rarely

as a haxelib:

• easier to provide small updates and fixes
• smaller and easier to maintain std lib
• users have to install the library and thus learn about haxelib first (it could be installed by default tho)
• possible desync and confusion with haxe/hxnodejs/node versions

also there seems to be some must-have node.js modules that everyone basically have in every app (e.g. express and its dependencies) - maybe we should also provide high-quality officially supported externs for that?

also what about nodejs Sys/sys implementation? it's not possible to implement full support because node.js lacks sync API that is required for haxe, but we could at least provide filesystem and Sys stuff.

[eduardo-costa]

Haxelib installed in the first Haxe install?
So the next updates can be provided faster.

[Simn]

We should treat this just like hxcpp, hxjava and hxcs.

[fponticelli]

I started working on the express externs here: https://github.com/abedev/hxexpress
I don't think we should cover those libraries unless we can commit to them 100%.

[eduardo-costa]

express was discussed some time ago.
I think we decided to keep hxnodejs focused only on node.

[fponticelli]

Sorry, I didn't notice how old the thread was ... I am glad about the decision :)

[nadako]

I'm wondering about version numbers. I'm not too familiar with semver, so maybe @fponticelli can help me here.

What I'm thinking would be good is to make hxnodejs versions match node.js versions (so 0.12.0 for the latest node.js release), but we also need to make releases that fix mistakes in the externs. How do we handle that version-number-wise?

[fponticelli]

I like the idea of pairing the version of the library with the node version
even if it doesn't really match the spirit of semver. If you decide to go
in that direction you can use the build to mark the "externs" progresses.
So something like v.0.12.0.p1 ... not sure how that plays with haxelib :(

Il giorno Wed Feb 25 2015 at 7:31:42 AM Dan Korostelev <
[email protected]> ha scritto:

I'm wondering about version numbers. I'm not too familiar with semver, so
maybe @fponticelli https://github.com/fponticelli can help me here.

What I'm thinking would be good is to make hxnodejs versions match node.js
versions (so 0.12.0 for the latest node.js release), but we also need to
make releases that fix mistakes in the externs. How do we handle that
version-number-wise?

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[nadako]

Looking at the haxelib's semver code here (https://github.com/HaxeFoundation/haxelib/blob/master/src/tools/haxelib/SemVer.hx#L78), it seems there's no support for that .p1 thing, only -alpha.1. But I think we could just pair major/minor versions with node.js and use patch versions for our internal releases, as node.js API doesn't change between patch versions.

[fponticelli]

sounds very reasonable

Il giorno Wed Feb 25 2015 at 7:42:57 AM Dan Korostelev <
[email protected]> ha scritto:

Looking at the haxelib's semver code here (
https://github.com/HaxeFoundation/haxelib/blob/master/src/tools/haxelib/SemVer.hx#L78),
it seems there's no support for that .p1 thing, only -alpha.1. But I
think we could just pair major/minor versions with node.js and use patch
versions for our internal releases, as node.js API doesn't change between
patch versions.

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[kevinresol]

One year anniversary for this thread 😕
Shall we have an alpha release first? So at least it is downloadable from haxelib and users can start playing around

[nadako]

Okay, I think we've decided here:

• release separately as hxnodejs lib (see overriding standard types #42)
• version using major.minor versions for compatible nodejs version and use patch version for the library releases (i'm still not sure how that'll work out, but I guess it's fine)