You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be great to be able to mix-n-match between library-owned/community denylist entries and project-private ones that we write for ourselves. We'd need a way for the detector to accept additional DenyListedEntry instances that our project could pass in, or something to that effect.
We've forked this lint check as a workaround and just maintain an internal copy of it (thank you for open-sourcing this! 🙏), but when we do that, we lose out on any updates that are pushed to the denylist in the future unless we actively merge upstream changes back into our fork.
I'm curious if there's additional consideration that's motivating keeping the denylist detector & entry class internal that I might be missing?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
It'd be great to be able to mix-n-match between library-owned/community denylist entries and project-private ones that we write for ourselves. We'd need a way for the detector to accept additional
DenyListedEntry
instances that our project could pass in, or something to that effect.We've forked this lint check as a workaround and just maintain an internal copy of it (thank you for open-sourcing this! 🙏), but when we do that, we lose out on any updates that are pushed to the denylist in the future unless we actively merge upstream changes back into our fork.
I'm curious if there's additional consideration that's motivating keeping the denylist detector & entry class internal that I might be missing?
Beta Was this translation helpful? Give feedback.
All reactions