-
-
Notifications
You must be signed in to change notification settings - Fork 187
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(permission-controller): Clean up use of any
#4171
Conversation
391be86
to
69c78bb
Compare
any
in PermissionController
any
98cf165
to
87d814d
Compare
Either replaces `any` with `@ts-expect-error` directives or leaves them in place without a TODO to replace them. All remaining instances of `any` are defensible.
87d814d
to
0196028
Compare
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 you explain why things can't be typed where you kept the any
and what you mean where you're mentioning abusing types for testing purposes?
@@ -302,7 +302,6 @@ export class AccountsController extends BaseController< | |||
metadata: { ...account.metadata, name: accountName }, | |||
}; | |||
currentState.internalAccounts.accounts[accountId] = | |||
// @ts-expect-error Assigning a complex type `T` to `Draft<T>` causes an excessive type instantiation depth error. |
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.
So why was this breaking things if it wasn't before?
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 have absolutely no idea and I'm scared to find out. Although, it's technically not breaking something now, where it was broken before. Maybe some kind of interaction with the PermissionController
types mediated by Snaps-related imports? That's the only thing I can think of.
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.
This upstream bug currently affects Draft<T>
types and update()
calls in our codebase.
There's not much we can do about it on our end other than add (or remove) @ts-expect-error
annotations whenever the compiler breaks out with an "excessive type instantiation depth" error.
For update()
calls, returning a new state instead of mutating in place can sometimes help.
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.
What are your thoughts on keeping this comment in place and removing the type assertion instead?
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.
Whatever TS version and config my VS Code is using is unhappy about this, but removing both the cast and the ts-expect-error
seems to work: c54671b
packages/permission-controller/src/rpc-methods/getPermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/getPermissions.test.ts
Outdated
Show resolved
Hide resolved
fdf32e1
to
6b95853
Compare
c2c596f
to
f4cd213
Compare
@hmalik88 reposting for visibility:
I appreciate @MajorLift's idiom for this practice:
(Although he rightly accuses these tests of being sloppily typed as opposed to necessarily using |
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.
One question on keeping the ts-expect-error
, but this otherwise looks good to me.
packages/permission-controller/src/PermissionController.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/PermissionController.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/PermissionController.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/PermissionController.test.ts
Outdated
Show resolved
Hide resolved
I did a final pass and left a few more comments, but aside from those everything lgtm! |
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.
Looks good to me! Thanks for your patience with applying all of the suggestions. :)
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.
Some nits, but looks good regardless.
packages/permission-controller/src/rpc-methods/requestPermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/requestPermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/requestPermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/revokePermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/revokePermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/revokePermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/revokePermissions.test.ts
Outdated
Show resolved
Hide resolved
packages/permission-controller/src/rpc-methods/revokePermissions.test.ts
Outdated
Show resolved
Hide resolved
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.
Looks good!
Explanation
Replaces almost all
any
type casts with@ts-expect-error
directives or more specific types. Of the original 81any
type casts in the permission controller and its tests, only 3 remain. No behavioral changes.Changelog
None.
Checklist