Merging externs from nodejs-std

[as3boyan]

Seems like your node.js externs is getting updated and improved very fast.

Currently I use this fork:
https://github.com/as3boyan/HIDE/tree/master/libs/nodejs-std

Main repo(https://github.com/dionjwa/nodejs-std) doesn't get updated, so maybe it's a good idea to add some basic externs for node modules(mv, mkdirp, walkdir, watchr) to your repo? I could add it if you like this idea. And node-webkit externs from there, licensed as BSD.

[clemos]

Well, I'd be happy to have more externs (though I don't really use those you mention), as well as node-webkit.
From what I can see, including node-webkit, for instance, would require a bit of work to embrace the conventions used in node-js-kit (implement npm.Package.Require, no __init__ or other tricks, etc).

As for nodejs-std, it's a pretty different project IMHO.
I personnally don't use std on node.js, and I'm honestly not too interested about it, so I wouldn't really be able to maintain it properly.
Also there was this discussion about merging it to haxe std:
HaxeFoundation/haxe#2784 (comment)
So I'm not too much in favor of merging it to my repo.
It might be build on top of it, though.

[as3boyan]

I am not using std too, but would like to have some module externs in one place.

[clemos]

I agree for the externs part, feel free to merge some to my repo;
Let me know if you need any help.

[as3boyan]

Seems like externs for Mv, mkdirp, watchr, walkdir could be similar to https://github.com/clemos/haxe-js-kit/blob/master/js/npm/Connect.hx, because they work like this

walkdir = require('walkdir');
walkdir(path);

and etc.

[as3boyan]

I plan to move Mv, mkdirp, watchr, walkdir, remove to js.npm and externs for atom-shell to js. Is it ok?

I want to make ultimate Swiss knife.

[as3boyan]

Also what do you think about switching to @:jsRequire as replacement for npm.package.require?

[clemos]

Hi,
I don't know atom-shell in details, but I would prefer it in js.npm as well. Now maybe there's a reason why you want to promote it to just js ?
As for @:jsRequire, I don't really see the advantage over my system for now: it doesn't handle package.json generation or library versions, for example.
At some point, it may be interesting to replace the @:native trick with @:jsRequire, but it can be done internally.

[as3boyan]

Now maybe there's a reason why you want to promote it to just js ?

Because it's not available on npm that's is why i put it there. And it's kinda browser API and etc...
I can move it to npm.

it doesn't handle package.json generation or library versions, for example.

I didn't knew that.

But I have noticed that npm.package.require does generates something like this:
App || require('') everytime I try to access some field, which is not very good I think.

[clemos]

Ok, then maybe js.atomshell makes sense ?
Once again, I've quickly looked at atom-shell docs and your haxelib project, but am still unsure about what will really be there ;)
As for Pack || require('pack'), I've indeed removed it, as it doesn't make sense
(as it turns out, require('pack') returns a unique reference across calls)

[as3boyan]

Once again, I've quickly looked at atom-shell docs and your haxelib project, but am still unsure about what will really be there ;)

It's not on github yet.

As for Pack || require('pack'), I've indeed removed it, as it doesn't make sense

Great, thanks!

[as3boyan]

[as3boyan]

I'm not sure why I'm getting this. Maybe I should switch to more stable version of Haxe

[as3boyan]

This function worked exactly in same way.

[clemos]

This should be fixed, now.
Callback<Void> has never really worked, it's now replaced by Callback0