React: React depends on an older version of core-js, breaking the usage with the new babel

[marcofugaro]

Do you want to request a feature or report a bug?
Bug.

What is the current behavior?
React is relying on an older version of core-js which goes in conflict with the newer beta version of babel.

The older version gets installed instead of the newer, so it results in errors like

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
React v16.4.0

[gaearon]

React doesn't really "depend" on core-js in practice for anything. It's true that it's in a dependency tree (which is kinda unfortunate) but we don't end up using any of its modules.

So React can't possibly break your app with this. If you're seeing some kind of conflict it probably means your package manager has a bug, and incorrectly hoists a package version.

[marcofugaro]

So it's a yarn issue? I don't really know how hoisting works, but I will provide a basic reproducible repo and submit the issue there

[gaearon]

I can't tell for sure—your screenshot doesn't show who's attempting to import that module

[marcofugaro]

That's the package.json, the root of the project.

I tested it in isolation both with yarn and npm, and the behaviour is different. Npm installs correctly the updated dependency, whereas yarn gives precedence to the 1.x one.

Will make a repo and submit the issue at yarn, hopefully they will look into it.

[gaearon]

I don't understand what you're saying.

I'm asking which package is attempting to load core-js (and is failing).

[marcofugaro]

Sorry, it's @babel/polyfill with the flag useBuiltins: 'usage' after using some async iterators.

Async iterators are present only in core-js v2.x.x.

[gaearon]

So you're saying @babel/polyfill depends on core-js in its package.json but didn't get node_modules/core-js with the version it expects?

[marcofugaro]

Yup, only using yarn.

After doing yarn init -y; yarn add babel-preset-accurapp react, I checked the core-js version in the node_modules manually (the package.json) and it's the 1.2.7.

EDIT: maybe I'm doing something wrong, let me create the repo

[gaearon]

The version in the top level folder is not necessarily what matters. What matters is that following Node resolution algorithm (./node_modules, then ../node_modules, then ../../node_modules, then ../../../node_modules, and so on) from where the package is imported gives you the right version.

Tools like npm or yarn can choose to put a package to node_modules folder above but as long as it doesn't break other expectations, this shouldn't matter.

Looking at your reproducing example, the version I get from @babel/polyfill/node_modules/core-js is 2.x. So the package manager didn't do anything wrong. As long as the require itself is inside @babel/polyfill, everything should work. And if it's not, why does a require exist without an explicit dependency?

[marcofugaro]

Thanks for your time investigating this @gaearon!

Yup, you're right, not an issue with yarn.

It turns out, the require is outside of @babel/polyfill. Basically what babel does, as described in the docs, it transforms this

var b = new Map();

into this

import "core-js/modules/es6.map";
var b = new Map();

so the core-js import is actually done from your application!

Babel then tells you to add @babel/polyfill to your dependencies, so that core-js gets installed also, but when you have other dependencies using core-js, the import from the application gets resolved to a different version of core-js, which is what I think it's happening here.

[gaearon]

That makes sense 👍

[marcofugaro]

For now I solved It by adding core-js also as a dependency of babel-preset-accurapp.

[gaearon]

You probably want it as a peer dependency instead.

[gaearon]

Or, rather, you want @babel/polyfill as a peer dependency. Thus forcing the user of the preset to install the correct version.

[sergej-s]

@marcofugaro How did your print the dependency tree so nicely? :)

[TrySound]

npm ls/yarn list