RDTL: "No props found for this component" when using const export

[Vanuan]

Describe the bug
When the component module exports a component as a constant, I see this message:
"No props found for this component"

To Reproduce

import { IButtonProps } from './types';
export const Button = (props: IButtonProps) => <button>{props.children}</button>;

export default {
  title: 'atoms|Button',
  component: Button,
}

Expected behavior

I expect to see a property table.

Screenshots

Code snippets

    webpackFinal: async config => {
      config.module.rules.push({
        test: /\.(ts|tsx)$/,
        use: [
          {
            loader: require.resolve('ts-loader'),
            options: {
              configFile: path.resolve(__dirname, './tsconfig.json'),
              transpileOnly: true,
            },
          },
          // Automatics props
          {
            loader: require.resolve('react-docgen-typescript-loader'),
          },
        ],
      });
      config.resolve.extensions.push('.ts', '.tsx');
      return config;
    },
  };

System
storybook/react "5.3.17"
react-docgen-typescript-loader "3.7.2"

Additional context
Maybe it's a react-docgen issue.

[Vanuan]

The crucial part is that using this syntax works:

import { IButtonProps } from './types';
const Button = (props: IButtonProps) => <button>{props.children}</button>;
export { Button };

[Vanuan]

Related issues I could find but don't appear to be exact duplicates:

• No props appearing for named function export with Addon-docs #9205 This is when props interface declared in a different file. But it appears to be working
• Prop table broken in 5.3.2 with propTypes #9415 This when using propTypes. Not using it
• addon-docs: "No props found for this component" when component is exported in camelCase #9575 This is a camel case export issue. This uses UpperCase
• addon-docs: Props doesn't work when using React.memo. #9586 This is when using React.memo. Not using it
• addon-docs: No props for some components #9592 This is an issue with <Props. I'm using CSF.

The only relevant suggestion is this:
https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#react-prop-tables-with-typescript

But it looks like this is available since sb 6.0. Should I still be using react-docgen-typescript-loader in sb 5.3.x?

[shilman]

@Vanuan the 6.0 setup should also work in 5.3. But it's a breaking change, which is the primary reason I haven't called it a 5.3 change. Can you try that?

[Vanuan]

@shilman I tried that and it doesn't work at all. It looks like it's documented to not work, so I created a PR to clarify that it only works with RDTL: #10276

Could you tell what's the relationship between react-docgen and react-docgen-typescript?

It looks like react-docgen is created by Facebook, while react-docgen-typescript is by styleguidist?

Why do you recommend using Facebook's version if typescript support is incomplete there? Or doesn't work at all practically for projects which provision types in a separate file.

What's the state of RDTL support in Storybook? Should I post bugs to another repository?

[shilman]

AFAIK react-docgen and react-docgen-typescript are parallel projects that do similar things. The former supports JS/Flow/TS as of 5.0, and the latter supports TS.

Here's the rationale for the move:

1. After releasing Props support in SB5.2, I've handled over 100 issues related to RDTL and created repro test cases for many of them. Nearly all of them work correctly in react-docgen.
2. Standardizing on a single package simplifies things. Furthermore, it looks like more of the ecosystem is using Babel for TS processing (e.g. CRA) and I remember hearing that it's actually recommended. So the move is consistent with that, and brings us closer to zero-config TS support in Storybook (take my word for it, this is a whole other can of worms.)
3. react-docgen seems to be more active than react-docgen-typescript, so the hope is that issues will get fixed there more quickly.
4. Even styleguidist, which publishes react-docgen-typescript switched to react-docgen as its default in the latest release.

As for how this all relates to Storybook, frankly I'm still figuring it all out. Even though SB Docs is relatively new, it already has more users than both Styleguidist and Docz combined (according to NPM downloads). I'm hoping with everybody standardizing on react-docgen, it will help push that project into shape.

Please feel free to keep filing issues here. Since Storybook is the primary interface to both of these tools for a lot of people, I hope we can figure out a structured way to track the issues in SB, and also make sure they get filed into the respective tools so that the maintainers of RTDL and react-docgen can fix them in their own ways and at their own pace. In the meantime, I'll try to support both options since neither of them is satisfactory yet, IMHO.

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[danielo515]

I having this same issue. But surprisingly it works just fine with addon-info:

And this is what I get with Addon docs:

[shilman]

addon-info uses the runtime propTypes information. this check was deleted in 5.3 because it masks other errors when docgen is configured incorrectly, and docgen info is generally preferable to runtime information.

However, I'm considering adding it back in 6.0. cc @patricklafrance

[danielo515]

Hello @shilman , thanks for your response.
Would you mind to list as an overview some of those problems?
I'm interested on getting flow info as prop types. Is this supported rigth now?

[shilman]

@danielo515 docgen typically either works or doesn't work. if it works, it does stuff like includes jsdoc comments, processes tags out of those jsdoc comments like @ignore and a bunch of other stuff like summary/detail for types and default values. if docgen is not properly set up, you get no prop table at all.

if the runtime type information is parsed as a fallback, you get whatever limited information is included in the runtime information, which is much less than what's in docgen, e.g. it won't contain the docgen descriptions. so we'd get support issues like "why are my props showing up but none of the descriptions?". so @patricklafrance deleted that runtime type information to simplify things and also make it clearer when docgen is working or not. i hope that answers your question.

as for flow types, they are supported by react-docgen. they should work in storybook as well, but they are not officially supported by storybook. meaning that flow-related questions/bugs will get lowest priority from me. however, we have tens of thousands of users--some of whom use flow--so hopefully you can get support from the community if you go that route.

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[stale]

Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Storybook!