transformer: typescript --useDefineForClassFields

[Boshen]

https://www.typescriptlang.org/tsconfig/#useDefineForClassFields

https://babeljs.io/docs/babel-plugin-transform-typescript

• --useDefineForClassFields You can use the setPublicClassFields assumption to replicate this behavior.

oxc/crates/oxc_transformer/src/compiler_assumptions.rs

Line 50 in aa3222a

pub set_public_class_fields: bool,

[Boshen]

Done in #7011 with setPublicClassFields.

[sapphi-red]

@Boshen Can we reopen this issue as the transform is now disabled? (#7486)
Or should I check #4754?

[sapphi-red]

Is there a way to transform public fields with useDefineForClassFields: false and also keep other class field features as-is? For example, when a user has useDefineForClassFields: false and target: 'es2024'.

[Boshen]

Is there a way to transform public fields with useDefineForClassFields: false and also keep other class field features as-is? For example, when a user has useDefineForClassFields: false and target: 'es2024'.

Not at present.

[overlookmotel]

Is there a way to transform public fields with useDefineForClassFields: false and also keep other class field features as-is? For example, when a user has useDefineForClassFields: false and target: 'es2024'.

What's the use case for transforming public fields, but not private fields?

[sapphi-red]

Is there a way to transform public fields with useDefineForClassFields: false and also keep other class field features as-is? For example, when a user has useDefineForClassFields: false and target: 'es2024'.

What's the use case for transforming public fields, but not private fields?

When a library you depend relies on the useDefineForClassFields: false behavior, but you don't need to transpile everything down to es2021. TypeScript and esbuild both supports this: typescript playground, esbuild try
I don't have a real world case, but I guess there are, because angular sets this by default and lit suggests to set it.

[overlookmotel]

Thanks for the links. I am guessing from lit's docs that this has something to do with decorators, which we've not tackled yet.

This is going to be tricky. How much of a blocker is it?

[sapphi-red]

Both angular and lit sets useDefineForClassFields: false to make decorators work nicely so I guess it won't be a problem until decorators are supported by oxc. I think I can just set the target to es2021 and show a warning that the target was changed for now. Vite has been recommending setting useDefineForClassFields: true regardless of the target and that should reduce the number of affected users.

[overlookmotel]

Just FYI, in case it wasn't clear: Any code which contains decorators currently will not run, because Oxc doesn't transform decorators, and most JS runtimes don't support decorators natively. useDefineForClassFields will not save us!