Master Babel 7: Resolve Common Runtime Errors and Optimize Polyfills
This article explains why Babel 6 and Babel 7 produce typical errors such as "regeneratorRuntime is not defined" and "Cannot find module 'core-js/library/fn/**'", then walks through the roles of @babel/preset‑env, @babel/plugin‑transform‑runtime, core‑js versions, useBuiltIns options, and provides concrete configuration examples for both application and library projects.
As a tool developer, Babel‑related problems are hard to avoid. In Babel 6 the most frequent complaint is regeneratorRuntime is not defined; in Babel 7 it becomes Cannot find module 'core-js/library/fn/**'. These errors stem from missing runtime dependencies that Babel injects based on the configured presets or plugins.
Prerequisite Knowledge
Before configuring Babel you need to understand what each package does:
@babel/preset-env @babel/plugin-transform-runtime @babel/runtime core-js @babel/polyfills babel-polyfills@babel/preset-env is a smart preset that lets you use the latest JavaScript without manually selecting syntax transforms or browser polyfills, reducing bundle size.
A smart preset that allows you to use the latest JavaScript without needing to micromanage which syntax transforms (and optionally, browser polyfills) are needed by your target environment(s). This both makes your life easier and JavaScript bundles smaller!
It mainly transforms new syntax ( const, let, etc.) and can also polyfill new APIs such as Array.prototype.includes or Promise.
Tips for Babel 6 vs Babel 7
In Babel 6 you used stage presets, which only transformed syntax; polyfills were added via babel-plugin-transform-runtime or babel-polyfill.
In Babel 7 the stage presets were removed. @babel/preset-env now provides both syntax transformation and optional polyfill capability.
Key Configuration Questions
How does preset-env reduce bundle size?
Why is @babel/plugin-transform-runtime still needed when preset-env can polyfill?
Do I still need @babel/polyfill?
Important Options of @babel/preset-env
targets : defines the environments (e.g., specific browsers) your code must support. Babel uses this to inject only the necessary polyfills.
useBuiltIns : controls how polyfills are handled. Options are false (no automatic polyfills), entry (import all required polyfills at the entry file), and usage (inject polyfills based on actual code usage).
corejs : specifies the core‑js version (2 or 3) and whether to include proposal APIs.
Example for useBuiltIns: "entry":
import 'core-js/stable';
import 'regenerator-runtime/runtime';
// your codeUsing useBuiltIns: false is discouraged because it bundles every polyfill, inflating the package size.
When to Use @babel/plugin-transform-runtime
This plugin re‑uses Babel’s helper code to reduce bundle size and can provide polyfills without polluting the global scope. It performs three actions:
1. Automatically requires @babel/runtime/regenerator for generators/async functions. 2. Uses core‑js for helpers when needed. 3. Replaces inline helpers with imports from @babel/runtime/helpers .
For library authors, enable corejs in the plugin and disable useBuiltIns in preset‑env so that polyfills are injected by the runtime plugin without affecting the global environment.
Sample Configurations
Application project (prefer preset‑env polyfills):
{
"presets": [["@babel/preset-env", {
"targets": {"chrome": "58"},
"useBuiltIns": "entry",
"corejs": {"version": 3, "proposals": true}
}]],
"plugins": []
}And in the entry file:
import 'core-js/stable';
import 'regenerator-runtime/runtime';Library project (avoid global polyfills):
{
"presets": ["@babel/preset-env"],
"plugins": [["@babel/plugin-transform-runtime", {
"corejs": {"version": 3, "proposals": true}
}]]
}Here preset‑env does not handle polyfills; the runtime plugin does, keeping the library clean.
Unresolved Issues and Experimental Solutions
Using a non‑global polyfill with preset‑env is not possible because the targets option cannot be combined with "pure" ponyfills. Babel introduced babel‑polyfills to address this, but it is still experimental and not recommended for production.
Conclusion
Understanding the interaction between @babel/preset-env, @babel/plugin-transform-runtime, and core‑js is essential for both application and library developers. Choose useBuiltIns: "entry" with preset‑env for apps, and enable corejs in the runtime plugin for libraries to avoid global pollution, while being aware of the trade‑off that targets will no longer reduce bundle size.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
