Create DOM-Level specific dom-version.d.ts

[SergioMorchon]

ECMAScript defines the basics of the script language, but It doesn't competes with the DOM Level API.

DOM API goes separately, as for example the level 2 (see http://www.w3.org/TR/DOM-Level-2-Core/).
Some scenarios, mainly Enterprise ones, Works with legacy version of browsers, which mixes versions of ECMAScript and DOM.

It would be great if we can choose the ES version and the DOM API versión (if we want one... nodejs apps?).

[LPGhatguy]

I think this is a good idea.

I also feel that the DOM APIs should be broken out into a dedicated dom.d.ts file that's modular. It would include other typing files that specify certain sets of features (Level 1, Level 2, Web Audio, Custom Elements) that are optional.

I'm not sure how I feel about a dedicated compiler target just for the DOM -- it's just another API.

[mhegazy]

would not https://github.com/borisyankov/DefinitelyTyped be a better place for this. users can include dom.level3.d.ts or even dom.chrome.d.ts?

#4168 includes a proposal to allow for picking up pieces of the default library, with this in place, it should be simple to do something like

tsc --lib core, es6 typings\dom.chrome.d.ts test.ts

to get your dom.chrome.d.ts from definitely typed, and get the default js typings from lib.core.d.ts.

@LPGhatguy and @SergioMorchon would this be sufficient to address your scenarios?

[LPGhatguy]

I don't feel that DefinitelyTyped is the appropriate place for first-class browser API definitions to live. Augmenting existing type definitions given in lib.d.ts seems like it could be a nightmare if the two projects are ever desynchronized.

What qualifies a method to be a DOM API candidate for inclusion in lib.d.ts by default?

[SergioMorchon]

@mhegazy yes! Granularity is the key. I also wanted to use es6 promises, but I still need to target es5, as explained at the purpose #4168...

Great decision, thank you!!

[mhegazy]

looks like #4168 and #4692 covers the request here. closing.