Create-react-app: react-scripts 3.4 has backwards incompatible changes and fails

Created on 14 May 2020  ยท  6Comments  ยท  Source: facebook/create-react-app

Describe the bug

Upgrading react-scripts from 3.2 to either 3.3 or 3.4 causes the build to fail.
Error:

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "webpack": "4.42.0"

npm ls webpack output:

โ”œโ”€โ”ฌ @storybook/[email protected]
โ”‚ โ”œโ”€โ”ฌ @storybook/[email protected]
โ”‚ โ”‚ โ”œโ”€โ”ฌ [email protected]
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ [email protected]  deduped
โ”‚ โ”‚ โ””โ”€โ”€ [email protected]  deduped
โ”‚ โ””โ”€โ”€ [email protected]
โ””โ”€โ”ฌ [email protected]
  โ””โ”€โ”€ [email protected]

Did you try recovering your dependencies?

yes

Which terms did you search for in User Guide?

webpack
webpack version
"a different version of webpack was detected "
etc

Steps to reproduce

Upgrade react-scripts when having @storybook in v5.2.5

Expected behavior

No failures. Quoting SemVer:

MINOR version when you add functionality in a backwards compatible manner, and

Actual behavior

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "webpack": "4.42.0"

Additional information

  • Using yarn is not an option
  • Using SKIP_PREFLIGHT_CHECK=true seems to be a nasty workaround, and it doesn't help the fact that semver was broken
  • Using eject is not an option for me
bug report needs triage

Most helpful comment

@TeoTN did you try deleting the package-lock.json file (and possibly node_modules, and then running npm install again?

Yes - the conflict is caused, to my understanding, by CRA specifying exact webpack version, so if any dependency has a different, incompatible one (not very unlikely), it'll clash.
I think basically a platform such as CRA should be a bit more elastic, otherwise updating it will force everyone to chase which (version of) dependency has what version of webpack. And in some cases, you'll run into the case when your dependency (e.g. Storybook) was only released with incompatible versions. Which I think, is making CRA violate SemVer by design - every time CRA updates webpack version they depend on, it'll break for some environments.

See related issue on Storybook side: https://github.com/storybookjs/storybook/issues/6505

However, the ball is on the platform side, one should not expect that CRA will be used only if XYZ dependencies use exact same build of webpack, with respect to patch version, this is unreasonable.

All 6 comments

related?

High Denial of Service

Package http-proxy

Patched in No patch available

Dependency of react-scripts [dev]

Path react-scripts > webpack-dev-server > http-proxy-middleware >
http-proxy

More info https://nodesecurity.io/advisories/1486

Hi @TeoTN,

thanks for the report. The change itself is backwards compatible, but @storybook shipping with different version of webpack is causing the warning. As stated in the error message, there are multiple ways to solve the said issue (including SKIP_PREFLIGHT_CHECK) but one easy way is to force the resolution of webpack to use the same module version for Storybook too:

  1. Delete package-lock.json / yarn.lock
  2. Add the following to your package.json:
  "resolutions": {
    "webpack": "4.42.0"
  },
  1. Run yarn / npm install

Ensure that only webpack: 4.42.0 was on installed and the warning should disappear.

If the issue persist, there might be another webpack lower in the root of the project

@petetnt Please kindly reopen the issue as the problem is not solved.

Firstly, my problem is with updating react-scripts, as I have not touched storybook. Clearly specifying fixed version of webpack is a bug in react-scripts, as it assumes the enterprise grade projects won't have other dependencies with webpack included, this is clearly an erroneous assumption.

Please notice, that in my original issue I'm clearly stating that use of yarn is _not possible_ in my case. package resolutions are not supported by npm.

Using SKIP_PREFLIGHT_CHECK would disable a valuable feature, as it does not affect only webpack. It'd be also useful, if the webpack version wasn't fixed, to check if there's a truly incompatible webpack version included.

Finally, disabling preflight check, or even fixing the webpack version and moving the burden of managing properly the version on me, is a regression on update and hence create react app introduces backwards incompatible change with the release.

@TeoTN did you try deleting the package-lock.json file (and possibly node_modules, and then running npm install again?

@TeoTN did you try deleting the package-lock.json file (and possibly node_modules, and then running npm install again?

Yes - the conflict is caused, to my understanding, by CRA specifying exact webpack version, so if any dependency has a different, incompatible one (not very unlikely), it'll clash.
I think basically a platform such as CRA should be a bit more elastic, otherwise updating it will force everyone to chase which (version of) dependency has what version of webpack. And in some cases, you'll run into the case when your dependency (e.g. Storybook) was only released with incompatible versions. Which I think, is making CRA violate SemVer by design - every time CRA updates webpack version they depend on, it'll break for some environments.

See related issue on Storybook side: https://github.com/storybookjs/storybook/issues/6505

However, the ball is on the platform side, one should not expect that CRA will be used only if XYZ dependencies use exact same build of webpack, with respect to patch version, this is unreasonable.

  "resolutions": {
    "webpack": "4.42.0"
  },

using "resolutions" is unfortunately not a viable solution when using npm

Was this page helpful?
0 / 5 - 0 ratings