Switch default for useDefineForClassFields in ESNext

[DanielRosenwasser]

Since this targets 3.7.1, I'm going to close this bug. When class fields reaches stage 4, I'll do the final two steps.

Originally posted by @sandersn in #27644 (comment)

---

useDefineForClassFields should be switched to true when targeting ESNext.

[sandersn]

Class fields aren't stage 4 yet. Moving to 3.9.

Edit: Still not stage 4. I'll move to 4.4 when that milestone gets created.

[jelbourn]

This isn't mentioned in the RC notes for 3.9- has it been bumped to a later version?

[DanielRosenwasser]

Don't think this was done in 3.9 - @sandersn?

[sandersn]

No, class fields still aren't at stage 4. For 4.0, I did make #37894, which makes suspicious accessor/property override patterns an error everywhere. Together with the included codefix, that finishes off all the planned work for #27644 except this issue.

[CarterLi]

2484210 changed default for useDefineForClassFields which broke my code and took me more than 1 hour to find the reason.

// TS 4.3.0-beta
class A { a: string } // => class A { }

// TS 4.3.2
class A { a: string } // => class A { a }

Such patterns are commonly used with decorators

class MyComponent {
  @property() a: string;
}

It's ok to introduce break changes and it's easy to revert to the old behavior too. The problem is that the release note said nothing about this.

If it's expected, please note it somewhere. Thanks.

[ExE-Boss]

This has shipped in TypeScript 4.3.1‑rc, so it probably should’ve been kept in the TypeScript 4.3.1 milestone.

[brainkim]

Just ran into this as a bug. Was using target: ESNEXT and class properties to define types for classes. I had defined a property on the prototype as an optimization, and when trying to do an upgrade of TypeScript started noticing that the property was overwritten to be undefined. Really would appreciate this kind of change appear in the release notes.

Alternatively, if there were a way to define the types of class properties without buying into the whole TC39 class properties spec, that would be fantastic.

[nicolo-ribaudo]

Alternatively, if there were a way to define the types of class properties without buying into the whole TC39 class properties spec, that would be fantastic.

You can write declare before the property name.

class A {
  declare x: string;
}

[brainkim]

@nicolo-ribaudo
I consider declare and most modifiers to be a little too noisy, but yeah that’s what I’m doing. Thanks for the tip!

One potential option would be to allow us to define properties via sibling interface:

interface Point {
  x: number;
  y: number;
}

class Point {
  constructor() {
    this.x = 0;
    // the absence of this line should cause an error
    // this.y = 0;
  }
}

[ExE-Boss]

@brainkim

One potential option would be to allow us to define properties via sibling interface:

interface Point {
	x: number;
	y: number;
}

class Point {
	constructor() {
		this.x = 0;
		// the absence of this line should cause an error
		// this.y = 0;
	}
}

You can do that already.

It’s used in the @types/node package: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d8e2ccd84ce78d70e48863e874653e2d8f9b75ae/types/node/events.d.ts#L21-L22

[brainkim]

@ExE-Boss
But you’re losing the strict property initialization checks right?

[sandersn]

Class fields moved to stage 4 in the April 2021 meeting, slated for publication in ES2022.

[robpalme]

For reference, this was fixed by PR #42663 and released in TypeScript 4.3.