Is your feature request related to a problem? Please describe.
I just spent a few minutes trying to debug my storybook integration until I noticed that I had (through careless copy&paste) registered the @storybook/addon-viewport in my addons.js file – but I had not npm-installed it.
I know this was stupid by me for not setting things up in a thorough way 🤦♂️
Still, running npm run storybook produced a webpack built without throwing any errors or giving hints:
info @storybook/vue v4.1.11
info
info => Loading presets
info => Loading presets
info => Loading custom .babelrc
info => Loading custom .babelrc
info => Loading custom addons config.
info => Loading custom webpack config (full-control mode).
webpack built 6ee5b84edc8caae1b3bb in 3449ms
Of course, opening Storybook on the assigned localhost resulted in a Cannot get / message.
Describe the solution you'd like
I would have liked the setup to at least give me a warning that the addon I registered wasn't available instead of just swallowing that error (which must have happened somewhere!?).
Describe alternatives you've considered
I can't really think of an alternative. I do think swallowing any errors is not a good thing to do, though 😄
Are you able to assist bring the feature to reality?
Maybe, I don't know? I'm not familiar with the code base & webpack. Would still give it a shot.
Additional context
As you might see, I have a custom webpack and babelrc (nothing special, "just" alias resolving & some sass files being loaded), but I don't think that relates (or should relate) to the issue described here.
That's a good idea @HerrBertling, would you like to raise PR? I can help you if needed.
I'm not sure of the correct way to fix this but after some digging around I managed to find a way to output the suppressed webpack errors for addons.
File - ./node_modules/@storybook/core/server/dev-server.js line 125 - This promise.all is swallowing all errors from the two queued promises, the way I got it to bubble out was to change it to:
Promise.all([
managerPromise.catch(e => e),
previewPromise.catch(e => e)
]).then(([managerStats, previewStats]) => {
This should allow storybook to serve correctly and the webpack error can be seen in the browser console
OK, cool. If you would like to raise a PR, I think we can get this looked into. Thanks @martinshing!
I won't be able to do the PR soon-ish due to my best release yet a few days ago: 👶 😊
CONGRATULATIONS ;) And don't worry, we'll see if someone else can pick this up.
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!
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!
Most helpful comment
I'm not sure of the correct way to fix this but after some digging around I managed to find a way to output the suppressed webpack errors for addons.
File - ./node_modules/@storybook/core/server/dev-server.js line 125 - This promise.all is swallowing all errors from the two queued promises, the way I got it to bubble out was to change it to:
This should allow storybook to serve correctly and the webpack error can be seen in the browser console