Deno: Should deno be a global variable instead of a module?

[ry]

This would allow runtime tests easily branch between deno and browser code:

if (window["deno"]) {
  deno.writeFileSync("foo.txt", buffer);
}

This is already how the REPL works.

[hayd]

Another benefit is this would mean all imports required .ts (there was no special case for deno).

[kitsonk]

I wouldn't be opposed to that. It actually cuts down on a fair amount of churn in module loading too. The only "opposition" I would have, is that it came up on one of the security threads that we could stop certain modules ("untrusted") from importing deno. As a global variable, it would be much harder to limit access to those APIs.

[ry]

I think the security issue is interesting - but I think the usefulness (and naturalness) of the global variable outweighs it...

Should the global variable be capitalized? "Deno" or "deno" ?

[piscisaureus]

I think the name should be Deno with a capital D.
This is follows the ecmascript convention of using UpperCamelCase for globals, even if they're not constructors. (cf. Reflect, Atomics, Symbol).

[thgh]

That would also unlock the door to building deno/node compatible modules. Current workaround: typeof libdeno !== 'undefined' && libdeno.builtinModules.deno.readFile

[kitsonk]

Also there is part of me where I wouldn't want to let deno exist as an import for too long... maybe not at all... (or we plan 0.3.0 in there near future and remove it there).

For the security, why it is interesting blocking APIs from being imported, at the end, I think we need to use a combination of more granular permissions and the built in sandbox capabilities that are already built into JavaScript engines, like web workers and service workers.

[GeorgeTaveras1231]

Just an opinion: I understand the desire to remove the deno module since it's currently treated as a special module (agree with @hayd). However, making it a global doesn't seem great either, since it creates a dumping ground for all builtin deno modules. If deno ships enough builtin modules, this could eventually add unnecessary overhead (in memory consumption for example) in running any given module, even though chances are that not every built in module will be in use.

[kitsonk]

@GeorgeTaveras1231 I would expect we would seal or freeze Deno in the global scope. This is for a very limited set of APIs which communicate with the privileged side that do not have a good browser standard API. If the namespace gets too big, we are doing it wrong.

Any longterm roadmap of native "plugins" shouldn't ever express themselves in the Deno namespace, IMO.

[kitsonk]

Because of the impacts on the runtime type library, I think it would be easier for me to tackle this. Thanks for the effort though @sh7dm.