`assumptions.setPublicClassFields` doesn't fully simulate tsconfig `useDefineForClassFields`

[hi-ogawa]

reproduction: https://github.com/hi-ogawa/reproductions/tree/main/unocss-countable-set

I found a somewhat odd code on unocss while testing it with rolldown-vite https://github.com/unocss/unocss/blob/0a32090ddf452ef78ad5bedb6d5e888a161fefc9/packages-engine/core/src/utils/countable-set.ts. A simplified version is the following:

class CountableSet<K> extends Set<K> {
  _map: Map<K, number>

  constructor(values?: Iterable<K>) {
    super(values)  // `super` calls `add` which initialize `this._map`
    this._map ??= new Map()
  }

  add(key: K) {
    this._map ??= new Map()
    this._map.set(key, (this._map.get(key) ?? 0) + 1)
    return super.add(key)
  }
}

console.log(new CountableSet(["foo"]))
// expected to output
// CountableSet(1) [Set] { 'foo', _map: Map(1) { 'foo' => 1 } }

This only works when typescript useDefineForClassFields: false, which entirely strips class field parts typescript playground

class CountableSet extends Set {
    constructor(values) {
        super(values);
        this._map ?? (this._map = new Map());
    }
   ...

On rolldown-vite, I wasn't able to find a way to achieve this and it's likely because Oxc's setPublicClassFields: true resets _map after super calls.

class CountableSet extends Set {
        constructor(values) {
                super(values);
                this._map = void 0; 
                this._map ?? (this._map = new Map());
        }
...

console.log(new CountableSet(["foo"]))
// rolldown-vite output
// CountableSet(1) [Set] { 'foo', _map: Map(0) {} }

[hi-ogawa]

Probably this isn't critical and the code shouldn't probably depend on such behavior even on useDefineForClassFields: false. For unocss case, it's actually broken on published version, so I suggested a fix there to eliminate such class field behavior dependence unocss/unocss#4436.

[Dunqing]

For TypeScript, if you wanted a behavior equivalent to useDefineForClassFields: false, you should set both set_public_class_fields and TypeScript's remove_class_fields_without_initializer to true.

oxc/crates/oxc_transformer/src/compiler_assumptions.rs

Lines 82 to 122 in 42ca96a

	/// When using public class fields, assume that they don't shadow any getter in the current class,
	/// in its subclasses or in its superclass. Thus, it's safe to assign them rather than using
	/// `Object.defineProperty`.
	///
	/// For example:
	///
	/// Input:
	/// ```js
	/// class Test {
	/// field = 2;
	///
	/// static staticField = 3;
	/// }
	/// ```
	///
	/// When `set_public_class_fields` is `true`, the output will be:
	/// ```js
	/// class Test {
	/// constructor() {
	/// this.field = 2;
	/// }
	/// }
	/// Test.staticField = 3;
	/// ```
	///
	/// Otherwise, the output will be:
	/// ```js
	/// import _defineProperty from "@oxc-project/runtime/helpers/defineProperty";
	/// class Test {
	/// constructor() {
	/// _defineProperty(this, "field", 2);
	/// }
	/// }
	/// _defineProperty(Test, "staticField", 3);
	/// ```
	///
	/// NOTE: For TypeScript, if you wanted behavior is equivalent to `useDefineForClassFields: false`, you should
	/// set both `set_public_class_fields` and [`crate::TypeScriptOptions::remove_class_fields_without_initializer`]
	/// to `true`.
	#[serde(default)]
	pub set_public_class_fields: bool,