Non-deprecated lib.dom.d.ts properties removed

[JasonGore]

While trying the TS 3.9 RC I'm encountering numerous compile errors against lib.dom.d.ts against properties that have been removed. I noticed the introduction of these changes in this PR, notably properties of CSSStyleDeclaration such as ms*, webkit*, and layout*. Given many of these weren't marked deprecated I want to make sure this is expected behavior.

(Making this issue after speaking with @DanielRosenwasser and tagging @sandersn . Thanks!)

[DanielRosenwasser]

Generally speaking, we generate these from WebIDL files, but I don't know what our story is for vendor-specific additions and how they come/go.

@sandersn @RyanCavanaugh has there been much discussion around that?

[sandersn]

#828 is the PR where we tried to write down our current thinking. Briefly, we're trying to include things that are in 2 or more browsers and a standards document. I don't think ms* webkit* layout* meet either of those criteria.

[JasonGore]

They can be present and work with certain browsers though without negative effects on other browsers though, right? I can understand the desire to remove these to have a common subset but this is generating build errors for what is otherwise valid code for the same browser configurations without a lot of warning / deprecation.

[sandersn]

As I understand it, we don't want to have the default typescript/javascript completions suggest properties that aren't actually available in the majority of browsers. However, before now we've never even tried to address breaking changes in the DOM. I think there are two missing pieces:

1. Opt-in to vendor-specific types. I'm not sure Typescript should ship with these, but they should be readily available on Definitely Typed or as a standalone package. Something like @types/browser-ie
2. A deprecation strategy that results in people finding out about @types/browser-ie if the property they used was moved there out of lib.dom.d.ts.

@orta and @saschanaz will probably also have a useful take on this since they have more expertise than I do with web standards.
#802 is the source PR with our discussion.

[orta]

We want to be moving to a place where more of the artifacts we build the dom types from come from the IDLs which the W3C/WHATWG provide instead of the edge ones aren't updated anymore

I could see a new DT module which keeps the vendor specific properties via interface merging as a great backup strategy

Re: two, that's a bit harder (we'd have to bake it into the compiler?) but we could at least go back and add a note to the release notes of the 3.9 blog post?

[muuki88]

This seems also be true for window.console. It seem that #831 removed this without any replacement?

Calls to window.console now give a compile error

Property 'console' does not exist on type 'Window'

Is this intended? If yes, is there a way to add this without declaring another global window, e.g.

declare global {
   interface Window {
       console: Console;
   }
}

[saschanaz]

window should have Window & typeof globalThis type instead of previous Window. So no, not an intended behavior. Not sure why it's just Window in your case 🤔

[adamlacombe]

window should have Window & globalThis type instead of previous Window. So no, not an intended behavior. Not sure why it's just Window in your case

I was running into a similar problem building ionic-team/stencil using [email protected] - specifically this line src/hydrate/runner/runtime-log.ts#L4.

@saschanaz I see you're referring to https://github.com/microsoft/TSJS-lib-generator/blob/master/baselines/dom.generated.d.ts#L19486

declare var window: Window & typeof globalThis;

I can confirm window.console doesn't throw Property 'console' does not exist on type 'Window'.
The Window interface used to extend WindowConsole though so we could assign another variable the type Window and console was an available property.

So should we use the following type/s moving forward?

const win: Window & typeof globalThis;
...
const or: typeof window;

I haven't really dug into the code/documentation so correct me if I'm wrong - I feel like console should be a property of the Window interface if we're following the webidl json file https://github.com/microsoft/TSJS-lib-generator/pull/831/files#diff-5b8b6a001502b365505d941e15c820a7R1
[Exposed=(Window,Worker,Worklet)]

[saschanaz]

You can even do const win: typeof globalThis as globalThis will also have window properties.

I feel like console should be a property of the Window interface if we're following the webidl json file

Not actually. If you check Window.prototype.console you'll get undefined, because it's not a property.

[muuki88]

I guess I understand why I'm getting this error. My method signature looks like this

const fn = ( win: Window ) => { win.console.log() }

According to your explanation I need to change it to

const fn = ( win: Window & globalThis ) => { win.console.log() }

Right?

IMHO this is a bit awkward 😅

[saschanaz]

@muuki88 typeof globalThis should also work, and less awkward. (You need typeof anyway!) Try: https://www.typescriptlang.org/play/?ssl=1&ssc=63&pln=1&pc=1#code/MYewdgzgLgBAZmGBeGAKGB3AlmAXDKATwAcBTEOGAcwBsQAjAQxoBUALLCGASmQD4YAb0w4AdKEggapUXSqpeAXyA

[muuki88]

Thanks a lot for the fast feedback. will do ♥️

[HolgerJeromin]

Or event less thinking needed:
const fn = ( win: typeof window ) => { win.console.log() }

[ExE-Boss]

@saschanaz Window.prototype only has [Symbol.toStringTag] because Window is defined with the [Global] extended attribute.

[saschanaz]

@saschanaz Window.prototype only has [Symbol.toStringTag] because Window is defined with the [Global] extended attribute.

Ah true, thanks for correction.