WHY Deno 2.0 supports process global, but require to create require method manually ?!

[redradist]

Deno 2.0 delivers bunch of features, but also bunch of inconsistency ...

Why Deno 2.0 supports process global, but require to create require method manually ?!
See:
https://docs.deno.com/runtime/fundamentals/node/#node.js-global-objects
https://docs.deno.com/runtime/fundamentals/node/#commonjs-support

Personally I think support of process global by default is mistake, I think it should be only supported in imported modules using npm: or in *.cjs files like it done for require method ...

Such support of global process, broke detection of runtime. Also it make no sense why support one feature and not support other, and where is the boundary between deno and node runtime ...

[idleberg]

Why Deno 2.0 supports process global, but require to create require method manually ?!

Isn't it the same in NodeJS when working in pure ESM code?

[redradist]

What do you mean the same ? My questions is about why process global exists, why not provide automatic conversion with deno lint fix or add additional flag --sloppy-node-globals or --sloppy-node-process

[redradist]

@idleberg Looks like deno team listened feedback and added flag --unstable-node-globals https://deno.com/blog/v2.1#improved-support-for-nodejs-globals
I think they should now move process global under this new flag when it become stable --node-globals`

[bartlomieju]

Personally I think support of process global by default is mistake, I think it should be only supported in imported modules using npm: or in *.cjs files like it done for require method ...

This has been tried for several years and resulted in endless stream of problems for users. I wrote about it more in https://deno.com/blog/v2.0-release-candidate#changes-to-global-variables. There's a ton of frameworks that load configuration files that the first thing they do is access process.env. We made good strides with several frameworks to do explicit import process from "node:process"; before accessing process, but there's a lot of existing code out there that doesn't do that.

Such support of global process, broke detection of runtime.

How did it break the detection?

Also it make no sense why support one feature and not support other, and where is the boundary between deno and node runtime ...

At this point, with recent addition of 1a0cb5b the only difference is that Deno defaults to ESM instead of CJS if there's no type option specified. Yeah, it's different than what Node is doing, but we want to push ecosystem forward to using ESM and our support of CJS is a great opportunity here.

[redradist]

@bartlomieju

This has been tried for several years and resulted in endless stream of problems for users. I wrote about it more in https://deno.com/blog/v2.0-release-candidate#changes-to-global-variables. There's a ton of frameworks that load configuration files that the first thing they do is access process.env. We made good strides with several frameworks to do explicit import process from "node:process"; before accessing process, but there's a lot of existing code out there that doesn't do that.

It could be done differently, with --sloppy-node-globals and add automatic conversion from process to import process from "node:process"

[redradist]

@bartlomieju Looks like deno team listened feedback and added flag --unstable-node-globals https://deno.com/blog/v2.1#improved-support-for-nodejs-globals
I think they should now move process global under this new flag when it become stable --node-globals`