How to Fix: Turbopack assigning class variables as undefined explicitly on construction.

Turbopack can break class field semantics by writing properties as explicitly undefined during construction, which changes runtime behavior compared to expected JavaScript output and can make getters, inherited values, or framework-dependent initialization fail in subtle ways.

This issue appears in a reproducible Next.js app when using Turbopack, where class variables that should remain untouched are instead assigned during object construction. If your code relies on prototype behavior, inherited defaults, decorators, field initialization order, or checks like "prop" in obj versus obj.prop === undefined, that transformation can produce incorrect results.

You can review the reproduction from the issue via the linked repository.

Understanding the Root Cause

At the language level, class fields are not the same thing as simply having a property that evaluates to undefined. There is a major semantic difference between:

• a property that does not exist on the instance yet, and
• a property that is explicitly created with the value undefined.

That difference matters because JavaScript object behavior depends on property presence. For example:

class ExampleA {}

class ExampleB {
  value;
}

When a bundler or compiler lowers class syntax, it must preserve the runtime meaning of the original code. The bug reported here suggests that Turbopack is emitting constructor assignments that eagerly define fields as undefined in cases where that output changes the expected result.

Why is this harmful?

• Prototype lookup changes: if a field is explicitly assigned on the instance, JavaScript stops reading from the prototype chain for that property.
• Presence checks change: Object.hasOwn(obj, "x") and "x" in obj now return different values.
• Initialization order matters: framework code or decorators may inspect the instance before your intended value is set.
• Inheritance can break: subclass construction may overwrite values that should have come from a base class or getter.

A simplified example of the semantic difference:

class Base {
  get theme() {
    return "dark";
  }
}

class Works extends Base {}

class Breaks extends Base {
  theme;
}

const a = new Works();
const b = new Breaks();

console.log(a.theme); // "dark"
console.log(b.theme); // undefined

If Turbopack transforms code so that an instance field is always assigned in the constructor, it can shadow inherited behavior and produce exactly this kind of bug.

Step-by-Step Solution

Until the upstream fix lands, the safest path is to avoid patterns that depend on uninitialized class fields under Turbopack, or switch to a build mode that preserves correct behavior.

1. Reproduce and verify the bug

Run the app using the reproduction steps from the linked issue and compare behavior between Turbopack and the standard Next.js dev pipeline.

npm install
npm run dev

If your project uses the Turbopack dev flag explicitly, test both modes:

next dev --turbo
next dev

If the bug only appears with --turbo, you have confirmed this is a Turbopack transformation issue, not a general class-field bug in your code.

2. Replace implicit class field declarations with explicit constructor logic

If you currently rely on field declarations like this:

class MyClass {
  value;
}

Refactor to an explicit constructor only when you truly want an own property on the instance:

class MyClass {
  constructor() {
    this.value = someInitialValue;
  }
}

If you do not want the property created unless a real value exists, avoid declaring the field at all:

class MyClass {
  constructor(input) {
    if (input !== undefined) {
      this.value = input;
    }
  }
}

This prevents the instance from being polluted with an own property set to undefined.

3. Move default behavior to getters when inheritance matters

If your class depends on fallback values from the prototype chain, prefer a getter or base-class method instead of an instance field declaration.

class BaseConfig {
  get apiMode() {
    return "stable";
  }
}

class FeatureConfig extends BaseConfig {
  constructor(enabledMode) {
    super();
    if (enabledMode !== undefined) {
      this.apiMode = enabledMode;
    }
  }
}

This pattern keeps inherited behavior intact unless you intentionally override it.

4. Disable Turbopack for affected development flows

If the bug blocks your app and the refactor is too invasive, temporarily use the standard Next.js dev server instead of Turbopack.

next dev

In package.json, that can look like:

{
  "scripts": {
    "dev": "next dev"
  }
}

This is often the most practical workaround while waiting for an upstream fix.

5. Audit property existence checks

Search for code paths that treat undefined as equivalent to missing properties. Those assumptions are fragile when a bundler incorrectly materializes fields.

if ("token" in instance) {
  // property exists, even if undefined
}

if (instance.token === undefined) {
  // may mean missing OR explicitly undefined
}

When correctness matters, use the exact check your logic requires:

Object.hasOwn(instance, "token")

That makes debugging much easier if transformed output changes instance shape.

6. Keep a minimal reproduction for upstream tracking

Because this is likely a compiler/runtime parity issue, keep a tiny reproduction project and link it in bug reports. This improves the chances of a precise fix in Turbopack and helps verify regressions in future Next.js releases.

Reference the original report and repo with this reproduction project.

Common Edge Cases

• Subclass overrides: a subclass field declared without a value may overwrite inherited getters or values from the base class.
• Decorators or metadata libraries: tools that inspect instance shape during construction may behave differently when fields are eagerly defined.
• Serialization differences: JSON.stringify ignores undefined values, but property existence checks before serialization may still change application behavior.
• React or Next.js data models: if your class instance feeds props, cache keys, or state normalization logic, explicit undefined fields can change memoization and equality checks.
• ORMs and validation libraries: some libraries distinguish between omitted fields and provided-but-empty fields. Explicit undefined can trigger the wrong branch.
• Private versus public fields: if you mix private fields, public fields, and inheritance, transformed constructor order becomes even more sensitive.

FAQ

Is this a JavaScript bug or a Turbopack bug?

This issue is best understood as a Turbopack transformation bug. JavaScript itself allows explicit undefined assignments, but the compiler must preserve the semantics of the original class syntax. If behavior differs between standard Next.js compilation and Turbopack, the bundling transform is the likely cause.

Why does explicitly assigning undefined matter if the value is still undefined?

Because property existence is part of JavaScript semantics. An own property with value undefined is not the same as no property at all. It affects prototype lookup, in checks, Object.hasOwn, reflection, inheritance, and some framework internals.

What is the safest workaround right now?

The safest short-term workaround is to either disable Turbopack for the affected workflow or refactor code to avoid relying on uninitialized public class fields. If instance shape matters, use explicit constructor assignments only when you truly want the property to exist.

In short, the fix is not just about silencing an odd runtime value. It is about preserving correct class field semantics, especially where inheritance, prototype fallback, and instance shape are critical. If your Next.js app behaves differently only under Turbopack, treat public field declarations as the first place to investigate.