feat: expose Console on global object [don't merge]

[bartlomieju]

It's useful to export Console from Deno object. Obvious example would be creating "capturing" console for testing module. Unfortunately I hit problem with types in TS which I can't figure on my own.

Currently experiencing this problem:

const fakeConsole = new Deno.Console(fakePrint);
window.console = fakeConsole;

error TS2741: Property '[isConsoleInstance]' is missing in type 'Deno.Console' but required in type 'consoleTypes.Console'.

► file:///Users/biwanczuk/dev/deno_std/testing/mod.ts:63:3

63   window.console = fakeConsole;
     ~~~~~~~~~~~~~~

  '[isConsoleInstance]' is declared here.

    ► $asset$/lib.deno_runtime.d.ts:2037:5

    2037     [isConsoleInstance]: boolean;
             ~~~~~~~~~~~~~~~~~~~

From lib.deno_runtime.d.ts:

declare interface Window {
   ...
   console: consoleTypes.Console;
   ...
}

Inside Console there is isConsoleInstance which is a unique symbol. This causes that Deno.Console.isConsoleInstance is a different symbol than consoleTypes.Console.isConsoleInstance.

I believe the problem lies in a way we generated our declaration file, but I'm not sure. Calling @kitsonk for help on this one.

[ry]

Can you add a test of some sort?

[bartlomieju]

I added the test case it fails with error described above.

[kitsonk]

Ah, yeah, the unique symbol thing... this recently crept up in the TypeScript repo, I can't remember the specific issue number, but TypeScript always emits unique for symbols, though not all symbols are unique... Since we aren't generating it anymore, I would just remove the unique and see if it works. In the code, if we case we ever generate it again, I would simply set it to /** @internal */ so it doesn't leak out anymore.

[kitsonk]

Also, hopefully in TypeScript 2.7 there will be support for a form of nominal typing which will use symbol branding, so we would likely want to adjust to that in the future, because that is essentially what we are trying to express here is a nominal type versus a structural one.

[justjavac]

isConsoleInstance is only used internally, should we remove it from the exported Console field. indentLevel too.

Even so, Type Deno.Console also can not assignable to type consoleTypes.Console, for 'private property printFunc'.

[kitsonk]

So the only easy way is to have just an interface then and guard based on that interface and keep the actual classes/types internal. This does highlight though that we do need to try to get back to a generated type library fairly quickly because trying to keep this in sync with code is going be not fun.

[bartlomieju]

I think I figured it out - instead of exporting I exposed it on global object as it should be.

@kitsonk @justjavac please review

[nayeemrmn]

instead of exporting I exposed it on global object as it should be.

That breaks the browser compatibility rule.

[bartlomieju]

instead of exporting I exposed it on global object as it should be.

That breaks the browser compatibility rule.

@nayeemrmn why is that? MDN tells that it's exposed on global (or Window in browsing scopes) which is de facto what I did.

[nayeemrmn]

@bartlomieju Isn't this about the made up Console type/constructor? That link only talks about the console object (which is actually a namespace). We can make a convenience type for it, but that has to be in Deno.

[bartlomieju]

@bartlomieju Isn't this about the made up Console type/constructor? That link only talks about the console object (which is actually a namespace). We can make a convenience type for it, but that has to be in Deno.

Alright, my bad, now I see what you mean. I'll think about it

[bartlomieju]

I'll revisit this PR after #2868