Incorrect @babel/runtime version

[AdrienLemaire]

• This is a v1.x issue.
• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Building files with webpack shouldn't raise @babel/runtime errors

Current Behavior

Described in this react-event-listener issue.

Steps to Reproduce

Link:

1. Install material-ui v1.5.1
2. Insert a Button
3. Build your dist output with webpack

Context

Looking at @material-ui/core packages.json, I see 2 conflicting dependencies:

• @babel/runtime 7.0.0-rc.1
• react-event-listener 0.6.2 using @babel/runtime 7.0.0-beta.42

These 2 versions of babel runtime are incompatible.

Your Environment

Tech	Version
Material-UI	v1.5.1
React	v16.4.2

[AdrienLemaire]

I tried debugging this issue, but still unable to resolve it.

Let's take the error:

ERROR in ./node_modules/@material-ui/core/styles/withStyles.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/getPrototypeOf' in 'project/node_modules/@material-ui/core/styles'    
 @ ./node_modules/@material-ui/core/styles/withStyles.js 20:46-94
 @ ./node_modules/@material-ui/core/Button/Button.js
 @ ./node_modules/@material-ui/core/Button/index.js
 @ ./src/components/pages/AccountDelete/index.js
 @ ./src/components/Routes.js
 @ ./src/components/Root.js
 @ ./src/app.js
 @ multi babel-regenerator-runtime ./src/app.js

I have 4 @babel/runtime versions in my node_modules. When trying to list the getPrototypeOf.js file in these dirs, I get

$ for dir in $(find node_modules -name 'runtime'); do cat $dir/package.json|grep version; ls $dir/helpers/getPrototypeOf.js; done
  "version": "7.0.0-beta.56",
node_modules/recompose/node_modules/@babel/runtime/helpers/getPrototypeOf.js
  "version": "7.0.0-rc.1",
node_modules/@material-ui/icons/node_modules/@babel/runtime/helpers/getPrototypeOf.js
  "version": "7.0.0-rc.1",
node_modules/@material-ui/core/node_modules/@babel/runtime/helpers/getPrototypeOf.js
  "version": "7.0.0-beta.42",
ls: cannot access 'node_modules/@babel/runtime/helpers/getPrototypeOf.js': No such file or directory

So it appears imports from material-ui will search in the node_modules/@babel directory instead of the node_modules/@material-ui/core/node_modules/@babel one ... weird

TBH, I don't know what to do next.

[oliviertassinari]

@Fandekasp It should be fine, both versions can live under the same bundle. Try reinstalling your dependencies. oliviertassinari/react-event-listener#90 is about flat installations.

Your issue has been closed because it does not conform to our issue requirements.
Please provide a full reproduction test case. This would help a lot 👷 .
A live example would be perfect. This codesandbox.io template may be a good starting point. Thank you!

[Slessi]

I also have similar problems when updating to 1.5.1 from 1.5.0.

./node_modules/@material-ui/icons/NoteAdd.js
Module not found: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/<project_dir>/node_modules/@material-ui/icons'

[guilherme-sol7]

I had this issue with this packages

"@material-ui/core": "^1.3.1", "@material-ui/icons": "^1.1.0",

Update @material-ui/icons to the lastet, current ^2.0.3 resolve my problem

[FinnWinchester]

Same here - issue with react-event-listener and @babel/runtime.

Error is:

ERROR in ./node_modules/react-event-listener/dist/react-event-listener.cjs.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/classCallCheck'

[Slessi]

@guilherme-sol7 is right, to use @material-ui/core 1.5.1 you must also use @material-ui/icons >= 2.0.0.

[remiroyc]

Same problem with "@material-ui/core": "^1.5.1" and without "@material-ui/icons".

It works on local, but fails on my integration server (codeship).

SOLUTION: It works fine with strict "@material-ui/core": "1.5.0". And FYI, I use yarn install

[Slessi]

@remiroyc check the error carefully, maybe you have something else which depends on an older version of @babel/runtime ? i.e. lower than 7.0.0-rc.1

[maciej-gurban]

Wouldn't locking dependency versions or providing a package-lock.json help avoid the issue altogether? I understand that it's a standard practice among the many developers to provide version ranges instead of precise versions due to the overhead of updating these versions later on, but this ends up making it possible to install the same version of material-ui with correct or broken dependency tree depending on time of the day, or specific date.

Would you consider adding doing either?

[eps1lon]

Lockfiles are not published. The smaller the version range the more likely you end up with a very big bundle which is a problem if your bundle has to be shipped to users. That's why every package in the dependency tree should agree to semantic versioning or everybody has to use exact versions because nobody guarantees non-breaking changes between version bumps.

I do however agree that using a release candidates or beta version in releases marked as stable is concerning. Maybe more care should be taken when bumping those to get the full benefit.