Storybook: Is there a way to prevent load of react-scripts for webpack.config.js?

[binomialstew]

Is your feature request related to a problem? Please describe.
I have a custom config for storybook using the full-control mode. I now have a sibling package in a lerna monorepo that uses react-scripts, but this is not used or wanted in my storybook package, and I'd like to avoid loading this config for storybook at all, as the rules conflict and I need much more control over the storybook config than what react-scripts offers for this use-case. React-scripts is being hoisted by lerna into the root node_modules directory, which results in this config being loaded for use when running the storybook and build-storybook scripts. From what I understand, this is because it is found in the root node_modules.

Describe the solution you'd like
I would either like a way to disable the load of react-scripts config completely—perhaps a cli flag or a way to get and extend only the base minimum config used for storybook in webpack.config.js (before all the config is added by react-scripts).

Describe alternatives you've considered
I considered preventing react-scripts from being hoisted to the root node_modules, but this isn't a good option because it has the potential to be used by many other leaf packages that could be added to this monorepo and therefore would be best held in the root n_m.

Are you able to assist bring the feature to reality?
I'm writing this in hopes there is already a supported way to achieve my goal without having to take the storybookBaseConfig in webpack.config.js and do a lot of tedious filtering of the rules that are being added from react-scripts. It would be a much cleaner solution to simply prevent the load of react-scripts from the start. If there is no way currently for this to be done, maybe we can talk about some options and the best way forward for a potential new feature.

[binomialstew]

I am able to work around this by running my storybook scripts in the storybook package subdirectory. This results in storybook not finding react-scripts because it is not in the local node_modules folder. I still think it would be helpful to have an optional load of react-scripts—I'm sure there are needs for this other than mine.

[shilman]

I've run across this too. Perhaps we can do a check in package.json instead of or in addition to the existing check. What do you think @mrmckeb ?

[ndelangen]

I think checking in package.json before searching in node_modules is a great solution!

@binomialstew would you be able to open a PR for this?

Here's the code that would need to change:
https://github.com/storybookjs/storybook/blob/5eb6af0e1b20a84b9fb28fd70b049f51993b1169/app/react/src/server/cra-config.js#L62-L70

I'm unsure how to tests this, maybe @Hypnosphi would have a suggestion on that?

[Hypnosphi]

@ndelangen add an example with lerna to cli/tests/fixtures?

[binomialstew]

Thanks, @ndelangen, for the hint. I've submit a PR for this.

@Hypnosphi, that sounds like a good idea, but I'd have to get a little more familiar with the project to set this up. I can probably do this in the next couple days, if it's still needed.

[binomialstew]

@shilman and @ndelangen --@mrmckeb has raised concerns around checking in package.json for react-scripts.

So, it's clear that checking in package.json is not viable. How about checking for process.env.REACT_SCRIPTS? Since some users already depend on react-scripts being used implicitly, we can make this backwards compatible by only preventing load of react-scripts when false.

Does this sounds like something that will work for all?

[mrmckeb]

Hi @binomialstew, thanks for moving the discussion back to here. I want to be clear that this was a design choice before I joined the project, but not one that I'm necessarily opposed to - there are pros and cons of this "detection" approach.

We can't detect react-scripts in the user's package.json, as they may have a different scripts version. So changing this would be a breaking change.

However, I have another thought... @shilman mentioned before that we could move the CRA preset out of the core React package. We could still install that by default alongside React, but that would then allow the user to remove it easily.

An alternative is a flag - but I'd still like this behaviour to be on by default. I feel that the DX is good right now for CRA users, and adding additional steps may make it worse.

[shilman]

@mrmckeb for a little color here, we've already started adding presets for scss and typescript, and it seems to be working well.

• https://www.npmjs.com/package/@storybook/preset-scss
• https://www.npmjs.com/package/@storybook/preset-typescript

I can imagine doing the same for CRA compat. We'd automatically add it to the user's presets.js file if CRA is detected by the CLI, and if it didn't get detected users could add it manually (and could potentially configure it also--something that's not possible right now).

This is a breaking change, so we wouldn't be able to introduce it until 6.0. But I think we should consider it!

[stale[bot]]

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!

[stale[bot]]

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!

[shilman]

I believe this is solved as part of #7221