Docs addon fails to render props table when source code uses default export types

[kylemh]

Describe the bug
In a TypeScript React (non-CRA) setup with the Docs addon and the react-docgen-typescript-loader, the props table will not work if you use the React default export's properties for type definitions.

(Please ignore the fact that the example uses React.FC. It's still an issue outside of this.)

In other words...
WORKS:

import React, { ButtonHTMLAttributes, FC } from 'react';

export interface Props extends ButtonHTMLAttributes<HTMLButtonElement> {
  isDisabled?: boolean;
}

export const Button: FC<Props> = ({ isDisabled = false, ...props }: Props) => (
  <button disabled={isDisabled} {...props} />
);

DOES NOT WORK:

import React from 'react';

export interface Props extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  isDisabled?: boolean;
}

export const Button: React.FC<Props> = ({ isDisabled = false, ...props }: Props) => (
  <button disabled={isDisabled} {...props} />
);

For what it's worth, if you use a named export type for FC, but keep doing React.ButtonHTMLAttributes, then you'll only see isDisabled defined in the table.

To Reproduce
Steps to reproduce the behavior:

1. npx -p @storybook/cli sb init --type react

2. yarn add -D ts-loader @storybook/addon-docs @storybook/addon-info react-docgen-typescript-loader react-is babel-loader

3. .storybook/main.js:

module.exports = {
  stories: ['../src/**/*.stories.(tsx|mdx)'],
  addons: ['@storybook/addon-actions', '@storybook/addon-links', '@storybook/addon-docs'],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve('ts-loader'),
          options: {
            transpileOnly: true,
          },
        },
        {
          loader: require.resolve('react-docgen-typescript-loader'),
        },
      ],
    });

    config.resolve.extensions.push('.ts', '.tsx');

    return config;
  },
};

and create some stories to compare!

Expected behavior
I should be able to create stories regardless of how I use types from dependencies.

System:

Environment Info:

  System:
    OS: macOS Mojave 10.14.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 10.18.1 - ~/.nvm/versions/node/v10.18.1/bin/node
    Yarn: 1.21.1 - ~/.nvm/versions/node/v10.18.1/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v10.18.1/bin/npm
  Browsers:
    Chrome: 79.0.3945.130
    Safari: 13.0.4
  npmPackages:
    @storybook/addon-actions: ^5.3.6 => 5.3.6 
    @storybook/addon-docs: ^5.3.7 => 5.3.7 
    @storybook/addon-info: ^5.3.7 => 5.3.7 
    @storybook/addon-links: ^5.3.6 => 5.3.6 
    @storybook/addons: ^5.3.6 => 5.3.6 
    @storybook/react: ^5.3.6 => 5.3.6 

[jeffu92]

My understanding is that this has been an issue for a while and is due to the limitations of react-docgen-typescript-loader, due to its reliance on react-docgen-typescript.

The limitations are called out at https://www.npmjs.com/package/react-docgen-typescript-loader#limitations and https://github.com/styleguidist/react-docgen-typescript#example.

I would love for this to be addressed too if possible.

[shilman]

@jeffu92 are you familiar with react-docgen's typescript support? we're hoping to move to that in 6.0 to simplify things and hopefully address some of these issues.

[jeffu92]

@shilman Not particularly, unfortunately. I just ran into this issue myself recently, so figured I'd share what I found.

[kylemh]

@jeffu92 FWIW the link you shared is discussing the need for your source code to use named exports. I don’t think they realize the limitation of using default exports from dependencies as external types.

[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!

[kylemh]

still a bug

[shilman]

Repro: 92f8c43

[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!

[kylemh]

Go away

[shilman]

@kylemh can you try the recommended 6.0 setup (should work in 5.3 too) and based on the repro linked above I expect the problem to be fixed:

https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#react-prop-tables-with-typescript

[kylemh]

I'll give it a whirl tomorrow!

[kylemh]

I gave this a try in other projects, but wasn't successful - although I'm a bit sleep-deprived.

Theoretically, I should be able to take this minimal TSDX + React + Storybook repo, and do:

1. yarn remove react-docgen-typescript-loader
2. yarn add @storybook/preset-typescript (to get latest version of preset)
3. Move preset declaration from .storybook/main.ts's addons field (as opposed to presets field).

And be good to go, right?

[kylemh]

Seems to still be an issue, but it sounds like there's a PR for the fix here:
reactjs/react-docgen#352

Please ignore the fact that the example uses React.FC. It's still an issue outside of this.

[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!

[kylemh]

reactjs/react-docgen#352 is still open 🤷

[shilman]

Yeah @kylemh I still don't have a good strategy to deal with this. Fixing bugs in react-docgen or react-docgen-typescript is probably outside the scope of what we can handle in Storybook. In the short term I'm afraid we'll have to support both to some degree. Although it is a code / documentation / support nightmare.

[kylemh]

Since the solution is outside the scope of the project, please feel free to close the issue!

[uyarn]

Any progress in this issue? @shilman

[shilman]

Reopening this. Although this is a limitation of another library, we should track it and figure out a fix one way or another.

[shilman]

We’re cleaning house! Storybook has changed a lot since this issue was created and we don’t know if it’s still valid.

Please open a new issue referencing this one if:

• this is still a problem in SB 7.x
• you can provide a consistent reproduction in 7.x (at https://storybook.new/ or per repro docs).