regenerator-runtime is a small helper library that provides the runtime support Babel needs to make generators and async/await work when code is transpiled down to older JavaScript, and for most modern projects it is a transitive dependency you did not choose and may no longer need. If you found regenerator-runtime in your node_modules and wondered where it came from, the answer is almost always "a build tool pulled it in." The regenerator runtime is not something teams usually install directly, which is exactly why it is worth understanding rather than ignoring.
This post explains what the package does, why it appears, and how to reason about it from a dependency-health perspective without either panicking or waving it through.
What regenerator-runtime actually does
When Babel transpiles modern JavaScript to an older target, it cannot express generator functions or async/await directly in, say, ES5, because those language features did not exist there. Babel rewrites them into a state machine, and that rewritten code needs a small runtime helper to drive it at execution time. That helper is regenerator-runtime.
So the package is not a feature library you call. It is plumbing that transpiled output depends on. If you have ever imported regenerator-runtime/runtime at the top of an entry file to make async code work in an old browser, you have seen the one case where developers touch it directly. Otherwise it rides in silently under @babel/runtime or a preset.
Why npm regenerator-runtime is in your tree
The npm regenerator-runtime package lands in a project through one of a few doors, all of them upstream of your own dependencies. A Babel preset configured to target old environments pulls it in. @babel/runtime historically depended on it. And any library you install that was itself built this way ships a dependency on it.
# Trace who actually pulled it in
npm ls regenerator-runtime
Run that and you will usually see it nested under a build tool or a published package, not at your top level. That transitive position is the whole reason it is easy to overlook: you never made a decision about it, so it never came up for review.
Do you even need it anymore?
This is the more interesting question than "is it dangerous." For a growing number of projects, the answer is no. If your build targets modern browsers and current Node.js, those runtimes support generators and async/await natively, so Babel does not need to down-level them, and the regenerator runtime becomes dead weight.
Check your Browserslist or Babel target configuration. If you are still transpiling to ancient targets out of habit rather than a real support requirement, tightening the target can drop regenerator-runtime and other legacy helpers from your bundle entirely. Smaller bundle, fewer dependencies, less to audit. That is the cleanest "fix" here: not patching the package, but removing the need for it.
The broader lesson applies past this one library. Legacy transpilation targets quietly accumulate runtime helpers, and revisiting your target list is a periodic hygiene task worth doing.
Thinking about its risk honestly
regenerator-runtime is a widely used, single-purpose package, and it does not have a notable history of security incidents. Inventing a scary CVE for it would be dishonest. The realistic way to think about its risk is the same way you should think about any transitive dependency you did not choose.
The risk is not the code as it exists today. It is the supply-chain surface: any package in your tree is a package whose next version could be compromised through a maintainer account takeover, and one you did not choose is one nobody on your team is watching. The defense is not specific to this library. Pin your dependencies with a committed lockfile, review lockfile diffs in pull requests so an unexpected version change gets noticed, and run npm audit in CI so a future advisory surfaces automatically. An SCA tool such as Safeguard helps precisely with the transitive case, mapping which of your direct dependencies dragged in a given package so you know who to nudge upstream if an issue appears.
Keeping transitive dependencies manageable
The practical takeaway extends well past regenerator-runtime. Every transitive package is code running with your application's privileges that you never explicitly vetted, so the goal is to keep that set small and observed rather than to fear any single member of it. Periodically list your full dependency tree and ask which entries you actually need. Tighten build targets that pull in legacy runtime helpers you no longer support. And treat a lockfile diff in code review as signal, not noise, because that is where a surprise dependency, or a surprise version of one, first shows up. Our security academy covers this dependency-hygiene workflow in more depth.
FAQ
What is regenerator-runtime used for?
It provides the runtime support that Babel-transpiled code needs to run generators and async/await on older JavaScript targets. Babel rewrites those language features into a state machine, and regenerator-runtime drives that state machine at execution time.
Why is regenerator-runtime in my node_modules if I never installed it?
It is almost always a transitive dependency, pulled in by a Babel preset, by @babel/runtime, or by a published library that was built to support old targets. Run npm ls regenerator-runtime to see which parent brought it in.
Can I remove regenerator-runtime?
Often yes. If your build targets modern browsers and current Node.js, those runtimes support generators and async/await natively, so Babel no longer needs to down-level them. Tightening your Browserslist or Babel target can drop the package from your bundle.
Is regenerator-runtime a security risk?
It is a single-purpose, widely used package without a notable incident history, so the risk is not the current code but the general supply-chain surface any transitive dependency carries. Pin it in a lockfile, review lockfile diffs, and run npm audit so any future advisory is caught.