Check globalThis.Deno when setting ENVIRONMENT_IS_NODE

[rojvv]

This makes the source codes generated work better outside Node.js.

Co-authored-by: X. [email protected]

[sbc100]

So the goal here is not to set ENVIRONMENT_IS_NODE when running on deno?

How much will actually work in that case? Do we need ENVIRONMENT_MAY_BE_DENO to get things to actually work correctly, or does some stuff just work as long as we don't set ENVIRONMENT_IS_NODE.

What ENVIRONMENT_IS_XXX variable would be set in that case? I guess none of them? I'd be somewhat surprised if that works.

[rojvv]

It’s currently working fine on Deno most of the times. But sometimes the process object is made available in the Deno environment for compatibility with Node.js.

[sbc100]

How you would feel about an opt-in -sENVIRONMENT=deno flag?

Even if we move forward without that, it seems like maybe we should add some basic tests if we are going to claim to run under deno.

[rojvv]

I think it’d be cool. It would just need to remove the “is Node.js” checks and think as if it is a browser and everything will work fine.

[sbc100]

So we should set ENVRIONMENT_IS_WEB under deno you think? Does that already get set today?

[rojvv]

I just tried ENVIRONMENT=web and it worked. But I still think this change makes sense if we want to target the three at once. And I want to do that now in a lib of mine.

[sbc100]

Do threads work under Deno via the Web's Worker API? (if not then I don't think we need to modify this version of the ENVIRONMENT_IS_NODE).

[sbc100]

Also, are you saying the deno defines process.versions.node ? That seems rather odd.

[rojvv]

Yes, threads work under Deno via Web Worker API. No, Deno doesn’t define process.versions.node, rather as I said sometimes its environment is modified for compatibility with Node.js modules, for example by esm.sh.

[sbc100]

I think trying to play cat a mouse with folks that are trying to polyfill node by defining process.versions.node inside of something that isn't node, might not be the right direction. If esm.sh is trying to claim to be compatible with node by declaring process.versions.node is seems reasonable to take them at their word... otherwise we are basically trying to tell the difference between real node and pollyfilled/fake node.

On the other hand I'm not an expert in this realm so maybe this kind of thing is normal? Do you know of the best/recommend way to detect "real" node?

[kripken]

Side note, I still think the best plan forward to support Deno, Bun, and other environments is #12203

I am not necessarily opposed to small incremental improvements like this PR in the meantime, though (but I share @sbc100 questions, above).

[rojvv]

As I said, Deno is already supported with ENVIRONMENT=web. Any code written for browsers has a high chance to work on Deno. It has the most complete support for Web APIs compared to Bun (or the latest Node.js if you say so).

You won’t have to have any polyfills for it. Both now and in the future.

As for Bun support, all I can say right now is “Good luck.” It is still mostly in the works and isn’t completely supporting major Web APIs.

Also, if Bun got stable and implemented Web APIS, the only runtime that would require polyfilling would be Node.js. Right now, both Bun and Node.js might require polyfilling.

[rojvv]

Well, I just noticed ENVIRONMENT=web works with Node.js as well.

[rojvv]

I’m on v20. Not sure if it will work with older versions 🤔

[sbc100]

I’m on v20. Not sure if it will work with older versions thinking

It probably depends on what features you use. I imagine that for many programs the all the code ends up being portable.

But, if you try to use something like threads and you want to run under node you would need explicit node support in the generated code.

[kripken]

That's good news. If more and more runtimes support Web APIs then maybe we can just recommend -sENVIRONMENT=web all the time. In that case #12203 might not even be needed.