TypeScript-DOM-lib-generator icon indicating copy to clipboard operation
TypeScript-DOM-lib-generator copied to clipboard

Create lib.common.d.ts?

Open saschanaz opened this issue 3 years ago • 4 comments

Situations like https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1368 will keep happening as the commonly implemented interfaces update their definitions time to time. It might be worth to have a separate library for this.

The requirement to enter the common lib would be "2+ browser engine implementations (Gecko, Blink, WebKit)" + "2+ non-browser implementations (node, deno, etc.)".

See also #1154 and https://github.com/microsoft/TypeScript/issues/43972. (The existence of yet-unofficial https://common-min-api.proposal.wintercg.org/ is especially interesting. The spec being unofficial does not block anything here as we can just use BCD. Very fortunate that BCD covers non-browser impls! 🚀)

saschanaz avatar Sep 18 '22 13:09 saschanaz

I stumble upon another issue today that

TypeScript thinks that NodeJS web streams are not the same as DOM web streams

When i tried this code it throws an error saying that they are not compatible with each other. That they are not exactly matching.

image

one comes from @types/node and the other one comes from lib.dom image image

image image

Even tough they are exactly the same globalThis.ReadableStream === require('stream/web').ReadableStream

You should definitely consider splitting up lib.dom into one that every environment have built in in both browser and non-browser context (that also includes different web worker).

  • "2+ non-browser implementations (node, deno, etc.)". think Bun.js should be part of this

I think that that common.d.ts should should just be defined by the wintercg common min api rather than defining some kind of minimum rule that at least 2 should have it.

just the other week i had a beef with atob / btoa where it said that they where deprecated in NodeJS but not the DOM

So i think that it would be worth it if every project extended lib.common.d.ts

jimmywarting avatar May 20 '23 22:05 jimmywarting

and btw, i think all the issues in @saschanaz https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1402#issue-1377066431 where he linked to a few issues should be closed as a duplicate of this issue as i think this issue is the right path forward.

closing as dupl of microsoft/TypeScript-DOM-lib-generator#1402

jimmywarting avatar May 20 '23 22:05 jimmywarting

I think that that common.d.ts should should just be defined by the wintercg common min api rather than defining some kind of minimum rule that at least 2 should have it.

That's in no way official at this point, so I'd rather not use it.

where he linked to

Wrong. 😉

saschanaz avatar May 21 '23 00:05 saschanaz

I meet a similar issue. You can't use for await on ReadableStream because AsyncIterable interface has not been added into dom lib or @types/web. Even you use @types/node, if you import ReadableStream from node:stream/web, you can use for await, but the global ReadableStream doesn't work though they actually are same in node env. There might be other similar issues. It's clear that we need lib.common.d.ts.

And we also want @types/wintercg-api or some similar for the use cases which the user want to ensure the code only use common APIs crossed web, node, deno, bun, cloudflare workers and so on.

hax avatar Oct 08 '23 07:10 hax