react-docgen-typescript causes styleguidist to bomb fatally if it can't parse props

[RoystonS]

Hi! Thanks very much for react-docgen-styleguidist. We're making good progress on creating a living style guide for our in-house documents thanks to it!

One blocking issue, however, is the impact on styleguidist when react-docgen-typescript can't parse the props in one component: it fails catastrophically with the dreaded TypeError: Cannot read property 'methods' of null error, and prevents the entire styleguide from being generated.

Our workaround right now is to remove that component from the styleguide, but it would be really helpful to be able to have a component in the styleguide even if react-docgen-styleguidist can't figure out props for it, so we can provide examples and live views of the component.

Here's an example of one of our problematic components, where we're using glamorous to produce a simple low-level styled component:

import glamorous from 'glamorous';
import { ITheme } from './ITheme';

export const BodyText = glamorous.span({
}, (_props: any, theme: ITheme) => ({
    color: theme.bodyTextColor,
    fontSize: theme.bodyTextSize
}));

export default BodyText;

It would be unreasonable to expect react-docgen-stypescript to figure out the props for that, but it would be great if it could still advertise a BodyText component with enough data to prevent styleguidist from blowing up, allowing a BodyText.md file to be created with examples.

Thanks!

[pvasek]

You are right that one of the biggest issues of this project is its stability in different use cases. There are so many possibilities how to define a component and its props for react + all combination of types that you can use in typescript that's really hard to support them all.

In this particular case the biggest problem is to guess that the BodyText is react component. I guess that right now it won't be recognise as react component.

If we make it less strict then there can be classes that you have in your components that will be reported as react component but in fact they are not.

Maybe there could be an option how to handle these cases but not sure if that could work. Any ideas how this could be handled? How that could be recognised from the code you provided?

[RoystonS]

Indeed. It would be impossible to handle every possible option.

Yep, making it less strict would likely cause lots of problems. We could potentially have some extra logic that only kicks in if everything else has failed, thereby not causing anything new to emerge in existing files.

I guess that I've given styleguidist one key piece of information to tell it that there's a component in here somewhere: the file is listed in styleguide.config.js#components.

So, what if rds were to say "Hey, you told me there was supposed to be a component in this file, but I haven't found anything that matches my current rules. I'll assume that you're not stupid and that there is a component here somewhere, so let's assume that one of the variables or classes you're exporting (starting with the one mentioned in export default, or failing everything, just the name of the file) is the component - and I'll make up an empty set of props for it. At least you'll be able to document the thing by putting a BodyText.md file next to it."

That wouldn't affect any existing files where there are detected components: it would just guarantee that if nothing was found, styleguidist wouldn't fail, and it would still be possible to provide docs for something.

[pvasek]

That sounds good. You are right that if you define it in components there should be at least component somewhere. The problem can be that if you have props+component defined in the single file then you have two exports and need to decide which one is correct.

But anyway your proposed "everything fails" solution is brilliant and it should be simple to implement as well. We could probably start with that.