Type declaration of CanvasImageSource in lib.webworker.d.ts is incomplete.

[kazakami]

Type declaration of CanvasImageSource in lib.webworker.d.ts is now only ImageBitMap.
But that should be HTMLOrSVGImageElement | HTMLVideoElement | HTMLCanvasElement | ImageBitmap
https://developer.mozilla.org/en-US/docs/Web/API/CanvasImageSource

TypeScript Version: 3.4.0-dev.201190216

Search Terms:
CanvasImageSource

Code

let ctx = document.createElement("canvas").getContext("2d")
let img = new Image()
ctx.drawImage(img, 0, 0)

tsconfig.json

{
  "compilerOptions": {
    "target": "es2018",
    "module": "commonjs",
    "lib": [
      "webworker",
      "es2018",
      "dom",
    ]
  }
}

whole project in https://github.com/Muratam/yabai-sample.ts

Expected behavior:
No error occurs when run webpack nor webpack --watch

Actual behavior:
Following error occurs when incremental build in webpack --watch
"TS2345: Argument of type 'HTMLImageElement' is not assignable to parameter of type 'ImageBitmap'.
Property 'close' is missing in type 'HTMLImageElement' but required in type 'ImageBitmap'"

Playground Link:

Related Issues:
#25468
In that issue, only TypeScript/src/lib/dom.generated.d.ts is referred, but lib.webworker.d.ts is also needed to be referred. Please fix type declaration of CanvasImageSource in lib.webworker.d.ts

[Fabianopb]

@kazakami and @RyanCavanaugh I'd be happy to contribute to this one!

[Fabianopb]

I started checking the issue in TSJS lib generator, and exposing CanvasImageSource with the required type to webworker means that we would need to bring along a whole chain of types and interfaces currently unknown to webworker and that CanvasImageSource depend on.

For example, HTMLOrSVGImageElement depends on the interface HTMLImageElement, which extends HTMLElement and so on and so forth. The chain looks really long...

Did I get this right? By doing this we would bring dozens of types and interfaces to webworker.

[Fabianopb]

Any comments anyone? Perhaps @sandersn?

[sandersn]

I'm not an expert on this yet, but the usual reason that you have to add a whole range of types is that a whole spec is missing and needs to be added to idlSource.json. For example, here's the CSS Basic User Interface entry in idlSources.json:

    {
        "url": "https://www.w3.org/TR/css-ui-3/",
        "title": "CSS Basic User Interface"
    }

Is there a w3 (or other?) spec that contains HTMLOrSvgImageElement?

Actually, on re-reading the original problem, is it the case that lib.dom.d.ts has these types but lib.webworker.d.ts doesn't?

[Fabianopb]

Actually, on re-reading the original problem, is it the case that lib.dom.d.ts has these types but lib.webworker.d.ts doesn't?

Yes, that's the core problem!

In the DOM CanvasImageSource is

type CanvasImageSource = HTMLOrSVGImageElement | HTMLVideoElement | HTMLCanvasElement | ImageBitmap;

And in the Webworker, it is

type CanvasImageSource = ImageBitmap;

And adding those three missing interfaces to the CanvasImageSource in Webworker creates that chain reaction I mentioned.

[Fabianopb]

Perhaps we could get a second opinion from @saschanaz ?

[saschanaz]

We exclude the non-existent types on workers, so no HTMLOrSVGImageElement etc.

I tried the example but tsc doesn't give any errors if I add "skipDefaultLibCheck": true. Looks like webpack-specific problem?

[Fabianopb]

@saschanaz I've tried his example with "skipDefaultLibCheck": true and the error persisted (in incremental builds with --watch as @kazakami mentioned).

However, it didn't raise any errors when lib is defined as

{
  "compilerOptions": {
    "target": "es2018",
    "module": "commonjs",
    "lib": [
      "es2018",
      "dom",
      "webworker",
    ]
  }
}

(notice that I've placed webworker after dom)

So my question is, does the order matter here?

[saschanaz]

does the order matter here?

Theoretically yes because the earliest-declared type should be persisted when multiple conflicting types exist.

[Fabianopb]

Does this solve the problem or do you think that's still a bug? At least doesn't seem to come from TypeScript if I understood correctly.

[Fabianopb]

Ping @kazakami, please take a look if the above discussion solves your issue (changing the order of items in the lib array), if that can be considered a solution perhaps this issue can be closed.