Updating core-js from 2.x to 3.x should bump major dependency

[tomchentw]

I accidentally upgraded react-avatar >= 3.8.0 and found it uses core-js 3 instead of 2. This might cause lots of inconsistency problems, so please follow the semver and bump react-avatar's major dependency. Thanks

[JorgenEvens]

Hi @tomchentw,

Could you add some more details as to which inconsistencies you've encountered. I would prefer understanding the issues your are having before I release a new major release where theoretically it wouldn't be required.

The upgrade to core-js@3 should only ever have had an impact on react-avatar itself, which worked identical after the upgrade. The new major release of core-js@3 mainly removed and re-organized the package structure, which react-avatar remained unaffected by as all core-js includes are injected at build time by babel.

Your code should respect the version of core-js you or other dependencies define in their package.json regardless of the one used by react-avatar.

There have been some issues after the upgrade, but these were due to tools breaking how semver modules were being resolved. [1], [2]

[tomchentw]

@JorgenEvens honestly I could NOT say this is exactly the problem. But I do suspect having issues of two versions of core-js exists in one application. It may not be noticeable during simply upgrading a minor version of react-avatar. Say:

Before

• [email protected] -> croe-js@2
• [email protected] -> core-js@2

Then, yarn could lift the common dep of core-js@2 up to the top-level so that there will be one version of core-js@2 in the application

After

• [email protected] -> croe-js@3
• [email protected] -> core-js@2

The two versions of core-js are now treated as a direct dependency under the package. Hence, two versions may be bundled together in the application.

---

I cannot really confirm this is the issue that happens to my application. You know how the front-end works. It's always changing and the complexity is increasing and sometimes it's harder for us to trace out the exact problem. Yes, the core-js is injected by the @babel/preset-env. But since you explicitly give it a version in your package.json#dependencies, you should take this into concern when bumping it up.

• https://unpkg.com/browse/[email protected]/lib/avatar.js
• https://unpkg.com/browse/[email protected]/lib/avatar.js

Take a look at the top-level imports by @babel/preset-env. Don't you think it a dramatic change?By bumping up the major verion of react-avatar, you could leave the option for the user to whether upgrading react-avatar or not. Thanks

[hijarian]

Right now the inconsistency which actually exist is #187 where gatsbyjs/gatsby breaks with the react-avatar depending on core-js@3.

Granted, it's only happening because they do some obscure voodoo on Webpack configs, as explained in gatsbyjs/gatsby#15601. But it's a valid example of things breaking because of this dependency change. Internal dependencies of projects are not that isolated in npm world, sadly.

[JorgenEvens]

I've been thinking about the arguments that have been raised in this issue and I still feel that the way the update to core-js@3 was released was the correct way. I also recognize that people using gatsby are running into issues that they have no direct control over.

What I'd like to suggest is the following. A tag will be created that points to the last release of react-avatar with core-js@2 on NPM and add a note to the readme of this project that highlights the change.

This means that people looking to use react-avatar with that specific version of core-js will not be receiving any of the new features or updates. Effectively moving that version into maintenance only, should critical bugs arise. There now are two options for users of gatsby, either they go the route discussed in #187 or they use the tagged version of react-avatar.

For those looking to understand my reasoning I'll quickly highlight my thoughts on some of the arguments against doing the update in a major release. If anyone feels differently about these and can provide strong arguments against my reasoning, please do.

Firstly, semver rules were not broken by the release in question during the upgrade of core-js to version 3. Semver dictates that a MINOR version when you add functionality in a backwards compatible manner [*]. The version updates to a package are not dependent on updates within their dependencies as long as the public API of the library is not changed by it, which it was not. [*].

Secondly the issue was raised that your bundle will now contain two versions of core-js which increases bundle size. This statement is completely accurate but would also be the case when a different dependency was introduced as part of a regular feature introduction (which is acceptable within a minor release).

core-js implements their polyfills according to the specifications released for the official browser feature. This means that behavior of the polyfilled functionality should be identical between versions of core-js and indistinguishable from native implementations. Thus not introduce any issues in any consumer of this library.

Lastly, I regret that the gatsby community is now having such a hard time using react-avatar. The unfortunate reality however is that gatsby's behavior breaks module loading and impact more libraries than react-avatar alone. I think that my suggestions of documenting this issue and making it easy to install a specific version of react-avatar (by creating a tag) is the correct way forward. Development of a version of react-avatar using core-js@2 would have halted either way, even if I would have had all the information I have now and released a major version change.

[JorgenEvens]

There is now a reference of the issues surrounding usage in Gatsby and a workaround in the readme of react-avatar.