Dan Korostelev

Also, can we get rid of js.html.compat stuff for nodejs somehow?

Yeah, we probably should do that for now and then deprecate it when 3.3.0 comes around

I did that, pls review!

@ncannasse > Also, can we get rid of js.html.compat stuff for nodejs somehow? Because any Buffer usage right now outputs a ton of unused compat stuff in the output js.

I don't think it ever worked actually, it was a run-time error instead. Good news is that I actually have a somewhat working `haxe.zip.Uncompress` for nodejs. Now I just need...

Could it be the case that your zips are not really compressed? Because then it bails out without trying to call `new Uncompress()`: https://github.com/HaxeFoundation/haxe/blob/39cdd730c4a1dfa629178a631be8e6baaec1441c/std/haxe/zip/Reader.hx#L198 And the default Haxe's implementation of...

I added documented private methods, but I'm worried about that `objectMode` option. It means that instead of strings and buffers, streams can read/write random objects which really goes contrary with...

I added a guideline on using `@:deprecated`, but we need to review our current externs and add that it where apropriate.

Isn't standard Haxe way `Std.is(obj, Array)` sufficient?

It's the same. However, we probably should provide Haxe-way examples in those deprecation messages indeed.