feat: unify class properties transform in ts and js

[Austaras]

Description:
And also expose an use_define_for_class_fields somewhere

BREAKING CHANGE:
It will break rust users

It won't be possible to use [[Set]] for pulibc fields and preserve private fields.

It will be a break change for ts users who want es2022/esnext output, but this is aligned with babel behaviour. And consider tsc doesn't have target env and would set useDefineForPublicFields to true in es2022, this shall also be aligned with tsc.

Related issue (if exists):
closes #3827, closes #3389, closes #3317, closes #3228, supersedes #3764

[Austaras]

One major difference would be class exprs where ts transform uses a sequence expr while js transform uses a iife.

This should be fixed.

[Austaras]

Ah, I've encountered with microsoft/TypeScript#45995

[Austaras]

Here's some observerations about initialized order of parameter properties:

1. tsc would init parameter properties before normal properties in target before es2022, however in target es2022 and esnext tsc would preserve class properties, so noraml ones would be initialized first. As tsc doesn't follow semantic versioning, this may soon changes.
2. babel simply transform parameter properties into assignments and preserve class normal properties, so in any case normal properties would be initialized first
3. esbuild would transform parameter and noraml properties into assignments so the initialized order is preserved, but it doesn't support useDefineForClassFields

I originally would like to choose route 3, but consider private properties

class A {
  a = 123
  #a = 456
  constructor(public b) {
    console.log(this.#a)
  }
}

a cannot be simply transformed into assignments, because it needs to be initialized before #a, but only if we bring whole class_properties in(and surprisingly, this is not impossible!), private properties could not be safely transformed. So now I choose to turn it into

class A {
 a
  constructor(b) {
    this.b = b
    this.a = 123
    this.#a = 456
    console.log(this.#a)
  }
}

This would generate many useless boilerplate, but at least it's consisent and doesn't break current tests. Hopefully not many people would use private properties in TypeScript.

[kdy1]

Hmm... Yeah I think your decision is right although I'm a bit confused by other tools.

[Austaras]

Oh, and ts has same bug I fixed in previous pr

[kdy1]

I didn't review fully yet.
I will do it soon, but I think I found a bug

[kdy1]

Thank you so much!

---

swc-bump:

• swc_ecma_transforms_base --breaking

[kdy1]

const a = 1;

class C {
    static f1 = 1;

    static {
        console.log(C.f1, C.f2, C.f3)
    }

    static f2 = 2;

    static {
        console.log(C.f1, C.f2, C.f3)
    }

    static f3 = 3;
}

and output of original file is

1 undefined undefined
1 2 undefined

[kdy1]

Okay, it's correct.
Thanks!

[Austaras]

Yes, the original output is wrong