webpack and its plugins should be peer dependencies of @storybook/builder-webpack5

[mxdvl]

Describe the bug

Currently, many of webpack-related dependencies are marked as direct dependencies of @storybook/builder-webpack5. This causes a problem with consumers of this package that already have their own version of these packages.

To Reproduce

Have a Webpack project with your own webpack-dev-middleware. Use Storybook. Get two distinct versions of webpack-dev-middleware.

System

Storybook Environment Info:

  System:
    OS: macOS 14.3
    CPU: (10) arm64 Apple M1 Max
    Shell: 3.6.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 18.18.2 - ~/Library/Caches/fnm_multishells/65622_1701365893085/bin/node
    npm: 9.8.1 - ~/Library/Caches/fnm_multishells/65622_1701365893085/bin/npm
    pnpm: 8.14.3 - ~/Library/Caches/fnm_multishells/65622_1701365893085/bin/pnpm <----- active
  Browsers:
    Chrome: 123.0.6312.105
    Edge: 123.0.2420.65
    Safari: 17.3
  npmPackages:
    @storybook/addon-essentials: 7.6.17 => 7.6.17 
    @storybook/addons: 7.6.17 => 7.6.17 
    @storybook/api: 7.6.17 => 7.6.17 
    @storybook/components: 7.6.17 => 7.6.17 
    @storybook/core-events: 7.6.17 => 7.6.17 
    @storybook/react: 7.6.17 => 7.6.17 
    @storybook/react-webpack5: 7.6.17 => 7.6.17 
    @storybook/testing-library: 0.2.2 => 0.2.2 
    @storybook/theming: 7.6.17 => 7.6.17 
    storybook: 7.6.17 => 7.6.17

Additional context

webpack-dev-middleware <=6.1.2 has a CVE

[valentinpalkovic]

Hi @mxdvl

Thank you very much for raising this issue.

In a less complex world, I would definitely agree with you. Today, though, the frontend development landscape is pretty fragmented, and this also applies to the number of package managers and their different behaviors.

Declaring all webpack-related dependencies as peer dependencies only works if users have already installed webpack. In more restricted modes, like yarn pnp, they have to be even direct dependencies of the user instead of transitive ones, which meta frameworks like Next.js may bring.

If the user still needs to install them as a direct dependency, the package managers decide whether they are automatically installed. Some do this by default (npm), and some don't (yarn berry).

Your problem currently seems to be that webpack-dev-middleware = 6.1.2 has a CVE. Indeed, Storybook usually doesn't define dependency versions as exact versions but rather as ranges.

The same applies in this case: webpack-dev-middleware's version is defined as ^6.1.1, which means that if you don't have a lock file in place and you freshly install Storybook, the latest allowed version of webpack-dev-middleware is installed, which is currently 6.1.3. If you already have a lock file in place, you can do the following:

• yarn up webpack-dev-middleware -R (for yarn > 1)
• npm update webpack-dev-middleware (for npm, I am not sure whether npm's update command updates transitive dependencies, though)

If all that doesn't help, you can always regenerate your lock files by deleting them and executing a fresh install. Then you should have webpack-dev-middleware installed in version 6.1.3.

I hope this helps.

I will close this issue since we are not planning to declare webpack-related dependencies as peer dependencies. If you still don't agree with me, let me know, and then we can discuss some solutions that cover the above-mentioned problems.

[mxdvl]

Thanks for the detailed response @valentinpalkovic. First off, I want to reassure you that we have addressed the CVE issue and only mentioned it because it was how we discovered that Storybook declares these peer dependencies as direct.

I am very disappointed that you team chooses to take an incorrect approach to dependencies management due to the fragmentation of the JS ecosystem. If the major players do not follow the rules, who will? I am well aware that different package managers work differently, but I would wager that this is a consumer's choice and trying to address their quirks is not the direct concern of Storybook. While I'm sure you've balanced this choice carefully with your user base, I think it's important for your team to be aware that there are consumers who would prefer the correct approach.

Lastly, webpack-dev-middleware's latest major version is 7. This means that any consumer who uses the latest version in their project is given two choices:

1. disregard your declared dependency and use v7 for both (yarn classic, npm's old hoisting strategy)
2. use two different versions 6 & 7 (pnpm) and hope any difference will be minimal

We've chosen option 2 due to our use of pnpm, but it increases the risk of more and more divergence between our development and production environments…

[valentinpalkovic]

Thank you for taking the time to give a lengthy answer!

Let's hypothetically assume that all Storybook webpack-related dependencies are declared as peer-dependencies. I would love to go through some scenarios with you and see how, from a user perspective, the experience with Storybook might be:

Init Storybook into a Next.js project

Next.js doesn't provide webpack or webpack-related packages as dependencies or devDependencies. Instead, they are pre-bundled. If a package manager like yarn berry were used, starting Storybook would instantly fail. That could be a better experience. We could install webpack and related dependencies for the user during initialization to circumvent that issue. But, Next.js users will now have webpack and related dependencies defined in their package.json, although this is not necessary for their project; it is only needed by Storybook. They would have to take care by themselves to keep the dependencies up to date and match the allowed version range defined by Storybook.

On the other hand, though, I definitely see inconsistencies in Storybook itself. For the Vite builder, we define Vite and its related packages as peer dependencies. But we are only talking about vite and vite-plugin-glimmerx, whose version is defined with an asterisk to allow all versions (which is error-prone if you ask me)

Allow multiple major versions of webpack-dev-middleware AND declare it as a peer-dependency

If we define webpack-dev-middleware as a peer-dependency AND we would allow to install it in versions 6 and 7, we would have to make sure that the internal configuration of the webpack-dev-middleware is compatible with both major versions. The webpack-dev-middleware is not configurable by the user and is not exposed to them. It is used internally to bootstrap the webpack server to deliver assets and to configure stats/hmr. I cannot see a strong reason why the webpack-dev-middleware should be a peer-dependency. Having multiple versions of packages installed might be counterproductive in terms of installation speed. Still, Storybook's version of webpack-dev-middleware and your own version are more or less independent and are also used independently by your application and Storybook. There isn't any configuration reuse that would arguably justify the usage of exactly one version of the package.

Since we are not prebundling webpack or its related dependencies and your main concern is not to have duplicate versions of a package, you could always use npm/pnpm/yarn's overrides/resolutions field in your package.json to force the installation of exactly one version of a specific package. But then you also opt-out to potentially break Storybook, because we don't guarantee that webpack-dev-middleware in version 7 actually works.

---

I definitely understand your concerns, but as often, a clear decision is not that straightforward and easy. If we followed your advice, first, this would be a breaking change, and we would have to wait for Storybook 9 to declare all webpack-related dependencies as peer dependencies. Second, the initial user experience with Storybook might suffer. We would have to evaluate that risk carefully. On the other hand, we are already doing what you are suggesting in the vite-builder. So you definitely have a point!

I will reopen that issue to keep it alive so that other people from the community can share their opinions and suggestions as well.

[mxdvl]

Thank you so much for the further insight into how such a small change can have wide-ranging repercussions. You've given a very detailed answer and I can see how my comment may come as short or rude. I apologise for the tone and want to reassure you that apart from this small annoyance my experience with Storybook and its team has been very positive.

I definitely understand your concerns, but as often, a clear decision is not that straightforward and easy.

Balancing priorities is hard and as you mentioned the ecosystem is quite fragmented. It does seem that your are restricted by Next's decision to equally not declare webpack as a peer dependency…

---

I cannot speak for other repositories and would love to know if there are any other developers out there that would want the peer dependencies to be “correct”. If not, this is a clear indication that your current decision was the best 😉