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,
}

appframe_js_-af-__projects_af-_rubymine_2017_2_eap

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)

Most upvoted comments

I believe this fails due to the same root cause:

export type QuerySingle<BaseQuery> = {|
  id: number,
  ...BaseQuery,
|}

in babel-plugin-flow-react-proptypes/lib/convertToPropTypes.js:165, spreadShape.properties.forEach explodes because spreadShape doesn’t have a properties property at all (possibly because it’s of type GenericTypeAnnotation?)

grrowl on Jan 3, 2018

@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.

brigand on Nov 13, 2019

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.

brigand on Nov 5, 2019

Is there any progress on this issue?

shanez on Nov 28, 2018

@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.

rosskevin on Sep 6, 2017

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.

mhaas on Jun 10, 2017