swc-project/swc · error · TypeError

Generator is already executing.

Error message

Generator is already executing.

What it means

`_ts_generator` is the state-machine helper SWC emits when generators/async-generators are downleveled for old targets. It keeps an `f` (executing) flag; if `step()` is re-entered while a step is still in progress — i.e. the generator is advanced synchronously from inside its own running body — it throws `TypeError("Generator is already executing.")` to protect its internal state.

Source

Thrown at crates/swc_ecma_transforms_base/src/helpers/generated/_ts_generator.rs:15

// This file is generated by `cargo codegen helpers`. DO NOT MODIFY.

use super::{HelperDef, HelperName};

pub const DEF: HelperDef = HelperDef {
    name: HelperName::ts_generator,
    local: "_ts_generator",
    import_path: "@swc/helpers/_/_ts_generator",
    #[cfg(feature = "inline-helpers")]
    source: r#"function _ts_generator(thisArg, body) {
    var f, y, t, _ = { label: 0, sent: function () { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, g = Object.create((typeof Iterator === "function" ? Iterator : Object).prototype), d = Object.defineProperty;
    return d(g, "next", { value: verb(0) }), d(g, "throw", { value: verb(1) }), d(g, "return", { value: verb(2) }), typeof Symbol === "function" && d(g, Symbol.iterator, { value: function () { return this; } }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (g && (g = 0, op[0] && (_ = 0)), _) try {
            if (f = 1, y && (t = op[0] & 2 ? y["return"] : op[0] ? y["throw"] || ((t = y["return"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [op[0] & 2, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }

View on GitHub (pinned to 5176682b65)

Solutions

1. Restructure so the generator is never advanced while it is executing: let the inner code return a request and let the outer driver resume the generator afterwards.
2. Queue re-entrant `next()` calls and drain the queue when the current step completes (see guard below).
3. Raise the compile target to ES2015+ so native generators (which define re-entrancy behavior differently) are emitted instead of the helper.

Example fix

// before (downleveled generator)
function* auto() {
  schedule(() => it.next()); // re-enters while executing
  yield 1;
}
const it = auto();
it.next(); // TypeError: Generator is already executing.

// after
function* auto() {
  yield () => it.next(); // yield the continuation, driver resumes it
  yield 1;
}

// Wrap downleveled generators with a re-entrancy guard that queues instead of throwing.
function guarded(gen) {
  let executing = false;
  const queue = [];
  const pump = () => {
    if (executing || queue.length === 0) return;
    executing = true;
    try { return queue.shift()(); }
    finally { executing = false; setTimeout(pump, 0); }
  };
  const wrap = (method) => (arg) =>
    new Promise((resolve, reject) => {
      queue.push(() => { try { resolve(gen[method](arg)); } catch (e) { reject(e); } });
      pump();
    });
  return { next: wrap('next'), throw: wrap('throw'), return: wrap('return'), [Symbol.iterator]() { return this; } };
}

try {
  it.next();
} catch (err) {
  if (err instanceof TypeError && /already executing/.test(err.message)) {
    // the generator re-entered itself — defer the resume to the next tick
    queueMicrotask(() => it.next());
  } else throw err;
}

When it happens

Trigger: The generator body (or a function it calls synchronously) invokes `.next()`, `.throw()` or `.return()` on the same generator instance — self-driving generators, saga-style runners that resume a generator from a callback the generator itself invoked, or a scheduler that pumps the same instance recursively.

Common situations: Porting redux-saga/iterator-protocol code to a downleveled target where native generators tolerated the pattern; test harnesses that drive generators manually and accidentally re-enter; cooperative schedulers calling `it.next()` inside code the generator ran synchronously.

Related errors

• unknown compound assignment operator
• spread should be removed before applying generator
• assignment property be removed before generator pass
• getter/setter property be compiled as CompiledProp::Accessor
• using declaration must be removed by previous pass

AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17). Data as JSON: /api/errors/1e1133c28d4defad. Report an issue: GitHub.