4.0.9 to 6.9 in Haxe RC2 - Buffer of undefined

[hoseyjoe]

We have a nodejs application coming out of Haxe code. Somewhere down at line 22000 in our JS Output we have a
require("Buffer").Buffer
We updated hxnodejs to 6.x. Now with our NodeJS server we are getting a "TypeError: Cannot read property 'Buffer' of undefined"

Line 4 of the JS output has
var require = (function(r){ return function require(m) { return r[m]; } })($s.__registry__ || {});
Commenting this out allows the server to run. It probably will error on anything requiring Buffer...but that isnt tested

[Gama11]

Hm.. well, haxe-language-server uses Buffer appears to work fine with latest hxnodejs and Haxe. Would be helpful to have a way to reproduce this.

[hoseyjoe]

ok. I was able to create a mostly small app. I believe it is the inclusion of haxe-modular that creates the issue. Maybe this should be a haxe modular issue?
Server.zip

[hoseyjoe]

It works with haxe modular and 4.0.9. it was the change to hxnodejs to 6 that caused the issue to arise

[Gama11]

I believe it is the inclusion of haxe-modular that creates the issue.

@elsassph Thoughts?

[hoseyjoe]

It maybe unrelated but through Googling it appears require("") will be undefined with circular logic. A requires B which then requires A...

[elsassph]

Looks like a Modular bug yes because it stubs the require function in the browser.
Can you try adding -D nodejs? Was it removed from hxnodejs?
Clearly the stub should be improved to not override one in scope.

[Gama11]

-D nodejs was not removed. However, it's now no longer defined in macro context. This is to make sure you can use it like a regular target define, and don't have to check for both js && nodejs everywhere.

[hoseyjoe]

Adding -D nodejs appears to fix the issue on our end. Also I'm not sure modular is needed on the backend, for us at least, and will probably remove it.

[elsassph]

Hmm mot sure to understand the macro context thing. We used to have both js and nodejs defines.

Should I change the tests to hardcode #if hxnodejs?

[Gama11]

The problem was that if you had code like this:

#if cpp
// use cpp specific API
// (other targets)
#elseif nodejs
// use some node specific API
#end

..it would fall apart if the macro context comes across that. Effectively, it meant that the nodejs define was pretty much useless on its own, since to make sure you're actually on the nodejs target, you had to check for (js && nodejs) - otherwise you might merely be on eval, with the hxnodejs lib included. Now it behaves more like a proper "target define".

For your use case, #if hxnodejs should work. Context.defined("nodejs") might work too?

Surprised this hasn't come up earlier, this change happened quite a while ago and people have been using dev versions of hxnodejs for ages before the new Haxelib release. :)

[elsassph]

It's getting OT but how are you supposed to know it's server or client side JS? Sounds like I need to assume hxnodejs.
Which reminds me there were discussions about the Electron context causing issues.

[Gama11]

I'm not sure I follow. It's not like nodejs replaces the js define, that's still there of course.

[Gama11]

Looks like Context.defined("nodejs") works, but depends on macro execution order. So this works:

-lib hxnodejs
--macro Main.foo()

While this doesn't:

--macro Main.foo()
-lib hxnodejs