Create-react-app: "Cannot resolve module babel-runtime/regenerator"

Created on 28 Jul 2016 · 18Comments · Source: facebook/create-react-app

I get this message when I use generators because babel-runtime is not a runtime dependency of the generated project. I didn’t notice this when I merged #238 because I tested only the local flow (npm run create-react-app).

I see three possible solutions:

Document this as a known gotcha in the howto. (People using generators would probably find it quick enough.)
Put babel-runtime into everyone’s dependencies on project creation regardless of whether they actually use generators. (Not very good, we have no control over the version, and this exposes Babel to users which we’d rather avoid.)
Add an option to babel-plugin-transform-runtime that would let us set runtimeModuleName to a resolved path. (I would prefer this.)

bug underlying tools

Source

gaearon

All 18 comments

I just ran into something similar when using react-input-enhancements, adding babel-runtime fixed the issue. Just importing anything from the lib would cause a compile failure.

blitzd on 28 Jul 2016

You could try using resolve.fallback config to make babel-runtime resolvable.

insin on 28 Jul 2016

You could try using resolve.fallback config to make babel-runtime resolvable.

This works as an interim solution but I don’t like that it makes us more tied to Webpack resolution mechanism. I would we solve this in a more generic way.

gaearon on 28 Jul 2016

You can solve this by bundling up _all_ the polyfill-style dependencies (including the current promise and whatwg-fetch) into a single runtime dependency, then hiding Babel under there.

You have the same "exposes users" and "version control" issues with the current polyfill dependencies anyway.

taion on 28 Jul 2016

Not sure I fully understand what you propose, can you elaborate?
I currently only want babel-runtime for regenerator, I don’t need it for any other use cases.

gaearon on 28 Jul 2016

@gaearon Never mind – I just realized this is really another thing like https://github.com/facebookincubator/create-react-app/issues/247 where the problem is that babel-runtime doesn't end up at top-level in node_modules.

taion on 28 Jul 2016

I’ll plug the hole for now with #262 but this is suboptimal (e.g. probably won’t work with Jest).
Will revisit as soon as we find a case that doesn’t work well with that hack.
I hope that babel/babel#3612 lets us do this, but if not, we’ll probably have to add babel-runtime for everyone at some point.

gaearon on 28 Jul 2016

Can this also be resolved by not shipping babel-runtime as a bundled dependency? Possibly ESLint as well. Then they'd just end up at top-level in node_modules.

taion on 29 Jul 2016

I'm not saying "drop bundledDependencies", just "un-bundle stuff that's expected to be at top-level in node_modules".

taion on 29 Jul 2016

So _that’s_ why they end up there even with npm 3, you’re right.
I didn’t realize that.

gaearon on 29 Jul 2016

A PR to unbundle ESLint plugins and babel-runtime is welcome. We’d probably want to keep the rest bundled though.

gaearon on 29 Jul 2016

Ah, this won't work – at least, it won't work in a straightforward way. It looks like babel-runtime still ends up as a nested dependency, because the other bundled Babel dependencies pull in babel-runtime... I think.

Well, anyway it worked for the ESLint plugins, but not babel-runtime, so that's my best guess.

And npm ddp after an install takes forever, so that's out too.

taion on 29 Jul 2016

Though – anybody else looking at this, don't take that as gospel. Very likely I just messed up.

taion on 29 Jul 2016

For anyone googling this error when trying to run Jest tests on generators (as @gaearon pointed out it the fix in #262 does not seem to work in Jest), looking for the workaround:

I fixed this by putting babel-runtime in my app dependencies. This fixed the issue.
Is this a recommended way to work around this for now?