-
Couldn't load subscription status.
- Fork 6.8k
feat(multiple): add support for TypeScript 4.4 #23646
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
Conversation
Updates to the latest version of Angular and TypeScript, and resolves the various build errors.
| ], | ||
| exports: [ | ||
| ...EXPORTED_DECLARATIONS, | ||
| MatPopoverEdit, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes are a workaround for an issue with ngcc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a link/issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There isn't, my changes in the PR for TS 4.4 on the framework side probably didn't cover the new generated code array spreads correctly. I'm looking into it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR to fix the compiler: angular/angular#43618.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. just one question.
| }; | ||
|
|
||
| /** Equivalent of `ClientRect` without some of the properties we don't care about. */ | ||
| type Dimensions = Omit<ClientRect, 'x' | 'y' | 'toJSON'>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would make sense to have an explicit type (with properties defined) in overlay/position instead of doing it that way. Not feeling strongly, just an idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went with this approach since it's still less code than listing out the properties individually on an interface.
| if (this._handles.length) { | ||
| this._rootElementTapHighlight = rootElement.style.webkitTapHighlightColor || ''; | ||
| rootElement.style.webkitTapHighlightColor = 'transparent'; | ||
| const rootStyles = rootElement.style as any; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally not a fan of any, but it's acceptable in this case since the type for CSSStyleDeclaration is wrong. Here are a two suggestions that are more type safe than any.
rootElement.style as CSSStyleDeclaration & { [key: string]: string|null|undefined }rootElement.style as CSSStyleDeclaration & { webkitTapHighlightColor?: string|null}
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Updates to the latest version of Angular and TypeScript, and resolves the various build errors.