fix(es/compat): Handle useDefineForClassFields: false

[magic-akari]

Description:

BREAKING CHANGE:

IMPORTANT NOTE: Users of decorators are recommended to configure "useDefineForClassFields": false to ensure that your code is properly transpiled.

Related issue (if exists):

• fix Inconsistent useDefineForClassFields behavior #6985

[magic-akari]

swc/crates/swc_ecma_transforms_typescript/src/strip.rs

Lines 55 to 71 in d4ebb5e

	/// Align the semantics of TS class fields with TC39 class fields. Defaults
	/// to `false`.
	///
	/// See https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier.
	///
	/// When running `tsc` with configuration `"target": "ESNext",
	/// "useDefineForClassFields": true`, TS class fields are preserved as JS
	/// class fields. We target ESNext, so this our behavior with
	/// `use_define_for_class_fields: true`.
	///
	/// When running `tsc` with configuration `"target": "<ES6-ES2020>",
	/// "useDefineForClassFields": true`, TS class fields are transformed to
	/// `Object.defineProperty()` statements. You must additionally apply the
	/// [swc_ecma_transforms_compat::es2022::class_properties()] pass to
	/// get this backward-compatible output.
	#[serde(default)]
	pub use_define_for_class_fields: bool,

swc/crates/swc/src/config/mod.rs

Lines 1479 to 1482 in d4ebb5e

	#[serde(default)]
	pub use_define_for_class_fields: BoolConfig<false>,
	}

Currently, the default value for use_define_for_class_fields is false. Should we change it?

[kdy1]

I think so. Thank you!

[magic-akari]

I think so. Thank you!

useDefineForClassFields	true	false	None
ES2022	Native	[[Set]]	Native
<= ES2021(TS)	[[Define]]	[[Set]]	[[Define]]
<= ES2021(JS)	[[Define]]	[[Set]]	[[Define]]

So, we choose the Define semantics when there is no input value from the user, right?
This may deviate from TS behavior, however, it ensures consistency in the final column of our table.

[kdy1]

Yes, I think it's more important to be consistent than to align with tsc

[magic-akari]

It appears that microsoft/TypeScript#45995 is a bug in TypeScript that occurs when useDefineForClassFields is absent.

When its value is present, the order of the TS constructor parameter properties always precedes the ECMAScript class field for the four cases of ES Version and useDefineForClassFields: true/false.

Please refer to the following table for more detailed information.

useDefineForClassFields	true	false
ES2022	TS Playground	TS Playground
<= ES2021	TS Playground	TS Playground

[kdy1]

🤣 It was a bug of tsc. What should we do, in your opinion?

[magic-akari]

The microsoft/TypeScript#45995 issue arises only when useDefineForClassFields is missing. However, if it is explicitly set to either true or false, then TS's constructor parameter properties consistently appear first. Hence, we must adhere to TS's behavior.

Moreover, there is another issue in TS where the initialization of constructor parameter properties does not always take effect.

Check the following code.

TS Playground

// @target: es2022
// @useDefineForClassFields: true
class Foo {
  b = this.a;
  constructor(public a = 1){

  }
}

output:

class Foo {
    a;
    b = this.a;
    constructor(a = 1) {
        this.a = a;
    }
}

The value obtained by b is undefined. However, if we reduce the ES version to below ES2022,

TS Playground

class Foo {
    constructor(a = 1) {
        Object.defineProperty(this, "a", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: a
        });
        Object.defineProperty(this, "b", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: this.a
        });
    }
}

B will get the correct value. I believe that such a situation is more reasonable. Therefore, for the scenarios above ES2022, I have made an improvement. SWC will output the following code to ensure correctness.

class Foo {
    a;
    b;
    constructor(a = 1) {
        this.a = a;
        this.b = this.a;
    }
}

[kdy1]

Sounds good, thank you so much for your hard work.

[kdy1]

Thank you!

---

swc-bump:

• swc_ecma_ast
• swc --breaking

[swc-bot]

Automated review comment generated by auto-rebase script