TypeScript-DOM-lib-generator

TypeScript-DOM-lib-generator copied to clipboard

Should ClipboardItemData allow non-Promises?

[{"_id":"635adf523056137e265f5e30","body":"I think https:\/\/webidl.spec.whatwg.org\/#es-promise means that conversion from ECMAScript value `V` to an IDL `Promise<T>` value effectively performs `new Promise((resolve, reject) => resolve(V))`.\r\n\r\nSo yes, non-Promises should be accepted.","issue_id":1661112977947,"origin_id":1207253567,"user_origin_id":8998201,"create_time":1659807740,"update_time":1659807855,"id":1666899794928,"updated_at":"2022-10-27T19:43:14.928000Z","created_at":"2022-10-27T19:43:14.928000Z"},{"_id":"635adf523056137e265f5e31","body":"It seems this is regressed at some point after #1102.","issue_id":1661112977947,"origin_id":1220003876,"user_origin_id":3396686,"create_time":1660859501,"update_time":1660859501,"id":1666899794932,"updated_at":"2022-10-27T19:43:14.932000Z","created_at":"2022-10-27T19:43:14.932000Z"},{"_id":"635adf523056137e265f5e32","body":"https:\/\/github.com\/microsoft\/TypeScript-DOM-lib-generator\/blob\/fc5fe1a880c5cb5750169f4b21dbb597fb052c9a\/baselines\/dom.generated.d.ts#L3644-L3647\r\n\r\nWell actually it's there, so maybe it's just that TS should import the latest bits?","issue_id":1661112977947,"origin_id":1220009244,"user_origin_id":3396686,"create_time":1660859827,"update_time":1660859827,"id":1666899794936,"updated_at":"2022-10-27T19:43:14.935000Z","created_at":"2022-10-27T19:43:14.935000Z"}]

https://github.com/microsoft/TypeScript/blob/a21024dbe7e79dc018e4193f27ecb66e0465b638/lib/lib.dom.d.ts#L3555 This implies that the options argument only allows `Promise`s of `Blob`s and `string`s, and [the spec](https://www.w3.org/TR/clipboard-apis/#typedefdef-clipboarditemdata) says so too; however, some browsers allow `Blob`s and `string`s to be used...

DanielRosenwasser

`RtcRtpEncodingParameters.maxFramerate` not included

[{"_id":"635ad190cecf4e081a219c27","body":"This is because people are not sure it's interop-ready: https:\/\/github.com\/w3c\/webrtc-extensions\/issues\/108\r\n\r\nThat said, the implementation detail doesn't matter for TypeScript. I'll accept a PR for this.","issue_id":1661112977951,"origin_id":1250255126,"user_origin_id":3396686,"create_time":1663502508,"update_time":1663502508,"id":1666896272024,"updated_at":"2022-10-27T18:44:32.024000Z","created_at":"2022-10-27T18:44:32.024000Z"}]

Hi, As I was going through the definitions, it seems like in Typescript 4.3 or @types/[email protected] `maxFramerate` was not included. At the time, it looks like `maxFramerate` did not have...

nainkunal933

DOM lib: Add support for Trusted Types API

