[flow] import type from another file does not resolve the type information

[rosskevin]

Problem

import type from another file does not resolve the underlying type information

breakpoints.js used throughout the project:

export type Breakpoints = 'xs' | 'sm' | 'md' | 'lg' | 'xl';

Hidden.js component:

import type { Breakpoints } from '../styles/breakpoints';

type Props = {
  /**
   * Hide the given breakpoint(s).
   */
  only?: Breakpoints | Array<Breakpoints>,
}

Expected result

When I place the type Breakpoints locally in the file (no import type), I get the expected result:

Placing every type inside the file is a non-starter though, as it severely limits reuse of types throughout the application.

[fkling]

react-docgen only looks at files in isolation since it doesn't know how to resolve dependencies. This is basically a duplicate of #33.

A typical workaround is to process the type definition file separately to extract the type information and join the data yourself.

That said, I'm open to suggestions how we could solve this, bearing in mind that the module identifier resolution process must be pluggable/exchangeable.

[rosskevin]

At the root, this does look like a duplicate of #33.

Regarding module resolution, I suspect it will have to be rather smart or reuse something from node or flow. I am unfamiliar with the code here, so not sure about the challenges, but let me just add some pertinent details.

Flow types are available from:

1. libdefs - as set by the [libs] in the .flowconfig
2. libdefs - as available in the <PROJECT_ROOT>/flow-typed directory
3. shadow files - as available in any node_modules/* as *.js.flow files. e.g. flow-source-copy is script that helps distribute flow types with a package.
4. localized in a single file in the project
5. imported by a project file

libdefs are globally available or bound to a module namespace, whereas import type works just as you would import any other js function etc (either from a node_module or local file).

[rosskevin]

I'm trying to venture down this path but I'm afraid I know little about this toolset.

I presume I would:

1. Determine import type statements
2. Gather exported flow types
3. Recurse over all files found in number 1, until no more import type declarations found
4. Do a normal parse
5. Merge flow type definitions

First thing is to discover the types imported and from where. I determined how to get the information but not how to return it through the resolver/handler. I unclear if I'm on the right track or even using the full capability of this toolset.

Called from our api-docs/index.js

reactDocgen.parse(src, findFlowTypeImportDefinitions)

// @flow
import { utils } from 'react-docgen';
import type { NodePath } from './types';

/**
 * Given an AST, this function tries to find the exported flow type definition.
 */
export default function findFlowTypeImportDefinitions(
  ast: ASTNode,
  recast: Object,
): ?NodePath {

  function importTypeDeclaration(path: NodePath) {
    let definition
    if (path.node.importKind === 'type') {
      if (path.node.specifiers) {

        // to be done in the handler?
        //const specifiers = path.get('specifiers');
        //specifiers.each(
        //  (specifier) => {
        //    const local = specifier.get('local');
        //    types.push(local.value.name);
        //  },
        //);
        // structure return representing types import?
        //return {
        //  module: path.node.source.raw,
        //  types: types,
        //};


        definition = path;
      }
    }

//    if(!definition) {
//      return false;
//    }
    return false;
  }

  recast.visit(ast, {
    visitImportDeclaration: importTypeDeclaration
  });
}

I've got a branch started with these experiments.

Any guidance is appreciated. We need to solve this before our next major release.

[rosskevin]

It seems that a new plugin inline's the flow types, this might solve this problem for me altogether.

https://twitter.com/thejameskyle/status/870764494917582850

https://github.com/thejameskyle/babel-plugin-react-flow-props-to-prop-types

[danez]

Duplicate of #33