TS parameter properties (constructor initializers) are wrongly available in other class fields, differs from babel

[elado]

Describe the bug

Seems like constructor(private field: Type) produces code that runs in a different order from Babel, resulting in runtime differences.

The following code:

function createObj(prop: string) {
  console.log(`[createObj] ${prop}`);
  return { prop };
}

class Something {
  private prop: string;
  constructor(private prop: string) {
    this.prop = prop;
    console.log(`[Something] constructor ${this.prop}`);
  }

  private readonly obj = createObj(this.prop);
}

new Something(1)

with Target ES2022 transpiles to

function createObj(prop) {
    console.log(`[createObj] ${prop}`);
    return {
        prop
    };
}
class Something {
    prop;
    constructor(prop){
        this.prop = prop;
        this.obj = createObj(this.prop);
        console.log(`[Something] constructor ${this.prop}`);
    }
    obj;
}
new Something(1);

Running it logs:

[createObj] 1
[Something] constructor 1

Babel, however, transpiles to

function createObj(prop) {
  console.log(`[createObj] ${prop}`);
  return {
    prop
  };
}
class Something {
  constructor(prop) {
    this.prop = prop;
    console.log(`[Something] constructor ${this.prop}`);
  }
  obj = createObj(this.prop); // <--- Left as a class field
}
new Something(1);

and logs show

[createObj] undefined
[Something] constructor 1

because createObj runs before this.prop is assigned.

I'd imagine the spec says to define all class props first, then run constructor, but I'm not entirely sure.

Input code

No response

Config

No response

Playground link

No response

Expected behavior

That this.prop stays undefined when calling createObj.

Actual behavior

No response

Version

1.3.56

Additional context

https://play.swc.rs/?version=1.3.56&code=H4sIAAAAAAAAA2WPMQ7CMAxF95zCA0OzVGKl4gwMjKhS2yiUVCWuHKcMVe6OyxAiGLx8fb3%2FfI%2FesEMPhmzP9jJM1UK4nCAwOT9q2BSAQR9wtvWMY9XdcrOFw7aXU6cbaZHlSB422DNIjUpKmbkPAa74tPwQXKYxRcNIsuVWgcH%2F5u9qZrQlQAwkDHWhkeRwmOBcvJQ7%2BmPl7evrVB21egN0VDpJBgEAAA%3D%3D&config=H4sIAAAAAAAAA1VPOw7DIAzdOQXy3KFi6NA79BCIOhERAYQdqSjK3QsJpM1mv4%2Ff8yqkhIkMPOVaxrJEnQjTuReEsmf9KQhwjkgm2chw6yxTpQbtCHdoOxhgnUbk6kJSd6WaA1wIhN3RsNl6O%2BT%2FTBPmmJDoKqxS7UeH10TRUmEO72Un2y%2B179HgAT9RDzsPg6VXd3JaUGxfBMLf3xcBAAA%3D

[magic-akari]

• Inconsistent parameter properties initialization order depending on the target syntax with useDefineForClassFields microsoft/TypeScript#45995
• fix(es/compat): Handle useDefineForClassFields: false #7055 (comment)

[magic-akari]

I'd imagine the spec says to define all class props first, then run constructor, but I'm not entirely sure.

I think you are right. The problem is the TypeScript constructor field, which is not part of the JS specification.
I'm not sure what to do with it.

[elado]

Since there's no clear spec and babel/tsc/swc all differ on the implementation (also different based on config) I am adding https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/parameter-properties.md to disallow parameter properties in my project.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.