TypeScript-DOM-lib-generator
TypeScript-DOM-lib-generator copied to clipboard
Create lib.common.d.ts?
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! 🚀)
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.
one comes from @types/node and the other one comes from lib.dom
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
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
I think that that
common.d.tsshould 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. 😉
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.