Some published packages, e.g., @wordpress/api-fetch, use async/await internally and the published transpiled sources (in build or build-module) therefore depend on the regeneratorRuntime global.

When imported into an app that's transpiled to a target that supports async/await natively, there is suddenly no one who would provide the regeneratorRuntime global and the app starts crashing. Even if the app contains import '@babel/polyfill', the preset-env plugin won't include the regenerator runtime, because it's not needed by the transpilation target.

This started happening in Calypso recently:

• tests always run on the latest Node.js and therefore don't need to be transpiled much. Jest needs to be explicitly configured to include the regenerator runtime which wouldn't otherwise be there.
• we're experimenting with a custom build for modern evergreen browsers that ships ESnext code to the client. The Gutenberg integration crashes there because of missing regenerator runtime.
• the Desktop app is compiled with Electron target. I didn't check it yet, but the Gutenberg integration is also likely to crash there the same way.

Possible solution:
The root cause of the issue is that the published package depends on something that it doesn't declare as NPM dependency. The dependency is silent and implicit.

Using regenerator: true flag in the transform-runtime plugin would convert the global reference into an import statement:

const regeneratorRuntime = require( '@babel/runtime/regenerator' );
regeneratorRuntime.useIt();

Then the NPM package would have to declare a @babel/runtime dependency in package.json. That makes the existing dependency explicit rather than adding a new one.

Using a transpiled code in an environment that doesn't need it is still suboptimal, but at least not broken. Shipping untranspiled code in NPM packages is AFAIK still an active research area in the JS community rather that something we can use today 🙂