[{"_id":"635add94d297b6213235f77c","body":"Thanks for the PR!\n\nThis section of the codebase is owned by @saschanaz - if they write a comment saying \"LGTM\" then it will be merged.\n<!-- Message About Merging -->","issue_id":1661112977955,"origin_id":1013044202,"user_origin_id":41898282,"create_time":1642160182,"update_time":1642160182,"id":1666899348290,"updated_at":"2022-10-27T19:35:48.290000Z","created_at":"2022-10-27T19:35:48.290000Z"},{"_id":"635add94d297b6213235f77d","body":"This needs multiple implementor interest. ","issue_id":1661112977955,"origin_id":1013046014,"user_origin_id":3396686,"create_time":1642160356,"update_time":1642160356,"id":1666899348294,"updated_at":"2022-10-27T19:35:48.294000Z","created_at":"2022-10-27T19:35:48.294000Z"},{"_id":"635add94d297b6213235f77e","body":"My understanding is that there are polyfill options for other browsers, making appropriate typings still pretty important.","issue_id":1661112977955,"origin_id":1013311370,"user_origin_id":143899,"create_time":1642180825,"update_time":1642180825,"id":1666899348298,"updated_at":"2022-10-27T19:35:48.298000Z","created_at":"2022-10-27T19:35:48.298000Z"},{"_id":"635add94d297b6213235f77f","body":"You're welcome to use DefinitelyTyped if you'd like to ship types which only work on a single engine \ud83d\udc4d\ud83c\udffb - though it might be quite difficult given how much existing code this affects.","issue_id":1661112977955,"origin_id":1013323992,"user_origin_id":49038,"create_time":1642181902,"update_time":1642182016,"id":1666899348302,"updated_at":"2022-10-27T19:35:48.301000Z","created_at":"2022-10-27T19:35:48.301000Z"},{"_id":"635add94d297b6213235f780","body":"Either way, this needs to take advantage of the new differently-typed getter\/setter feature in order to be properly backwards-compatible. For example,\r\n\r\n```\r\ninterface Element {\r\n get outerHTML(): string;\r\n set outerHTML(html: string|TrustedHTML);\r\n}\r\n```","issue_id":1661112977955,"origin_id":1013328661,"user_origin_id":143899,"create_time":1642182300,"update_time":1642182300,"id":1666899348305,"updated_at":"2022-10-27T19:35:48.304000Z","created_at":"2022-10-27T19:35:48.304000Z"},{"_id":"635add94d297b6213235f781","body":"@shicks , can you please take another look? Do you think this would be backwards-compatible? I ended up introducing `setterType` as I could not find a way to do what we wanted with current implementation of emitProperty. Happy to choose different approach if needed. ","issue_id":1661112977955,"origin_id":1014682610,"user_origin_id":37370256,"create_time":1642434733,"update_time":1642434733,"id":1666899348309,"updated_at":"2022-10-27T19:35:48.308000Z","created_at":"2022-10-27T19:35:48.308000Z"},{"_id":"635add94d297b6213235f782","body":"This looks much better. IIUC, the TypeScript team has a corpus of real world code that they can compile against - presumably they'd want to test this against that corpus to make sure it doesn't break anything significant.\r\n\r\nThe main breakage I anticipate at this point is if anybody is _implementing_ the DOM API (i.e. like a NodeJS virtual DOM) - but at this point anybody who's just _using_ the DOM should be fine.","issue_id":1661112977955,"origin_id":1082419110,"user_origin_id":143899,"create_time":1648591781,"update_time":1648591781,"id":1666899348312,"updated_at":"2022-10-27T19:35:48.311000Z","created_at":"2022-10-27T19:35:48.311000Z"},{"_id":"635add94d297b6213235f783","body":"We're prototyping the use of `TrustedHTML` at GitHub, and would really love to see this land!","issue_id":1661112977955,"origin_id":1130497005,"user_origin_id":248078,"create_time":1652905221,"update_time":1652905221,"id":1666899348315,"updated_at":"2022-10-27T19:35:48.315000Z","created_at":"2022-10-27T19:35:48.315000Z"},{"_id":"635add94d297b6213235f784","body":"Is there any chance of moving this forward in the near future?\r\n\r\nhttps:\/\/github.com\/DefinitelyTyped\/DefinitelyTyped\/pull\/61160 was making some progress last month, but my understanding is that it will still be hard to use if the `Element.innerHTML` setter still only allows `string` assignment in `lib.dom.d.ts`. This makes it rather tricky to use trusted types in practice, without working around lots of errors. \ud83d\ude14","issue_id":1661112977955,"origin_id":1217026842,"user_origin_id":248078,"create_time":1660676299,"update_time":1660676299,"id":1666899348318,"updated_at":"2022-10-27T19:35:48.318000Z","created_at":"2022-10-27T19:35:48.318000Z"},{"_id":"635add94d297b6213235f785","body":"So far no implementer interest outside of Google, so a progress can happen when something happens there.","issue_id":1661112977955,"origin_id":1217056177,"user_origin_id":3396686,"create_time":1660677225,"update_time":1660677225,"id":1666899348321,"updated_at":"2022-10-27T19:35:48.320000Z","created_at":"2022-10-27T19:35:48.320000Z"},{"_id":"635add94d297b6213235f786","body":"> So far no implementer interest outside of Google, so a progress can happen when something happens there.\r\n\r\n\ud83d\ude4b We are actively working on exploring trusted types on the `github.com` site, and are specifically running into challenges with the concrete implementation due to this. \ud83e\udd13\r\n\r\nBy implementer, I'm guessing you might mean just browsers, though?\r\n\r\nIs there any way to make the `innerHTML` setter type at least *compatible* with `TrustedHTML` from `@types\/trusted-types`? That would make a big difference.\r\n(For example, one blunt possibility would be for `.innerHTML` to accept any `string` or any object with `toString()`.)","issue_id":1661112977955,"origin_id":1217068530,"user_origin_id":248078,"create_time":1660678061,"update_time":1660678181,"id":1666899348323,"updated_at":"2022-10-27T19:35:48.323000Z","created_at":"2022-10-27T19:35:48.323000Z"},{"_id":"635add94d297b6213235f787","body":">By implementer, I'm guessing you might mean just browsers, though?\r\n\r\nYes.\r\n\r\n\r\n\r\n> Is there any way to make the `innerHTML` setter type at least _compatible_ with `TrustedHTML` from `@types\/trusted-types`? That would make a big difference.\r\n\r\nThat's really a thing that needs a Microsoft decision, but I think TS should support overloading the setter declaration to make it compatible.","issue_id":1661112977955,"origin_id":1217084234,"user_origin_id":3396686,"create_time":1660678839,"update_time":1660678925,"id":1666899348325,"updated_at":"2022-10-27T19:35:48.325000Z","created_at":"2022-10-27T19:35:48.325000Z"},{"_id":"667f79e663673df7300e5972","body":"> So far no implementer interest outside of Google, so a progress can happen when something happens there.\r\n\r\nThere is now multi implementor interest: https:\/\/github.com\/mozilla\/standards-positions\/issues\/20#issuecomment-1853427823, with a Gecko implementation [progressing](https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=1508286). Implementation in WebKit is also [ongoing](https:\/\/bugs.webkit.org\/show_bug.cgi?id=266630). What are the next best steps?\r\n\r\n","issue_id":1661112977955,"origin_id":2115134866,"user_origin_id":128171,"create_time":1715862906,"update_time":1715862906,"id":1719630310839,"updated_at":"2024-06-29T03:05:10.839000Z","created_at":"2024-06-29T03:05:10.839000Z"},{"_id":"667f79e663673df7300e5973","body":"When the feature ships, MDN data will be updated and that will be automatically reflected here.","issue_id":1661112977955,"origin_id":2115148728,"user_origin_id":3396686,"create_time":1715863324,"update_time":1715863324,"id":1719630310910,"updated_at":"2024-06-29T03:05:10.910000Z","created_at":"2024-06-29T03:05:10.910000Z"},{"_id":"667f79e663673df7300e5974","body":"> When the feature ships, MDN data will be updated and that will be automatically reflected here.\r\n\r\nDo you mean browser compat data on MDN? I think browser compat data on MDN is manually updated, at least [that was the case](https:\/\/github.com\/mdn\/browser-compat-data\/pull\/6263) when the Trusted Types shipped in Chrome. Once that happens (which, I guess, is after shipping in Gecko or WebKit), what is actually happening automatically in this repo? Trusted Types APIs are already largely integrated in HTML, DOM and other specs (e.g. https:\/\/dom.spec.whatwg.org\/#parentnode). \r\n\r\nSorry for those basic questions, I'm just trying to figure out what needs manual work and when is it best to do that work. It seems like the 'when' part is after 2nd implementation part ships, but I don't know yet the 'what' part.\r\n\r\n\r\n\r\n","issue_id":1661112977955,"origin_id":2115385612,"user_origin_id":128171,"create_time":1715869286,"update_time":1715869286,"id":1719630310921,"updated_at":"2024-06-29T03:05:10.920000Z","created_at":"2024-06-29T03:05:10.920000Z"},{"_id":"667f79e763673df7300e5975","body":"> Do you mean browser compat data on MDN? I think browser compat data on MDN is manually updated, at least that was the case when the Trusted Types shipped in Chrome. \r\n\r\nYes. After that a friendly bot will come along and create here a PR like this: #1726","issue_id":1661112977955,"origin_id":2115441789,"user_origin_id":2410353,"create_time":1715870538,"update_time":1715870538,"id":1719630311024,"updated_at":"2024-06-29T03:05:11.023000Z","created_at":"2024-06-29T03:05:11.023000Z"}]

This PR adds support for Trusted Types APIs and Sinks in dom and worker libraries. These APIs are so far only supported by Blink. In https://github.com/microsoft/TypeScript/issues/30024 we seem to be...

tosmolka

window.scrollTo behavior option missing "instant" string literal union

[{"_id":"635ad971cecf4e081a21a1a3","body":"Hey, I just ran into this issue as well. It looks like according to the CSSOM spec there is no `'instant'` setting for option.\r\n\r\nYou can see in the [CSS Overflow Module Level 3](https:\/\/drafts.csswg.org\/css-overflow-3\/#propdef-scroll-behavior) that `scroll-behavior` only accepts the vales `'auto' | 'instant'`. Furthermore, the [CSSOM](https:\/\/drafts.csswg.org\/cssom-view\/#scrolling) specifies that if behavior is auto and the element in question being scrolled to has the smooth computed for it (i.e. the scroll-behavior property of the element is set to 'smooth') that smooth scrolling will be used. The only case where instant scrolling should be used (per the spec) is if the element _doesn't_ have scroll-behavior set to smooth and auto is the behavior for `scrollTo`. In other words, instant scrolling behavior _cannot_ be forced by the `scrollTo` method per the spec.\r\n\r\nHowever, I've checked and both Firefox and Chrome deviate from the spec and allow the use of `'instant'` for `scrollTo`. I'm not sure what should be done here from TypeScript's perspective as the reality of the web and the letter of its law differ. Ideally, the spec would be revised to allow for explicitly instant scrolling","issue_id":1661112977960,"origin_id":977170733,"user_origin_id":4015408,"create_time":1637701749,"update_time":1637701749,"id":1666898289819,"updated_at":"2022-10-27T19:18:09.818000Z","created_at":"2022-10-27T19:18:09.818000Z"},{"_id":"635ad971cecf4e081a21a1a4","body":"It seems this is intended. The `instant` has been renamed into `auto`. So you need to change `instant` into `auto`. Ref: https:\/\/github.com\/microsoft\/TypeScript-DOM-lib-generator\/commit\/fe01c9a6d6afde86bd15f2588dc9360416a2beb4#r31507840","issue_id":1661112977960,"origin_id":991839435,"user_origin_id":987638,"create_time":1639288264,"update_time":1639288264,"id":1666898289823,"updated_at":"2022-10-27T19:18:09.823000Z","created_at":"2022-10-27T19:18:09.823000Z"},{"_id":"635ad971cecf4e081a21a1a5","body":"For my case I have to use `instant` option not `auto` because the `<html>` tag is set to smooth scroll, by using inline style","issue_id":1661112977960,"origin_id":991840008,"user_origin_id":29286430,"create_time":1639288691,"update_time":1639288791,"id":1666898289827,"updated_at":"2022-10-27T19:18:09.826000Z","created_at":"2022-10-27T19:18:09.826000Z"},{"_id":"635ad971cecf4e081a21a1a6","body":"I'm running into basically the same issue as @aquaductape:\r\n`behavior: 'auto'` respects the element's CSS `scroll-behavior: smooth` declaration.\r\n\r\nWhat works (in browsers) is `behavior: 'instant'`, prefixed with a `\/\/ @ts-expect-error [mildly irritated message]` \ud83d\ude09","issue_id":1661112977960,"origin_id":1216383232,"user_origin_id":86827,"create_time":1660641798,"update_time":1660641904,"id":1666898289831,"updated_at":"2022-10-27T19:18:09.830000Z","created_at":"2022-10-27T19:18:09.830000Z"},{"_id":"635ad971cecf4e081a21a1a7","body":"~~according to <https:\/\/drafts.csswg.org\/cssom-view\/#extensions-to-the-window-interface>,~~\r\n~~'instant' has been removed, browser should not support this feature.~~\r\n\r\n~~i opened an issue: <https:\/\/bugs.chromium.org\/p\/chromium\/issues\/detail?id=1358809>~~","issue_id":1661112977960,"origin_id":1233878191,"user_origin_id":10328430,"create_time":1662018190,"update_time":1662026404,"id":1666898289835,"updated_at":"2022-10-27T19:18:09.834000Z","created_at":"2022-10-27T19:18:09.834000Z"},{"_id":"635ad971cecf4e081a21a1a8","body":"The proposed merging of \"instant\" with \"auto\" along with the described resolution algoritm of the \"auto\" behavior value, remove a perfectly valid use case\/feature, without as much as a hint of justification or even mentioning it.\r\n\r\nAfter the change `window.scrollTo` (and related methods) can only affect scroll behavior in the direction of making it smoother, but not make it more instant. Something that was previously possible, and intentionally done (as demonstrated by this issue, and other similar examples available with quick Googling).\r\n\r\nThis spec change looks like a mistake, IMO \u2014 a resonable hypothesis as the linked document is in an \"editor's draft\" state:\r\n\r\n> An editor's draft is a document allowing the Group to iterate internally on its content for consideration. Editor's Drafts are works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C.\r\n>\r\n> **These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards.** \r\n\r\n\u2014 <https:\/\/www.w3.org\/standards\/types#ED> _(Emphasis mine)_\r\n\r\nThus, I argue that this change in TypeScript's lib is premature, and someone should raise an issue with W3C's CSSWG regarding this, instead of pressuring browser makers to act on it in haste.","issue_id":1661112977960,"origin_id":1234012739,"user_origin_id":86827,"create_time":1662024480,"update_time":1662024753,"id":1666898289838,"updated_at":"2022-10-27T19:18:09.837000Z","created_at":"2022-10-27T19:18:09.837000Z"},{"_id":"635ad971cecf4e081a21a1a9","body":"@maranomynet yes, that makes sense!","issue_id":1661112977960,"origin_id":1234039356,"user_origin_id":10328430,"create_time":1662025916,"update_time":1662025916,"id":1666898289840,"updated_at":"2022-10-27T19:18:09.840000Z","created_at":"2022-10-27T19:18:09.840000Z"},{"_id":"635ad971cecf4e081a21a1aa","body":"Thanks people! Filed https:\/\/github.com\/w3c\/csswg-drafts\/issues\/7773. ","issue_id":1661112977960,"origin_id":1254415571,"user_origin_id":3396686,"create_time":1663811911,"update_time":1663811911,"id":1666898289843,"updated_at":"2022-10-27T19:18:09.843000Z","created_at":"2022-10-27T19:18:09.843000Z"},{"_id":"667f7a19899db58b59015ccf","body":"should closed by https:\/\/github.com\/microsoft\/TypeScript-DOM-lib-generator\/pull\/1481","issue_id":1661112977960,"origin_id":1514516696,"user_origin_id":8519685,"create_time":1681901008,"update_time":1681901008,"id":1719630361818,"updated_at":"2024-06-29T03:06:01.818000Z","created_at":"2024-06-29T03:06:01.818000Z"},{"_id":"667f7a19899db58b59015cd0","body":"Right, thanks.\r\n\r\n@github-actions close","issue_id":1661112977960,"origin_id":1514589955,"user_origin_id":3396686,"create_time":1681904765,"update_time":1681904765,"id":1719630361872,"updated_at":"2024-06-29T03:06:01.872000Z","created_at":"2024-06-29T03:06:01.872000Z"},{"_id":"667f7a19899db58b59015cd1","body":"Closing because @saschanaz is one of the code-owners of this repository.","issue_id":1661112977960,"origin_id":1514590217,"user_origin_id":41898282,"create_time":1681904779,"update_time":1681904779,"id":1719630361887,"updated_at":"2024-06-29T03:06:01.886000Z","created_at":"2024-06-29T03:06:01.886000Z"},{"_id":"667f7a19899db58b59015cd3","body":"When I run npm run build, it says that \"instant\" isn't a valid value for type ScrollBehavior. \r\n\r\nMy code is\r\n\r\ndocument.documentElement.scrollTo({\r\ntop: 0,\r\nleft: 0,\r\nscroll-behavior: 'instant'\r\n})\r\n\r\nand\r\n\r\nwindow.scrollTo({\r\ntop: ref.offsetTop,\r\nleft: 0,\r\nscroll-behavior: 'instant'\r\n})","issue_id":1661112977960,"origin_id":1635184195,"user_origin_id":133179804,"create_time":1689302570,"update_time":1689302570,"id":1719630361977,"updated_at":"2024-06-29T03:06:01.977000Z","created_at":"2024-06-29T03:06:01.977000Z"}]

# Bug Report [window.scrollTo behavior option](https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollTo#parameters) has three types: "smooth", "instant" and "auto", but typescript doesn't have "instant" value. ### 🕗 Version `v4.4.4` ### ⏯ Playground Link https://www.typescriptlang.org/play?#code/O4SwdgJg9sB0DOBjATlANmgKlAFAbwCMBTACwEMA3EKZALgAIByceAFzLFcYF8BKIA ### 💻...

aquaductape

Attempt to add interface for constuctors to add static properites

[{"_id":"635ad1ee8041c95dfb1719a0","body":"[](https:\/\/cla.opensource.microsoft.com\/microsoft\/TypeScript-DOM-lib-generator?pullRequest=1379) <br\/>All CLA requirements met.","issue_id":1661112977964,"origin_id":1214472318,"user_origin_id":10137,"create_time":1660519582,"update_time":1660519706,"id":1666896366284,"updated_at":"2024-06-29T03:05:14.593000Z","created_at":"2022-10-27T18:46:06.284000Z"},{"_id":"635ad1ee8041c95dfb1719a1","body":"Thanks for the PR!\n\nThis section of the codebase is owned by @saschanaz - if they write a comment saying \"LGTM\" then it will be merged.\n<!-- Message About Merging -->","issue_id":1661112977964,"origin_id":1214472353,"user_origin_id":41898282,"create_time":1660519591,"update_time":1660519591,"id":1666896366289,"updated_at":"2022-10-27T18:46:06.288000Z","created_at":"2022-10-27T18:46:06.288000Z"}]

OK, this PR is a headache and a trip down the rabbit hole for me. It's technically a broken PR as I know one test fails, but I can't fix...

Spice-King

AbortSignal conflict issue between @types/[email protected] and @types/[email protected]

[{"_id":"635ad49ececf4e081a219e60","body":"Just a note, the current version is `0.0.70` and the last working version is `0.0.69`. (Not 0.70 and 0.69)","issue_id":1661112977968,"origin_id":1196400428,"user_origin_id":140370,"create_time":1658909362,"update_time":1658909362,"id":1666897054005,"updated_at":"2022-10-27T18:57:34.005000Z","created_at":"2022-10-27T18:57:34.005000Z"},{"_id":"635ad49ececf4e081a219e61","body":"> Just a note, the current version is `0.0.70` and the last working version is `0.0.69`. (Not 0.70 and 0.69)\r\n\r\nThanks, I've updated my post.","issue_id":1661112977968,"origin_id":1196942378,"user_origin_id":465272,"create_time":1658937258,"update_time":1658937258,"id":1666897054009,"updated_at":"2022-10-27T18:57:34.009000Z","created_at":"2022-10-27T18:57:34.009000Z"},{"_id":"635ad49ececf4e081a219e62","body":"See also https:\/\/github.com\/DefinitelyTyped\/DefinitelyTyped\/issues\/60868 and https:\/\/github.com\/DefinitelyTyped\/DefinitelyTyped\/pull\/61412","issue_id":1661112977968,"origin_id":1214381083,"user_origin_id":24830662,"create_time":1660484637,"update_time":1660484637,"id":1666897054013,"updated_at":"2022-10-27T18:57:34.013000Z","created_at":"2022-10-27T18:57:34.013000Z"},{"_id":"635ad49ececf4e081a219e63","body":"#1365 added `AbortSignal.timeout` and that seems the cause of the conflict. #1093 worked around this last time by removing `AbortSignal.abort`, but not sure we should do the same here.\r\n\r\nI'd prefer waiting [#60868](https:\/\/github.com\/DefinitelyTyped\/DefinitelyTyped\/issues\/60868).","issue_id":1661112977968,"origin_id":1250145656,"user_origin_id":3396686,"create_time":1663451438,"update_time":1663451438,"id":1666897054016,"updated_at":"2022-10-27T18:57:34.016000Z","created_at":"2022-10-27T18:57:34.016000Z"},{"_id":"664546a34ecfda50de10d343","body":"Is there any workaround besides pinning @types\/[email protected]?","issue_id":1661112977968,"origin_id":1731836050,"user_origin_id":1301335,"create_time":1695405661,"update_time":1695405661,"id":1715816099338,"updated_at":"2024-05-15T23:34:59.337000Z","created_at":"2024-05-15T23:34:59.337000Z"}]

