Storybook webpack builds hide errors by default and don't handle failure

[tomjn]

Describe the bug

When building the storybook, webpack shows the progress and can hang due to an error. However, there are no clues to what this error is and no handling of the error.

For example:

odules/prettier/standalone.js as it exceeds the max of 500KB.
15% building 1/11 entries 775/797 dependencies 58/283 modules^C

Here it will proceed incrementing the numbers until it reaches that point, then it never proceeds or exits. There are no error messages, no logs, no warnings. This happens across many versions of Storybook 6.x and has happened on both Webpack 5 and Webpack 4 over the span of many months. I've also heard this happen from friends who use independent unrelated stacks that also use Storybook, and they too are none the wiser.

Looking up debugging steps for this issue reveals people who accidentally fixed their webpack issue and storybook started working again, but no debugging steps, no error logs, no methods for diagnosing the issue.

To Reproduce

Unknown at this time, sometimes it will randomly happen to us in CI but not locally, and a rebuild will make it proceed without problems, only to happen again several hours/days later.

System

❯ npx sb@next info                                                                           
Need to install the following packages:
  sb@next
Ok to proceed? (y) y
npm WARN deprecated urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated fsevents@1.2.13: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.

Environment Info:

  System:
    OS: macOS 12.1
    CPU: (8) arm64 Apple M1 Pro
  Binaries:
    Node: 14.18.2 - ~/.nvm/versions/node/v14.18.2/bin/node
    npm: 7.24.2 - ~/.nvm/versions/node/v14.18.2/bin/npm
  Browsers:
    Chrome: 96.0.4664.110
    Safari: 15.2
  npmPackages:
    @storybook/addon-a11y: ^6.4.9 => 6.4.9 
    @storybook/addon-actions: ^6.4.9 => 6.4.9 
    @storybook/addon-essentials: ^6.4.9 => 6.4.9 
    @storybook/addon-links: ^6.4.9 => 6.4.9 
    @storybook/addon-postcss: ^2.0.0 => 2.0.0 
    @storybook/addon-storyshots: ^6.4.9 => 6.4.9 
    @storybook/addons: ^6.4.9 => 6.4.9 
    @storybook/builder-webpack5: 6.4.9 => 6.4.9 
    @storybook/manager-webpack5: 6.4.9 => 6.4.9 
    @storybook/react: ^6.4.9 => 6.4.9 

This has also happened on multiple Intel Macs, MacOS 11, Circle CI running an ubuntu image, an AWS build server, under Storybook 6.3, 6.2, etc.

Additional context

How do you debug this? I'm not interested in solving my specific case if it means I'm just as lost when another issue crops up in 6 months time and there's no debugging or troubleshooting steps.

Also, how do I use the webpack config dump if half the entries are like this: dirxml: [Function: dirxml],

[tomjn]

I attempted to run the storybook build using --inspect on Node and tried to pause the debugger after storybook had hung to see where it had hung and VSCode failed to pause and give me any information

[tomjn]

Also --loglevel doesn't appear to have any influence on the output, neither --loglevel silly or --loglevel verbose changes the output.

It appears storybook has no recovery/troubleshooting/debugging step for this, and should have exited with an error code but has not. It took a cmd+c force quite or crashing the node process deliberatley to trigger an exit code

The closest I can get to useful debugging information so far is running the command with --inspect and attaching the Chrome debugger, which crashes the Node process immediately with:

``` 15% building 1/11 entries 374/411 dependencies 7/220 modules[BABEL] Note: The code generator has deoptimised the styling of /Users/tomjn/..../node_modules/prettier/standalone.js as it exceeds the max of 500KB. 15% building 1/11 entries 772/797 dependencies 58/281 modulesDebugger attached. Debugger ending on ws://127.0.0.1:9229/2bd9de00-e4a3-42d7-a4c2-0c489852349d For help, see: https://nodejs.org/en/docs/inspector /Users/tomjn/..../node_modules/sass/sass.dart.js:3722 while (true) ^ RangeError: Maximum call stack size exceeded at /Users/tomjn/..../node_modules/sass/sass.dart.js:3722:11 at call$2 (/Users/tomjn/..../node_modules/sass/sass.dart.js:27826:12) at call$1 (/Users/tomjn/..../node_modules/sass/sass.dart.js:27814:32) at _rootRunUnary (/Users/tomjn/..../node_modules/sass/sass.dart.js:4098:18) at /Users/tomjn/..../node_modules/sass/sass.dart.js:96848:16 at runUnary$2$2 (/Users/tomjn/..../node_modules/sass/sass.dart.js:29232:39) at call$0 (/Users/tomjn/..../node_modules/sass/sass.dart.js:28295:51) ```

[shilman]

Do you a have a reproduction repo you can share? If not, can you create one? See how to create a repro. Thank you! 🙏

[tomjn]

@shilman I think you've missed the point, I'm sure I could eventually find out the specific thing causing my specific problem, that would be great for me this one time, but useless to everybody else.

This is not a user support issue, this is a bug report.

This issue is not about me and my specific problem on my project, it's about you and storybook just "hanging" frozen..

I am reporting a bug in Storybooks error handling mechanism.

This is the issue:

