-
-
Notifications
You must be signed in to change notification settings - Fork 312
fix: Allow passing strings instead of enums #1646
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
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for creative-fairy-df92c4 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@wxt-dev/analytics
@wxt-dev/auto-icons
@wxt-dev/browser
@wxt-dev/i18n
@wxt-dev/module-react
@wxt-dev/module-solid
@wxt-dev/module-svelte
@wxt-dev/module-vue
@wxt-dev/storage
@wxt-dev/unocss
@wxt-dev/webextension-polyfill
wxt
commit: |
@@ -13209,7 +13209,7 @@ export namespace Browser { | |||
/** | |||
* A list of request types. Requests that cannot match any of the types will be filtered out. | |||
*/ | |||
types?: ResourceType[] | undefined; | |||
types?: (ResourceType | `${ResourceType}`)[] | undefined; |
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.
Downside to this approach: ResourceType
is actually a string literal union here. There's another enum further down that is named ResourceType
, so this type was also modified.
This might be fine now, but as @types/chrome
is updated, this approach might cause problems in the future.
Overview
Addresses concerns mentioned here:
Warning
Not sure if I want to actually merge this PR or not... The regex approach isn't very clean, and it makes mistakes. I think it would make more sense to update
@types/chrome
directly to allow using string litterals in specific cases, like they already do.Manual Testing
See new type test