Many of the interfaces defined in dom.iterable should also be available to web workers. These include:
HeadersFormDataURLSearchParamsAnd since the dom.iterable library does not play well with the webworker library, I have to define these interfaces in my own, separate, library (instead of just including built-in libraries).
The webworker library should either _also_ have an "iterable" variant, or these interfaces should be abstracted to a higher level.
TypeScript Version: 3.5.3, master
Search Terms:
dom iterable worker
Code
// index.ts
const h = new Headers();
console.log([...h.entries()]);
const h = new Headers();
console.log([...h.entries()]);
tsc --target esnext --lib esnext,webworker index.ts
Expected behavior:
This should compile fine (as it does when using --lib esnext,dom,dom.iterable).
Actual behavior:
index.ts:3:19 - error TS2339: Property 'entries' does not exist on type 'Headers'.
3 console.log([...h.entries()]);
~~~~~~~
Found 1 error.
Playground Link:
Can't show this in the playground as I can't specify --lib options.
Related Issues:
Somewhat related to: https://github.com/microsoft/TypeScript/issues/20595
Unfortunately, I missed this for 3.8. I'm going to move to 3.9 and look at it early in the release cycle with @orta.
Same, I forgot this again. =( I'll try to get to it in a couple of weeks for 4.0.
Like #20595, the solution to this problem is to move the webworker-shared parts of dom.iterable.d.ts to web.iterable.d.ts and have both webworker.d.ts and dom.iterable.d.ts. (I'm not sure yet if it's possible to include webworker without targetting es2015, but es5 should not include web.iterable.d.ts by default).
Most helpful comment
Unfortunately, I missed this for 3.8. I'm going to move to 3.9 and look at it early in the release cycle with @orta.