-
-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use of -D nodejs
#4524
Comments
I'm not really fond of the Second of all, I think one shouldn't check for The APIs are fully orthogonal and it would be cool to just be able to select them. With nodejs that works, because as a haxelib, it is an opt-in by nature. Similarly, it would be great if one could opt-out of browser specific APIs (e.g. with There's always the possibility of having a 3rd API become established. The issue with |
@back2dos Am I correct that you support (4) as shown in the table? For the #if nodejs_only
// implementation that is specialized for node
#elseif xyz_only
// implementation that is specialized for xyz
#else
// our default implementation
#end Anyway, I'm not very interested in specialization and it can be done at a later stage if we pick (4). The |
I like (4), but it's unclear to me if we should revert 744b018 or not. If one wants to make a proper node.js module, even if it's meant to work with browser, it should export to |
Yeah, but in NW/Electron environment we have both |
What about just reversing the order of
People who want custom behaviors can assign fields to |
Sounds okay to me. |
Uhm, I'm not sure: if you run a web app into Electron/NWJS, are you not expecting to export into window as you would do in Chrome ? |
Well, I'm not sure, but I would use the require mechanism (and thus |
One could probably require both, but I think |
I just got stung by this :-) I'm using webpack |
What's the status here? |
Let's go with exports > window if other people think that's a good idea, the NWJS/Electron workflow is indeed quite particular. |
This seems to be a pretty easy fix that can be done for 3.3. Technically, it might be a breaking change, but I doubt that someone relies on that. |
We have a few choices:
Given one may want to write a JS lib that works in both browser and nodejs, I would recommend (4). It would be annoying to create separated versions for node/browser.
Currently we have commits that support (2), e.g. 744b018. When people use hxnodejs, it will define
-D nodejs
and remove browser support... Note that accessing the node API does not imply the code will only run in node. It could be there is a dynamic check, e.g. usingjs.Browser.supported
, and then access the node API only when it is running in node.(1) makes sense since the node api will only be available when using a haxelib, which will define nodejs. However it means that a generic JS lib written in haxe may not run in node even if it doesn't use any node API... It can happen e.g. for the feature checks in
js.html.compat.*
, we should usewindow
in browser, but useglobal
in nodejs.If we really want the ability to specialize for an environment, I would recommend using
-D nodejs-only
and-D browser-only
.ping @ncannasse @aduros @nadako
The text was updated successfully, but these errors were encountered: