Skip to content

Update TypeScript DOM Libs #47445

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

Merged
merged 1 commit into from
Jan 19, 2022
Merged

Conversation

typescript-bot
Copy link
Collaborator

@typescript-bot typescript-bot added Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript Housekeeping Housekeeping PRs For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jan 14, 2022
@orta
Copy link
Contributor

orta commented Jan 15, 2022

@typescript-bot test this
@typescript-bot dt

@typescript-bot
Copy link
Collaborator Author

typescript-bot commented Jan 15, 2022

Heya @orta, I've started to run the extended test suite on this PR at 903cb75. You can monitor the build here.

@orta orta requested a review from sandersn January 15, 2022 12:06
@orta
Copy link
Contributor

orta commented Jan 15, 2022

This looks like it won't break much, IMO

@orta
Copy link
Contributor

orta commented Jan 17, 2022

@typescript-bot dt

@orta
Copy link
Contributor

orta commented Jan 17, 2022

@typescript-bot run dt

@typescript-bot
Copy link
Collaborator Author

typescript-bot commented Jan 17, 2022

Heya @orta, I've started to run the parallelized Definitely Typed test suite on this PR at 903cb75. You can monitor the build here.

@@ -1873,7 +1885,7 @@ interface AbortSignal extends EventTarget {
declare var AbortSignal: {
prototype: AbortSignal;
new(): AbortSignal;
// abort(): AbortSignal; - To be re-added in the future
abort(reason?: any): AbortSignal;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This I thought was a part of the automation, but I guess not - might have to change it on the DOM side

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean we might need to add an override?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, this was not supposed to happen because it conflicts with the node AbortSignal - but the deploy process didn't take into account the new param - microsoft/TypeScript-DOM-lib-generator@1bba426

@@ -4928,8 +4943,10 @@ interface EventSource extends EventTarget {
readonly CONNECTING: number;
readonly OPEN: number;
addEventListener<K extends keyof EventSourceEventMap>(type: K, listener: (this: EventSource, ev: EventSourceEventMap[K]) => any, options?: boolean | AddEventListenerOptions): void;
addEventListener(type: string, listener: (this: EventSource, event: MessageEvent) => any, options?: boolean | AddEventListenerOptions): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the rationale for these new overloads?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

microsoft/TypeScript-DOM-lib-generator#736 with microsoft/TypeScript-DOM-lib-generator#1182 - basically default to message event if we don't know the event name

@DanielRosenwasser
Copy link
Member

Going to merge this for now for the beta, but I still feel a little confused about those 2 changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript For Uncommitted Bug PR for untriaged, rejected, closed or missing bug Housekeeping Housekeeping PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants