-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
Change AbortController to default import #579
Conversation
@@ -1,7 +1,7 @@ | |||
import contractMap from '@metamask/contract-metadata'; | |||
import type { Patch } from 'immer'; | |||
import { Mutex } from 'async-mutex'; | |||
import { AbortController } from 'abort-controller'; | |||
import AbortController from 'abort-controller'; |
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.
Let's use a // eslint-disable-next-line
directive to avoid modifying the ESLint config
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.
Ok. Can do. Just wondering though is that a lint rule we want to preserve? It feels like we may have opted into it by default?
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.
Yeah we probably did, but the defaults are generally reasonable, and as a matter of expediency discussions about which lint rules we should use should be had on our ESLint config repo. For the purposes of this PR, I think it's best if we only concern ourselves about how we disable this particular rule for this particular instance.
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.
Fair! Will update!
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.
Although, now that we're here, I think that rule is good, because consider a module with both named and default exports. Many such packages exist, and the named and default exports are usually different. If you import the default export under the name of a named export, you find yourself in an annoying place if you ever also want to use the named export, since one of the names have to change. That seems bad to me!
This polyfill package is an exception in that the default and named export are the same thing, and IMO we should call them both AbortController
.
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.
Makes sense. I've swapped out the config change for a eslint-disable-next-line
1cc9eb2
to
f4ee38d
Compare
f4ee38d
to
659d374
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.
Just one more thing!
* Change AbortController to default import * Update src/assets/TokenListController.ts Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Change AbortController to default import * Update src/assets/TokenListController.ts Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
🤦
FIXED:
AbortController
(polyfill) constructor as a named import. Despite the package seeming to support named imports, this change seems to be required for the TokenListController to not blow up.