lib.dom.d.ts OffscreenCanvas.getContext() not returning type based on context ID

[TomasHubelbauer]

lib Update Request

I would like to request that OffscreenCanvas.getContext behaves the same way as HTMLCanvasElement.getContext in that the latter returns different concrete context types depending on what context ID is passed in as an argument and the former just returns an umbrella context type that needs to be disambiguated first.

Configuration Check

My compilation target is ESNext and my lib is ["DOM", "ESNext"].

Missing / Incorrect Definition

HTMLCanvasElement.getContext:

const canvas = document.createElement('canvas');
const context = canvas.getContext('2d');
// `context` is `CanvasRenderingContext2D`

// lib.dom.d.ts:
getContext(contextId: "2d", options?: CanvasRenderingContext2DSettings): CanvasRenderingContext2D | null;
getContext(contextId: "bitmaprenderer", options?: ImageBitmapRenderingContextSettings): ImageBitmapRenderingContext | null;
getContext(contextId: "webgl", options?: WebGLContextAttributes): WebGLRenderingContext | null;
getContext(contextId: "webgl2", options?: WebGLContextAttributes): WebGL2RenderingContext | null;
getContext(contextId: string, options?: any): RenderingContext | null;

OffscreenCanvas.getContext:

const canvas = new OffscreenCanvas(16, 16);
const context = canvas.getContext('2d');
// `context` is `OffscreenRenderingContext`

// lib.dom.d.ts:
getContext(contextId: OffscreenRenderingContextId, options?: any): OffscreenRenderingContext | null;

I believe it would be beneficial to add overloads with context ID literals which return specific context types.
Also, maybe it would make sense to introduce a context type string literal enum for the normal canvas context types, not just a string?

Documentation Link

• https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext#return_value
• https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas/getContext#return_value

[TomasHubelbauer]

OffscreenCanvas is also missing convertToBlob. I am happy to contribute these changes in one PR, just give me a greenlight.

[TomasHubelbauer]

I did not read the issue template carefully enough, it seems the right way to handle this is not to send a PR here but instead open one in https://github.com/microsoft/TypeScript-DOM-lib-generator so I did that:

microsoft/TypeScript-DOM-lib-generator#1501