Skip to content

Create lib.common.d.ts? #1402

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
saschanaz opened this issue Sep 18, 2022 · 4 comments
Open

Create lib.common.d.ts? #1402

saschanaz opened this issue Sep 18, 2022 · 4 comments

Comments

@saschanaz
Copy link
Contributor

saschanaz commented Sep 18, 2022

Situations like #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 microsoft/TypeScript#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! 🚀)

@jimmywarting
Copy link

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
Copy link

jimmywarting commented May 20, 2023

and btw, i think all the issues in @saschanaz #1402 (comment) 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

@saschanaz
Copy link
Contributor Author

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

@hax
Copy link

hax commented Oct 8, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants