feat(cli): give access to process global everywhere

[lucacasonato]

What do we do with the TypeScript types?

[dsherret]

What do we do with the TypeScript types?

I think we probably want to add our own type for process and then maybe if the user imports @types/node it will start using that process global instead (this is pretty trivial for me to implement)? For now, we can just add our own type.

[dsherret]

I think maybe we should merge without typescript types for now?

[Hajime-san]

Is the intent of this implementation some kind of requirement that cannot be met by import process from 'node:process'?
Personally, I find it strange that the deno runtime has the global variable that are not compatible with browsers.
I would like to hear about any discussions that took place within the core team regarding this and their conclusions.

[bartlomieju]

Is the intent of this implementation some kind of requirement that cannot be met by import process from 'node:process'? Personally, I find it strange that the deno runtime has the global variable that are not compatible with browsers. I would like to hear about any discussions that took place within the core team regarding this and their conclusions.

Deno global var is also not compatible with browsers. There's a multitude of bugs and simple mismatches that would be fixed by exposing process by default. In our testing a lot of frameworks works pretty much flawlessly in Deno barring ReferenceError: process is not defined. While we could add a significant bit of machinery to catch these errors and provide hints (in addition to lint rule), it makes everyone's lives so much easier to just have it exposed.

[Hajime-san]

Admittedly, Deno namespaces are not compatible with browsers.
However, since there is a Deno-specific implementation under the Deno namespace, we believe that users will be able to recognize this as a Deno-specific API.
Similarly, I have often thought that if it were implemented like NodeJs.process...

I'm glad to hear that exposing global variables is intended to improve compatibility with Node.js.

I heard that Deno's Node.js compatibility works by internally determining whether or not it is in compatibility mode.
This process probably falls outside the scope of this compatibility mode.
Therefore, we believe that this is an API for compatibility only, and we do not recommend active use of it.
I believe that informing users about this point in the type definition or documentation is consistent with Deno's stance toward Node.js compatibility.

I really wanted to hear it. Thanks!

[bartlomieju]

This would close #24978 (and others...)