• When a webpack build fails, Storybook hangs and shows no useful information
• There is no documentation acknowledging this can occur or what to do
• There are no logs detailing what happened
• Sometimes the issue is non-deterministic, making it even more difficult to guess what the error is
• Storybook should just hand you the error in the CLI output, but it does not.

[tomjn]

I also cannot give you a reproduction repo because I do not know the cause of my problem, and I have no mechanisms, no debugging steps, no logs, no error reporting, nothing, absolutely nothing I can use to diagnose or debug this issue. That is the bug. Storybook should have printed the error, it does not, it does nothing, it just hangs with no explanation.

[tomjn]

Also, if I trigger this deliberately in a reproduction repo, that will be useless to me because I already know what caused it (me), and nothing will get fixed on the storybook side

[shilman]

@tomjn I think you're the one who's missing the point. I have seen hundreds of different Storybooks with webpack errors that cause Storybook to crash WITH an error. I have yet to see a clean example of Storybook hanging like this without any errors. I don't doubt it's a bug in Storybook but please explain how I can debug the problem if I can't reproduce it myself?

[tomjn]

That's the problem though, I do not know how to reproduce it without giving you access to a full confidential client repository, but my understanding is if I did and you helped, you'd find the problem, fix it for me and my project, then close the issue. It's incredibly frustrating precisely because there is so little information, getting what I've provided in this issue has already required me to sink days of developer time trying to dig into storybook code and trying different combinations.

Believe me, if I could give you a clean repo that reproduced this 100% of the time I would, but even on my own project it isn't 100% reproducible for unknown reasons, with the issue mysteriously vanishing when switching branches or updating packages, only to reappear with the same load out unexpectedly.

I've seen reports of this elsewhere, I will try to locate one of these with their PR's that fixed the issue causing the problem for them

[shilman]

My guess is that this is either a corner case bug in webpack itself or a corner case with Storybook's configuration of webpack. Given that you've seen this problem across both webpack 4/5, across multiple versions of Storybook, AND across multiple projects, it sounds like a highly annoying issue and I'd love to get to the bottom of it.

[tomjn]

@shilman is there a way to make it output more than just the number of modules/dependencies and instead name them outright? If I had an idea of which story it was trying to build that would help towards debugging as well as letting me try to isolate a reproduction case

[tomjn]

I found this issue which has the same situation, the poster found their problem in the end:

https://github.com/storybookjs/storybook/issues/12117

[tomjn]

Noting that a colleague had tried and failed to reproduce the issue in the same repository under Node 16, using the same package lock file & code. I have yet to get past this issue and uncover any clues to reproducing the problem but my tests have all been on Node 14. Hoping this might give clues to reproducing the issue more reliably

[shilman]

@tomjn Sorry for the radio silence -- took some family time to celebrate the new year. I think you can output the webpack stats object using the --webpack-stats-json command-line flag. I'm not sure everything that's in there, but it contains a bunch of webpack internals that could be useful in debugging

[CWSites]

I am also running into an issue where it completely times out and crashes. None of my components will open, the opening introduction page works but I can't navigate to anything else. This started for me in the past couple days where it was working beforehand.

Storybook 6.4.9 with React 17.0.2

[tomjn]

@CWSites no, that's a separate unrelated issue, if you were having this issue you would never have gotten to the point where it could load in the browser, and it would not have crashed.

This issue is for when a build is frozen with no error messages while building dependencies, and has to be manually stopped by user interaction, either via cmd+c in the terminal, or by killing the node process.

You should create a new issue, or find the relevant issue for this problem

[cullylarson]

I'm having a similar issue. start-storybook hangs without an error message or a status update. Adding stats: "verbose" to the webpack config and --loglevel silly to the command doesn't change the output.

UPDATE

I know this issue is more generally around error reporting during build. However, in case someone else stumbles on this specific issue, I resolved it by doing the following:

1. Comment out everything from .storybook/main.js that wasn't needed (all addons, plugins, etc).
2. Remove .storybook/preview.js
3. At this point, I finally got an error message that babel-plugin-react-require couldn't be found.
4. I added babel-plugin-react-require as a dep, restored preview.js and reverted all my main.js changes and the build started working.

[tomjn]

I managed to track this down to some SCSS code that was making webpack freeze. Unfortunately the output from storybook made it look like it was storybook itself that had frozen, and I couldn't extract the command storybook was using to reproduce it independently.

From the storybook end, I believe the solution is better signalling, so it's clear it's not storybook that has the problem, but the webpack build. Perhaps by stating it's going to start and then saying it's finished

[jiri-thiemel-te]

This is just crazy! How can one make storybook dev to display al console logs from the components when it builds?

[tomjn]

This is just crazy! How can one make storybook dev to display al console logs from the components when it builds?

@jiri-thiemel-te I'd avoid the hyperbole as it's a big put off to potential contributors who might volunteer time to fix problems.

Actually in my case there was nothing to hide, webpack itself and sub-components had no output in this situation, so it was not storybook at fault. Granted it looked like storybook was hiding the error messages, but it turned out a webpack plugin was entering an infinite loop.

I'm going to close this as it's misleading, and only attracting people with unrelated issues causing confusion.