Skip to content
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

Merged
merged 18 commits into from
Apr 26, 2024

Conversation

rekmarks
Copy link
Member

@rekmarks rekmarks commented Apr 16, 2024

Explanation

Replaces almost all any type casts with @ts-expect-error directives or more specific types. Of the original 81 any type casts in the permission controller and its tests, only 3 remain. No behavioral changes.

Changelog

None.

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've highlighted breaking changes using the "BREAKING" category above as appropriate

@rekmarks rekmarks requested a review from a team as a code owner April 16, 2024 18:39
@rekmarks rekmarks force-pushed the rekmarks-permission-controller-cleanup branch from 391be86 to 69c78bb Compare April 16, 2024 18:40
@rekmarks rekmarks changed the title Clean up use of any in PermissionController refactor(permission-controller): Clean up use of any Apr 16, 2024
@rekmarks rekmarks force-pushed the rekmarks-permission-controller-cleanup branch 2 times, most recently from 98cf165 to 87d814d Compare April 17, 2024 15:24
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.
@rekmarks rekmarks force-pushed the rekmarks-permission-controller-cleanup branch from 87d814d to 0196028 Compare April 17, 2024 23:50
@rekmarks rekmarks requested a review from a team as a code owner April 17, 2024 23:56
@legobeat legobeat requested a review from MajorLift April 18, 2024 02:26
Copy link
Contributor

@hmalik88 hmalik88 left a 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.
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Member Author

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/Caveat.ts Show resolved Hide resolved
@rekmarks rekmarks force-pushed the rekmarks-permission-controller-cleanup branch from fdf32e1 to 6b95853 Compare April 19, 2024 16:55
@rekmarks rekmarks force-pushed the rekmarks-permission-controller-cleanup branch from c2c596f to f4cd213 Compare April 19, 2024 17:01
@rekmarks
Copy link
Member Author

rekmarks commented Apr 19, 2024

@hmalik88 reposting for visibility:

This is just replacing the previous any types with a @ts-expect-error directive. Either way, we are "abusing" our types by intentionally violating them. The reason for this "abuse" is that we are testing runtime errors that can only be produced through invalid TypeScript.

I appreciate @MajorLift's idiom for this practice:

intentional destructive testing

(Although he rightly accuses these tests of being sloppily typed as opposed to necessarily using any, much of the time.)

Copy link
Contributor

@mcmire mcmire left a 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.

@rekmarks rekmarks requested a review from MajorLift April 22, 2024 21:25
@rekmarks rekmarks requested a review from mcmire April 22, 2024 21:25
@MajorLift
Copy link
Contributor

I did a final pass and left a few more comments, but aside from those everything lgtm!

@rekmarks rekmarks requested a review from MajorLift April 24, 2024 02:24
MajorLift
MajorLift previously approved these changes Apr 24, 2024
Copy link
Contributor

@MajorLift MajorLift left a 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. :)

mcmire
mcmire previously approved these changes Apr 25, 2024
Copy link
Contributor

@mcmire mcmire left a 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.

@rekmarks rekmarks dismissed stale reviews from mcmire and MajorLift via 834d764 April 25, 2024 23:07
Copy link
Contributor

@mcmire mcmire left a comment

Choose a reason for hiding this comment

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

Looks good!

@rekmarks rekmarks merged commit 843a794 into main Apr 26, 2024
139 checks passed
@rekmarks rekmarks deleted the rekmarks-permission-controller-cleanup branch April 26, 2024 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants