Repository navigation
Switch default for useDefineForClassFields in ESNext #34787
Description
Activity
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.
Reacted by Jiri SpacThis isn't mentioned in the RC notes for 3.9- has it been bumped to a later version?
Don't think this was done in 3.9 - Nathan Shively-Sanders (@sandersn)?
14 remaining items
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.
Reacted by Cue, Brian Kim, Glandos, Ron Spickenagel and Keith GilletteReacted by Brian KimThis has shipped in TypeScript 4.3.1‑rc, so it probably should’ve been kept in the TypeScript 4.3.1 milestone.
Just ran into this as a bug. Was using
target: ESNEXTand 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 beundefined. 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.
Reacted by webstrandAlternatively, 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
declarebefore the property name.class A { declare x: string; }
Reacted by ExE BossNicolò Ribaudo (@nicolo-ribaudo)
I considerdeclareand 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; } }
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/nodepackage: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d8e2ccd84ce78d70e48863e874653e2d8f9b75ae/types/node/events.d.ts#L21-L22ExE Boss (@ExE-Boss)
But you’re losing the strict property initialization checks right?Class fields moved to stage 4 in the April 2021 meeting, slated for publication in ES2022.
For reference, this was fixed by PR #42663 and released in TypeScript 4.3.
Originally posted by Nathan Shively-Sanders (@sandersn) in #27644 (comment)
useDefineForClassFieldsshould be switched to true when targeting ESNext.