Clément Charmet
Clément Charmet
> It's not as simple as that. For example fetch and XMLHttpRequest have completely different APIs. And relying on the absence of require breaks down when you run on a...
Ultimately, I'll end up maintaining hundreds of packages, like you :D
> I'm not sure we're on the same page here. I guess not :p Say `js-kit` depends on both `js-kit-browser` and `js-kit-node`, and `js-kit-node` depends on `hxnodejs`, then depending on...
That would be great :) @matthijskamstra's tutorials are already a pretty solid starting point: http://matthijskamstra.github.io/haxenode/index.html I've been thinking about at least moving Haxe/JS related stuff to a dedicated Github organisation....
@fullofcaffeine Well I gave a shot at Haxe/JS + Yeoman here : https://github.com/clemos/generator-haxe-webapp Honestly, I've never really used it, because I finally found Yeoman pretty useless. But you're right, bootstrapping...
- neko is _not_ required :p
BTW, it seems @fantoine started something ;) https://twitter.com/ExternKit
I just think haxelib is pretty underrated. For instance, I wasn't so interested until @back2dos showed me some tricks. Maybe it was just inspiration rather than actual tricks. As for...
The problem is really with the dependency system, because all `haxe-js-kit` externs use it, and thus depend on the `npm.Package` modules. The reason is `haxe-js-kit` started as a rather small...
@kevinresol Thank you for your support :) But I believe `npm.Package` has no reason to be mandatory now we have `@:jsRequire`. Then if it becomes just a tool to handle...