"Cannot resolve module babel-runtime/regenerator"

[gaearon]

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.)

[k-dahl]

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.

[insin]

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

[gaearon]

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.

[taion]

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.

[gaearon]

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.

[taion]

@gaearon Never mind – I just realized this is really another thing like #247 where the problem is that babel-runtime doesn't end up at top-level in node_modules.

[gaearon]

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.

[taion]

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.