v2.9.1

Fixed

• Handling of optional JSDoc types ( @caabernathy , #89 )

v2.9.0

New: Type aliases and optional method parameter flag

@caabernathy added new information to method parameters ( #83 ). If the parameter has a flow type, the name of the type is no also included. I.e. if the type definition is:

export type StatusBarStyle = $Enum<{
     ...
}

the docs for a parameter of that type will include alias: "StatusBarStyle".

In addition the docs now include an optional field indicating whether the parameter is optional or nor.

v2.8.2

Fix/Improvement

• Better handling of method parameters ( #72 )

v2.8.1

I believe publishing 2.8.0 to npm didn't work properly, so this just to ensure that there is a working version in npm.

No changes in this release.

v2.8.0

New

@janicduplessis added support for extracting documentation about custom React component methods ( #66 ).

v2.7.0

New

This version adds a great new feature: Support for Flow type definitions. Thanks a lot to @danez for implementing this feature ( #48 ).

react-docgen is now able to extract type definitions as in this example:

import React, { Component } from 'react';

type Props = {
  /** Description of prop "foo". */
  primitive: number,
  /** Description of prop "bar". */
  literalsAndUnion: 'string' | 'otherstring' | number,
  arr: Array<any>,
  func?: (value: string) => void,
  obj?: { subvalue: ?boolean },
};

/**
 * General component description.
 */
export default class MyComponent extends Component<void, Props, void> {

  props: Props;

  render(): ?ReactElement {
    // ...
  }
}

In the JSON output, every prop will have a new field named flowType. If you use both, flow (for static type checks) and React propTypes (for dynamic type checks) you can do so without any collisions. The JSON blob now simply contains more information and you can decide which one to use for your documentation.

Have a look at the more extensive description in the README to learn how flow types are represented.

v2.6.3

Fixes

• propTypeHandler now ignores nodes that are not ObjectExpressions. If there was something else, e.g.

  propTypes: Foo.bar,
  

  propTypeHandler used to throw an error.

v2.6.2

Fixes

• Fixed docblock parsing for stateless named functions (function declarations) used as default exports ( #51, 0b8546a ).

v2.6.1

Fixes

• Fix docblock extraction for classes with decorators ( #49 , 44777a9 )

v2.6.0

New: --resolver CLI option

The --resolver lets you specify from the CLI which resolver^* to use. It can either be the name of a built-in resolver or a path to a JavaScript module that exports a resolver function:

react-docgen --resolver findExportedComponentDefinition ./path/to/component.js
# same as 
react-docgen ./path/to/component.js

react-docgen --resolver findAllComponentDefinitions ./path/to/component.js

react-docgen --resolver ./path/to/custom/resolver.js ./path/to/component.js

Read more about resolvers.

---

* Resolvers contain the logic to find React component definitions in the JavaScript files.