Incorrect class #private fields initialization order with target ES2022 and useDefineForClassFields set to false

Bug Report

🔎 Search Terms

ES2022 class field initialization order
private fields order
useDefineForClassFields false

🕗 Version & Regression Information

This changed between versions 4.9.5 and 5.0.4

⏯ Playground Link

5.0.4 with runtime error (useDefineForClassFields: false, target: ES2022)

4.9.5 without runtime error (useDefineForClassFields: false, target: ES2022)

💻 Code

class Buzz {
    wow = 'one'
}

class Foo { 
    #bar = this.buz.wow;
    constructor(private buz: Buzz) {}
}

new Foo(new Buzz())

🙁 Actual behavior

With 5.0.4 and useDefineForClassFields: false, target: ES2022 the above code fails in runtime because #bar = this.buz.wow; stays initialized before constructor, this doesn't happen if "normal private" is used (private bar = this.buz.wow;). Such construct works without issues on 4.9.5.

🙂 Expected behavior

The initialization is done in the same way as on 4.9.5.

Still an issue in 5.1.3.

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

That's fine as long as there is an error produced on compilation time. Having this quietly passing produces a lot of hard to understand issues on run-time.

Any updates on compilation errors / order fix?

Same on 5.1.6.

Joshua Chen (@Josh-Cena)

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

Joshua Chen (@Josh-Cena) if this is the expected behavior, I think that, at least, should be a compilation error....

class Buzz {
    wow = 'one'
}

class Foo { 
    #bar = this.buz.wow;
                ^^^_ This is property is uninitialized... or something similar

    constructor(private buz: Buzz) {}
}

new Foo(new Buzz())

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

I think this is supposed to work, but we didn't handle this case correctly when private fields were introduced. The ideal solution would be for parameter properties to work with both private fields and --useDefineForClassFields. For such a feature to work correctly, we would have to choose between two different behaviors:

Parameter properties are initialized before all class fields, or
Parameter properties are initialized after all class fields

Prior to the adoption of private names, the TypeScript emit followed (1), which I believe is still the best approach.

If we want to correctly preserve these semantics and this evaluation order in the presence of private names or --useDefineForClassFields, then the correct emit would be to:

declare all of the class fields, including private-named fields and those introduced by parameter properties
Initialize the fields introduced by parameter properties
Initialize the remaining fields in the order they appear in the class body.

This means moving the field initializers into the constructor body:

// source
class C {
  y = this.x;
  #z = this.y;
  constructor(public x) {}
}

// transpiled
class C {
  x;
  y;
  #z;
  constructor(x) {
    this.x = x;
    this.y = this.x;
    this.#z = this.y;
  }
}

If we want to correctly preserve these semantics and this evaluation order in the presence of private names or --useDefineForClassFields, then the correct emit would be to:

declare all of the class fields, including private-named fields and those introduced by parameter properties

Initialize the fields introduced by parameter properties

Initialize the remaining fields in the order they appear in the class body.

This means moving the field initializers into the constructor body:
// source
class C {
  y = this.x;
  #z = this.y;
  constructor(public x) {}
}

// transpiled
class C {
  x;
  y;
  #z;
  constructor(x) {
    this.x = x;
    this.y = this.x;
    this.#z = this.y;
  }
}

That's the behavior I expected. Cool to know it's an unexpected breaking change, and this issue is someting fixable 😄

5.3.2 still affected

I forgot to mention a small workaround I wrote couple months ago. It's possible to detect wrongly defined properties using eslint and this rule:

'no-restricted-syntax': [
      'error',
      {
        selector: 'PropertyDefinition[key.type="PrivateIdentifier"]:has(ThisExpression)',
        message: 'Use `private` modifier until https://github.com/microsoft/TypeScript/issues/54206 is fixed.',
      },
    ],

Hope this helps someone to prevent runtime issues.

No change in 5.4.3

5.5.2 also affected

I came here because I'd like to write code like this:

class Foo {
  baz = this.bar.baz

  constructor(public bar: { baz: unknown }) {}
}

… instead of like this:

class Foo {
  baz

  constructor(public bar: { baz: unknown }) {
    this.baz = this.bar.baz
  }
}

… because:

the later requires separating declaration from initialization; this is almost like requiring to write let value; value = 42 instead of a simple const value = 42
I don't think constructor should do any complicated work, and I'm too used to it being completely empty

… and I assumed that this works for #fields the same way. Provided that TypeScript does #54206 (comment), it shouldn't be any less intuitive.

Confirmed this still reproduces on both current stable and nightly:

TypeScript 7.0.2
TypeScript 7.1.0-dev.20260713.1

Compiler options:

{
  "target": "ESNext",
  "module": "NodeNext",
  "moduleResolution": "NodeNext",
  "useDefineForClassFields": false,
  "strict": true
}

Minimal reproduction:

class Dependency {
  create(): string {
    return "ok"
  }
}

class Broken {
  #value = this.dependency.create()

  constructor(private readonly dependency: Dependency) {}

  read(): string {
    return this.#value
  }
}

console.log(new Broken(new Dependency()).read())

For both versions, tsc exits successfully with no diagnostic. The emitted
field remains ahead of the parameter-property assignment:

class Broken {
  #value = this.dependency.create();

  constructor(dependency) {
    this.dependency = dependency;
  }
}

Running the output exits 1 with:

TypeError: Cannot read properties of undefined (reading 'create')

This appears to be the native-private-field gap adjacent to #50971 / #55028:
with useDefineForClassFields: false, an ordinary field initializer is moved
into the constructor after the parameter-property assignment, but a #private
initializer remains native and the compiler also does not issue TS2729.

We encountered this in emitted NestJS resolver code. Type-checking and
source-level tests passed; a post-build constructor check reproduced the runtime
failure before rollout. The local workaround is to use TypeScript private or
initialize the #private field explicitly inside the constructor.

Navigation Menu

Repository navigation

Incorrect class #private fields initialization order with target ES2022 and useDefineForClassFields set to false #54206

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect class #private fields initialization order with target ES2022 and useDefineForClassFields set to false #54206

Description

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Activity

Michsior14 commented on Jun 2, 2023

Josh-Cena commented on Jun 2, 2023

Michsior14 commented on Jun 3, 2023

Michsior14 commented on Jun 29, 2023

Michsior14 commented on Jul 12, 2023

tonivj5 commented on Jul 26, 2023

rbuckton commented on Jul 26, 2023

tonivj5 commented on Jul 26, 2023

Michsior14 commented on Dec 1, 2023

Michsior14 commented on Dec 11, 2023

Michsior14 commented on Mar 25, 2024

Michsior14 commented on Jun 21, 2024

parzhitsky commented on Feb 8, 2025

dilame commented on Jul 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions