Compatibility with core-js 3

[mpeyper]

What's up?

Currently I'm unable to set babel's preset-env to use the corejs: 3 option, which involves installing core-js@^3, without react-cosmos failing on an error about @babel/runtime-corejs2:

[Cosmos] Export Failed! See errors below:

ModuleNotFoundError: Module not found: Error: Can't resolve 'core-js/library/fn/object/values' in '<my-package path>/node_modules/@babel/runtime-corejs2/core-js/object'
<stack trace>

Mkay, tell me more...

I'm using a custom webpack config, with a custom babel config setting the value with a custom babel preset... so I'm definately not discounting that this could be an issue with my setup and not an issue with cosmos. I'll try to get some time in the next day to setup a simplified example to replicate, but I wanted to get the issue up in case someone just knows how to fix this.

I'd love to contirbute towards fixing this, but I'm really struggling to work out how @babel/runtime-corejs2 even becomes a dependency of react-cosmos's published package.

[ovidiuch]

Hi @mpeyper,

The only place where Cosmos knows about Babel is when constructing the default webpack config. It adds a loader rule for babel-loader if you already have it installed.

But you're saying you use a custom webpack config, so it must be something else.

I don't have experience with core-js 3, but please provide a reproducing case when you have the time and I'm sure we'll get to the bottom of this.

Cheers!

[mpeyper]

Hi @skidding,

If you npm i react-cosmos and check the package.json of the installed package, you'll see @babel/runtime-corejs2 as a listed dependency. If you can tell me how that gets there during your build process, I'm happy to try to fix this myself.

I still haven't had time to set up a repro case, but I might later today.

[ovidiuch]

Did you try react-cosmos@next?

[mpeyper]

Not yet (wasn't aware of it). I'll give it a shot ant report back.

[mpeyper]

Hi @skidding,

I've checked react-cosmos@next and it no longer has @babel/runtime-corejs2 as a dependency, so it's unlikely to be affected by this issue. Unfortunately the changes in the next version seem substantial and breaking, so I've got quite a few custom proxies and bits and pieces of fairly specialised code around the old codebase (react-cosmos is part of a larger common toolchain we use for an extensive micro-frontends architecture, so my use-case is pretty niche).

I think you can close this issue as there is not much for you to do here, and I'm not sure the appetite for wanting to update the classic package for things like this.

Out of interest, how close to stable the the next version? Also, do you think a cosmos.config.jsmight ever make a comeback? When making a common toolchain package, it's often common to a refer to a path using require.resolve or call some code to derive a value for the config.

[ovidiuch]

Cosmos Next is very stable. It's been under development for over a year and a lot of people use it. The only things left before it becomes latest are some onboarding tweaks, a small presentation website and helping as many people like you upgrade.

I wanted to make migration tools but I haven't been able to get enough feedback from Cosmos Classic users to justify the cost.

Would you be willing to spend some time to explain/show me your config/proxies/setup? It would be very useful for me and hopefully I can help you make the switch without spending too much time on your part. If you're interested please send me a message on Slack, Twitter, email (see my profile), wherever you're more comfortable.

[ovidiuch]

@mpeyper Transferred this issue to the Classic repo.