Regression: Slowed Builds with react-docgen-typescript

[clintandrewhall]

Describe the bug

This is a regression from the resolved state of #6430. It may be an issue with RDTL, perhaps not. They have styleguidist/react-docgen-typescript#112 still open.

In that bug, @strothj and @denieler were able to improve react-docgen-typescript-loader to reuse the parser instance to improve performance. I've updated our dependencies to 5.1.11 and there has been a regression.

If I comment react-docgen-typescript-loader out, I get much faster build times:

To Reproduce
Steps to reproduce the behavior:

1. Enable react-docgen-typescript-loader for .tsx? files, as recommended.
2. Have a repo with 10+ stories.
3. See slow build time.

You can view our config here.

[shilman]

@clintandrewhall A few questions:

1. Is this a bug with storybook or with the overall experience of using it?
2. You say repo with 10+ stories, but in your config you've excluded *.example.tsx - does this fix the problem?
3. Do you know which files RDTL is running on? Is it possible there are .tsx files in node_modules that are getting unnecessarily processed?

[clintandrewhall]

@shilman

1. I'd say it's a bug that surfaces when adding Typescript documentation to components within stories using react-docgen-typescript/-loader.
2. I've excluded *.examples.tsx in that portion of the webpack config because without it, react-docgen-typescript tries to glean properties from my Storybook files, (which doubles the time).
3. I can alter the webpack config to also ignore node_modules... but it's unlikely our dependencies have many .tsx files in them. Additionally, this regressed without a change to that rule.

To be clear: this is exactly like the behavior in #6340, which was quickly solved by the change in RDTL 3.1.1. I was surprised to see it return. I've pored over the code there, and elsewhere, and don't see a clear cause. Rolling back those dependencies has no effect, either.

[clintandrewhall]

Excluding node_modules reduced startup time somewhat, about 20s. Is it possible to output how many files were processed?

[atanasster]

@clintandrewhall what do you think about #7942 - loading prop tables from file and generating prop tables manually only when interfaces are changed. Linked in there is also my custom scripts.
Another option i was considering to create a new webpack react docgen plugin that will resemble more the webpack uglify js plugin with caching and parallel execution options.

[clintandrewhall]

@atanasster @shilman a prop table cache would be sick.

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

[clintandrewhall]

Any update on this? I don't want this to go stale... it's still a time sync for us.

[atanasster]

@clintandrewhall i am getting back from an extended vacation and we discussed with michael to make my scripts into an external webpack plugin. Hopefully soon, but in the meantime you can try my wip scripts as i posted and let me know your input.
If you need help setting up the scripts, please send a message on discord, i will be happy to assist.

[atanasster]

@clintandrewhall :
I just released https://github.com/atanasster/webpack-react-docgen-typescript for caching and speed up of parsing typescript prop tables. Feedback and issues welcome to get it stable

[The-Code-Monkey]

@shilman any update as to when this issue will be fixed and what version it will be fixed in?

[shilman]

@The-Code-Monkey yes. we are recommending a new configuration in 6.0 and will be updating the docs this week.

[thany]

@atanasster Sorry to but in, but since I'm experiencing this issue as well, I thought I'd try your plugin.

Our build time almost doubled. Went from 54sec to 1.8min 🤔
I suppose it needs to build up caches. So I gave it one more build, and that time it finished in 52sec. So that's back to where we started. A difference of 2sec over almost a minute is within the margin of error.

Any ideas?

[shilman]

@The-Code-Monkey @thany 6.0 recommendations updated here https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#react-prop-tables-with-typescript

[thany]

Excellent! But unfortunately that requires Storybook 6.0, doesn't it?
If only 6.0 would be final. That's why I'm hunting for a solution in 5.3.

[shilman]

@thany I believe it should work with 5.3 as well. Please give it a try!

[shilman]

We've just released zero-config typescript support in 6.0-beta. Please upgrade and test it!

• Release 6.0.0-beta.12+
• Migration instructions
• Updated docs

Thanks for your help and support getting this stable for release!

[rafaelalmeidatk]

I finished migrating a project from 5.3 to 6.0 and I don't have problem with the TS increased times anymore. The difference is amazing, from ~3 minutes to ~21 seconds:

[coreybruyere]

I recently had to wipe node modules and package-lock while debugging an issue when implementing jest+enzyme into a project and am now getting extremely slow start times for Storybook. Initially I was getting this error:

'loose' mode configuration must be the same for @babel/plugin-proposal-class-properties, @babel/plugin-proposal-private-methods and @babel/plugin-proposal-private-property-in-object (when they are enabled).

but seemed to have resolved it with this.

Can't share my repo since it's for my company, but here's my main.ts:

module.exports = {
  stories: ['../packages/**/stories/*.stories.@(ts|tsx|mdx)'],
  addons: [
    '@storybook/addon-actions',
    '@storybook/addon-links',
    '@storybook/addon-docs',
    '@storybook/addon-a11y/register',
    '@storybook/addon-viewport/register',
    '@storybook/addon-knobs/register'
  ],
  typescript: {
    check: false,
    checkOptions: {},
    reactDocgen: 'react-docgen-typescript',
    reactDocgenTypescriptOptions: {
      compilerOptions: {
        allowSyntheticDefaultImports: false,
        esModuleInterop: false
      },
      propFilter: (prop) => {
        if (prop.parent) {
          return !prop.parent.fileName.includes('react') && !prop.parent.fileName.includes('styled-components');
        }

        return true;
      }
    }
  }
};

and all Storybook related dependencies:

    "@storybook/addon-a11y": "^6.2.0",
    "@storybook/addon-actions": "^6.2.0",
    "@storybook/addon-docs": "^6.2.0",
    "@storybook/addon-info": "^5.3.21",
    "@storybook/addon-knobs": "^6.2.0",
    "@storybook/addon-links": "^6.0.21",
    "@storybook/addon-viewport": "^6.2.0",
    "@storybook/addons": "^6.0.21",
    "@storybook/cli": "^6.0.21",
    "@storybook/core": "^6.2.0",
    "@storybook/react": "^6.2.0",
    "@types/storybook__react": "^5.2.1",
    "react-docgen-typescript-loader": "^3.3.0",

Nothing has changed and I'm wondering what to be looking out for in my config that might need to be updated? It usually takes 1 minute or more for Storybook to start.

[shilman]

@coreybruyere All of your storybook package versions should match.

You can do this automatically (recommended) by:

• stable: npx sb upgrade
• prerelease: npx sb upgrade --prerelease

[coreybruyere]

@shilman - Thanks. That seems to have worked. Not sure what happened to my babelrc but I ended up having to add these changes like someone else noted in this thread:

"plugins": ["@babel/plugin-proposal-class-properties", "@babel/plugin-proposal-private-methods"],

[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).