Merging externs from nodejs-std about haxe-js-kit HOT 14 CLOSED

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.

from haxe-js-kit.

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

from haxe-js-kit.

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

from haxe-js-kit.

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.

from haxe-js-kit.

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.

from haxe-js-kit.

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

from haxe-js-kit.

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.

from haxe-js-kit.

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.

from haxe-js-kit.

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)

from haxe-js-kit.

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!

from haxe-js-kit.

from haxe-js-kit.

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

from haxe-js-kit.

This function worked exactly in same way.

from haxe-js-kit.

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

from haxe-js-kit.