With the latest release of `@types/[email protected]` being installed side-by-side with `@types/[email protected]`, we are receiving the following conflict: ``` ../../node_modules/@types/node/globals.d.ts:72:13 - error TS2403: Subsequent variable declarations must have the same type....

cjones26

Event type for error event is incorrect

[]

In `GlobalEventHandlersEventMap`, `error` event is mapped to `ErrorEvent`. This might be correct for `Window` when handling events from runtime error, it is incorrect for `Element`s. When `Element`s trigger that event,...

upsuper

ReadableStreamBYOBReader and ReadableStreamReader disappeared with typescript 4.2.2

[{"_id":"635adc6d3056137e265f5bcf","body":"ref https:\/\/github.com\/microsoft\/TypeScript-DOM-lib-generator\/issues\/886#issuecomment-664158110 and the following comment.","issue_id":1661112977975,"origin_id":786518126,"user_origin_id":2410353,"create_time":1614331057,"update_time":1614331057,"id":1666899053061,"updated_at":"2022-10-27T19:30:53.061000Z","created_at":"2022-10-27T19:30:53.061000Z"},{"_id":"635adc6d3056137e265f5bd0","body":"true, but now that chromium is leveraged in many browsers (vivaldi, brave, edge, chrome, ...), should we not consider to have it anyway ?","issue_id":1661112977975,"origin_id":787063889,"user_origin_id":1405160,"create_time":1614428073,"update_time":1614428073,"id":1666899053066,"updated_at":"2022-10-27T19:30:53.065000Z","created_at":"2022-10-27T19:30:53.065000Z"},{"_id":"635adc6d3056137e265f5bd1","body":"FYI these types were re-added in #1362, so they will become available in a future TypeScript release. (I don't know how soon that'll happen, though.)","issue_id":1661112977975,"origin_id":1204946478,"user_origin_id":649348,"create_time":1659602341,"update_time":1659602341,"id":1666899053070,"updated_at":"2022-10-27T19:30:53.070000Z","created_at":"2022-10-27T19:30:53.070000Z"}]

I updated to typescript 4.2.2 today, but strangely, ReadableStreamBYOBReader and ReadableStreamReader disappeared from type definition

npenin

`ReadableStream.pipeThrough` should be generic on `transform` argument and return real type of `ReadableStream`

[{"_id":"635ad9608041c95dfb171ff0","body":"Sounds like a good idea to me. ","issue_id":1661112977979,"origin_id":1204891099,"user_origin_id":3396686,"create_time":1659599219,"update_time":1659599219,"id":1666898272023,"updated_at":"2022-10-27T19:17:52.023000Z","created_at":"2022-10-27T19:17:52.023000Z"}]

Sorry if here is not the place to discuss individual API design. Currently `pipeThrough` is defined as https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/11d922f302743cb3fcee9ab59b03d40074a2965c/baselines/dom.generated.d.ts#L11137 It always returns a `ReadableStream`. However according to spec it will return...

yume-chan

[WebRTC] A lot of metrics are missing

[{"_id":"635ad74cea01ec786e7ce2da","body":"@aboba FYI","issue_id":1661112977983,"origin_id":1196361592,"user_origin_id":11347890,"create_time":1658906840,"update_time":1658906840,"id":1666897740105,"updated_at":"2022-10-27T19:09:00.105000Z","created_at":"2022-10-27T19:09:00.105000Z"},{"_id":"635ad74cea01ec786e7ce2db","body":"This generator uses https:\/\/github.com\/mdn\/browser-compat-data (bcd) for them.\r\nPerhaps this one:\r\nhttps:\/\/github.com\/mdn\/browser-compat-data\/blob\/499d5fa0371c2919eb3caf43bc11b2805ae99772\/api\/RTCRtpStreamStats.json\r\n\r\nIf the data is wrong in bcd these must be corrected or added. Then this generator will add them into dom.generated.d.ts","issue_id":1661112977983,"origin_id":1196405983,"user_origin_id":2410353,"create_time":1658909710,"update_time":1658909710,"id":1666897740109,"updated_at":"2022-10-27T19:09:00.109000Z","created_at":"2022-10-27T19:09:00.109000Z"},{"_id":"635ad74cea01ec786e7ce2dc","body":"BCD indeed is used for interfaces, but dictionaries are manually managed because it's not straightforward to map them to BCD. \n\nhttps:\/\/github.com\/microsoft\/TypeScript-DOM-lib-generator\/blob\/321faea739848ceade8d40aa5db16fadf8cd25c2\/inputfiles\/removedTypes.jsonc#L468-L507\n\nPR welcome. ","issue_id":1661112977983,"origin_id":1204888363,"user_origin_id":3396686,"create_time":1659599050,"update_time":1659599050,"id":1666897740113,"updated_at":"2022-10-27T19:09:00.113000Z","created_at":"2022-10-27T19:09:00.113000Z"}]

If you look at RTCStats and its subdirectory you'll notice the metrics are very much not up to date. For example [RTCOutboundRtpStreamStats in dom.generated.d.ts](https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/main/baselines/dom.generated.d.ts#L1343) appears to be missing 20-30 or...

henbos