bug: Storybook@4.1.x swallows errors from the compiler

In case there are some errors during compilation (in my case that was Manager Compiler), e.g.:

Module not found: Error: Can’t resolve ‘child_process’ in …

or

Module parse failed: Unexpected token (1:0) You may need an appropriate loader to handle this file type.

core/server/dev-server will reject with Stats instance, but core/server/build-dev won’t show any errors, because it expects Error instance. As a result storybook execution will hang forever without any error messages:

info @storybook/react v4.1.11
info
info => Loading static files from: ~/foo/public .
info => Loading presets
info => Loading presets
info => Loading custom addons config.
info => Using base config because react-scripts is not installed.
info => Loading custom webpack config (extending mode).
webpack built 16bec9665459b26d1ce2 in 29388ms

To Reproduce

Steps to reproduce the behavior:

a. Create some file e.g. foo.unknown and try to import it in your code b. Try to import child_process

Expected behavior

a. We should get an error complaining about lacking loader b. We should get an error, that webpack can not resolve the module

Code snippets

Possible solution is to improve error handling here:

https://github.com/storybooks/storybook/blob/v4.1.11/lib/core/src/server/build-dev.js#L285-L290

We can test for Stats object (I don’t know whether is better to test for interface or add instanceof check):

  } catch (error) {
    if (error instanceof Error) {
      logger.error(error);
    } else if (error && error.hasErrors && error.hasErrors()) {
      // Stats with errors
      logger.error(error.toJson().errors.slice(0, 5).join("\n\n"));
    }
    if (options.smokeTest) {
      process.exit(1);
    }
  }

Another possible solution is to rewrite promises in core/src/server/dev-server.js so that they always return Error instances (but in this case I’ve got problems with output formatting. Logger converts error instance into json without line breaks)

System:

• OS: Ubuntu 18.04
• Framework: React
• Version: 4.1.11

[SleepWalker]

@shilman yep, it is fixed in v5.

[shuieryin]

I got the same issue on v5.3.13, seems the bug reappear again?