-
Notifications
You must be signed in to change notification settings - Fork 6.8k
refactor(ng-update): better check for updated constructor signatures #12970
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
refactor(ng-update): better check for updated constructor signatures #12970
Conversation
invalidArgCounts: [ | ||
{ | ||
count: 2, | ||
message: '"g{{defaults}}" is now required as a third argument' |
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.
FYI: There will be a follow-up PR that adds some additional messages to the TSLint failure.
Even though it's not necessarily needed because we show the new signature, it's good to explain people what changed.
Note: Technically the type checker wouldn't be a good idea to use for the schematics because when doing an upgrade from V5 to V7, we won't have typings for But since the Angular CLI always installs the desired target version, we will have the typings for that version and can just check the signatures. Since we just check and not migrate anything, it's even better just displaying the signature of the target Material version. e.g. consider the following signatures for each version:
In that case if someone upgrades from |
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
|
||
import {transformChanges} from '../transform-change-data'; | ||
|
||
export const constructorChecks = transformChanges<string>([ |
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.
Add a comment here explaining what this config is for?
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.
Can do. Will do that while rebasing.
487dca1
to
22e8f53
Compare
Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can *way* better report invalid signatures for constructor changes like for the `MatCalendar` (angular#9775). Just relying on the length of arguments means that *order* is being ignored. This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
22e8f53
to
18c91da
Compare
@jelbourn Rebased. |
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. |
Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can way better report invalid signatures for constructor changes like for the
MatCalendar
(#9775). Just relying on the length of arguments means that order is being ignored.This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
NOTE: There is one downside: Right now since we cannot check whether a type is assignable to another one, things like that will result in a false report.
But IMO since this just results in a polite message from TSLint, and we benefit a lot more for things like the
MatCalendar
, we should be fine having this trade-off. We can follow-up with some custom checks.