This re-introduces the possibility of an infinite dependency loop, for example adding export { COLORS as COLORS2 } from './index'; to button.tsx causes the chain index -> button -> index, throwing RangeError: Maximum call stack size exceeded

The bug - as demonstrated by the files within components/button - is that the first time a file is imported its resulting imports are cached -- however, those results are pruned by the named variables being imported which causes the cache to be invalid.

e.g. given the two imports in two different files:
import { ButtonIconSide } from './button';
import { ButtonColor } from './button';

the script encounters the first file and caches './button' = { ButtonIconSide }, when the second file is processed the same cache is used and ButtonColor is missed.

Two potential ideas for fixing

don't prune exports

Simply commenting out the if (importedTypeNames.includes(name)) { check results in the expected output; this check is in place for two reasons:

1. code simplicity - without pruning, the file's exports would resolve to all exports found while processing a given file, e.g. given index -> button -> common, index would be seen to have Omit - code would need to updated to prune to the file's exports instead of the values imported from it
2. performance - don't generate proptypes for unused values; this performance gain recedes when considering the codebase as a whole (most types are exported & used), but there is still overhead for any type and interface defined by a file but not exported.

change cache key

Instead of looking up caches by the resolved file path, the key could instead be the concatenation of the importing file + imported file. This allows pruning to remain as is while resolving the underlying bug.

I think I prefer option 2 as it touches less code and only introduces very marginal complexity.

Thanks for the deep look @chandlerprall
I went with option 2

Thanks again @thompsongl !

@chandlerprall Good call on the CL

Thanks for fixing it :)