[compiler][ez] Option to bail out on blocklisted imports #30643
Conversation
[ghstack-poisoned]
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
| import {getOrInsertDefault} from '../Utils/utils'; | ||
|
|
||
| export function validateRestrictedImports( | ||
| path: NodePath<t.Program>, |
There was a problem hiding this comment.
Hmm we should be able to use LoadGlobal’s binding information to see if a dangerous import is actually used in a particular component/hook.
Is there a motivating use-case to check at the program level or was that just an easy way to do the check?
There was a problem hiding this comment.
@josephsavona My understanding is that there were a few cases when we wanted to bail-out on higher-level component logic. I also thought about bailing out on LoadGlobal (NonLocalBinding.module), but another issue is that it doesn't follow aliasing or data flow (e.g. I may alias or do a PropertyLoad off of an import).
From my understanding, the modules we want to bail out on are pretty rarely imported (~20 matches internally). They are also React-related (e.g. createContainer or exporting a dangerous hook function).
There was a problem hiding this comment.
I think so far, we were able to avoid using this (it's really not a scalable option) by relying on Flow + compiler bailouts. For now, the restricted modules aren't used enough for false positives to matter -- false negatives on the other hand might be annoying to debug.
We can re-evaluate / rewrite if our rollout strategy changes
[ghstack-poisoned]
…ng logic in Program" --- Drive-by cleanup when writing #30643 [ghstack-poisoned]
…ram" --- Drive-by cleanup when writing #30643 [ghstack-poisoned]
[ghstack-poisoned]
Stack from ghstack (oldest at bottom):