babel-plugin-flow-react-proptypes: Object type spread failing on imported type from other module or libdef (e.g. flow-typed)
babel-7
branch - I’m looking into this. found
is in a local libdef.
import type {RoutingState} from 'found'
type Props = {
...$Exact<RoutingState>,
classes: Object,
children?: Element<*>,
currentUser?: CurrentUser,
t: Function,
width: string,
}
TypeError: src/App/AppFrame.js: Cannot read property 'key' of undefined
at /Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/makePropTypesAst.js:154:19
at Array.map (native)
at makeObjectAstForShape (/Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/makePropTypesAst.js:153:48)
at makePropTypesAstForPropTypesAssignment (/Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/makePropTypesAst.js:43:12)
at annotate (/Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/index.js:101:85)
at /Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/index.js:181:20
at Array.forEach (native)
at PluginPass.ClassDeclaration (/Users/kross/projects/ui/node_modules/@alienfast/babel-plugin-flow-react-proptypes/lib/index.js:178:29)
at newFn (/Users/kross/projects/ui/node_modules/babel-traverse/lib/visitors.js:266:21)
at NodePath._call (/Users/kross/projects/ui/node_modules/babel-traverse/lib/path/context.js:71:18)
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 4
- Comments: 31 (27 by maintainers)
I believe this fails due to the same root cause:
in
babel-plugin-flow-react-proptypes/lib/convertToPropTypes.js:165
,spreadShape.properties.forEach
explodes becausespreadShape
doesn’t have aproperties
property at all (possibly because it’s of typeGenericTypeAnnotation
?)@TSMMark that might happen if you have a type import (
import type ...
), since at the point the import is reached, we don’t know whether or not we need it at runtime. The import is modified such that the babel flow plugin won’t strip it, and then we can use it later if you refer to the type in a place that we process.I apologize for such a long standing issue.
@TSMMark I might be able to work on this on the weekend, but if you have some time, I would very much appreciate a PR that either makes this fail softly or one that actually implements the expected behavior with exact types + spread.
Is there any progress on this issue?
@UchihaVeha - that is the exact case for this issue, it does not import the type from another file so it is null and fails. If type
TodoView
were in the same file, it would work.I found some interesting discussion here:https://github.com/codemix/flow-runtime/issues/27
They apparently have a tool that preprocesses libdefs and makes them available.