The dom.iterable lib contains many interfaces that should also be in webworker

[philipwalton]

Many of the interfaces defined in dom.iterable should also be available to web workers. These include:

• Headers
• FormData
• URLSearchParams

And 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: #20595

[sandersn]

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.

[sandersn]

Same, I forgot this again. =( I'll try to get to it in a couple of weeks for 4.0.

[sandersn]

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).

[tankakatan]

The problem is still present in TypeScript 4.3.4 and it's really annoying. I use [email protected] in conjunction with [email protected] in my project, and it fails to compile my tests because of the issue. Please resolve.

[kangzeroo]

I am having this issue too, but with "lib": ["es2015", "dom", "webworker"], in my tsconfig.json (not using dom.iterable lib).

Going to try this comment's suggestion to "skipLibCheck": true, although I reckon that might end up badly in production... with the web worker, or some other lib... Will update with my findings...

UPDATE: Ok, so "skipLibCheck": true worked... I was able to compile. But I am concerned I will run into issues in production (esp with other libs). BUT if the web worker runs in its own process, perhaps the types won't ever conflict in prod? Could someone with more expertise on this matter clarify for me? 🙏 thanks!

[alexandrzavalii]

looks like the issue is still present?