How to extend storybook js rule for webpack.config.js in v5?

[adamchenwei]

Is your feature request related to a problem? Please describe.
I am having problem with importing commonJS file, so I wanted to try tweak webpack.config.js to customize exclude property so the commonJS component is not processed by the loader, hoping that can eliminate the import problem.

Describe the solution you'd like
A valid approach to extend existing webpack config for storybook. Since the old mode was deprecated and the new doc did not mention way to extend existing js rule
Describe alternatives you've considered
Override the whole config, but it likely causes more problem...
Are you able to assist bring the feature to reality?
maybe, with lots guidance to dig through code base
Additional context
using storybook v5. loading a common JS component, and mentioned some more detail on what exactly was the error here

[shilman]

@adamchenwei You can use full-control mode and simply modify the incoming config without rewriting it entirely. There are lots of examples in the docs, examples, and github issues.

[adamchenwei]

@shilman would you have an example in full control mode update js loader config?
I can't find anywhere online

In this case i want the storybook to load commonjs component correctly by first try to use exclude property so sb ignore it when try to convert the commonjs file with the default js loader config.

Let me know if it makes sense or need example?

[shilman]

@adamchenwei here's one of many relevant examples: #6758

You'll need to adapt it to your needs, but hopefully it points you in the right direction.

[ndelangen]

Here's the official documentation:
https://storybook.js.org/docs/configurations/custom-webpack-config/#full-control-mode

[zackphilipps]

Am I the only one super frustrated with Storybook docs? I have to use the old configuration method for integration with InVision's DSM (not that the specific reason matters much), and any time I have a need to customize anything it's nearly impossible to find what I need to do. Just one frustrating example is the link above going to nothing in particular (looks like the Full Control Mode docs were moved or removed.) There's even a link on that page that is supposed to list "Webpack customization modes" but looks like that's gone, too. Running into the same thing with Webpack itself where they only show docs for the latest version as if everyone can use it immediately. Is it too much to ask for software devs, in general, to at least keep an easily-accessible history of docs for each major version of their software? Are we really expecting people to navigate a maze of obscure closed issues and threads?

Edit: I see now where Webpack has v4 docs, so that's good.

[ndelangen]

Hey zack:

Is it too much to ask for software devs, in general, to at least keep an easily-accessible history of docs for each major version of their software?

Of course we want this, and efforts are made to make this a reality.