Split the "lib.dom.d.ts" definition file apart

Search Terms

lib.dom.d.ts, split, modular

Suggestion

I'm currently writing a TypeScript definition file for the API of a game, which will be submitted to DefinitelyTyped soon.

The API of the game exposes a Notification class to the global scope, which collides with the one in "lib.dom.d.ts" definition file. Not only that, but it also uses jQuery and XMLHttpRequest, forcing me to include that definition file.

Use Cases

By splitting the "lib.dom.d.ts" definition file apart, user can select only the APIs they need.

This change should not break the backward compatibility of old projects, although old versions of TypeScript will not support projects using the modular definition file.

Examples

For example, the "lib.dom.d.ts" definition file could be split up like this:

lib.dom.d.ts
|-- lib.dom.elements.d.ts
|-- lib.dom.notification.d.ts
|-- lib.dom.xhr.d.ts
`-- ... (other modules)

When some parts of the user's definition file collide with the "lib.dom.d.ts" definition file, the user can use the following instead:

{
    "compilerOptions": {
        "lib": [
            "DOM.Elements",
            "DOM.XHR",
            ... // (other modules except for "DOM.Notification")
        ]
        ...
    }
    ...
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

まず、既存の lib.dom.d.ts 定義ファイルと、compilerOptions.lib がライブラリ定義を選択する仕組みを調査します。既存のプロジェクトに対する lib.dom.d.ts の現在の動作を維持しながら、ユーザーが DOM.Notification などの競合する API を省略できるようにするモジュール分割を定義します。提案した構成が、後方互換性を損なうことなく DOM API を選択的にサポートできれば完了です。