-
-
Notifications
You must be signed in to change notification settings - Fork 554
assumptions.setPublicClassFields
doesn't fully simulate tsconfig useDefineForClassFields
#9192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Probably this isn't critical and the code shouldn't probably depend on such behavior even on |
…lizer` option (#10576) * close #9192 * close #10491 We've discussed adding `removeClassFieldsWithoutInitializer` option to support removing class fields without an initializer in #10491 (comment). This is used to align the`TypeScript`'s `useDefineForClassFields: false` option.
For TypeScript, if you wanted a behavior equivalent to oxc/crates/oxc_transformer/src/compiler_assumptions.rs Lines 82 to 122 in 42ca96a
|
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:
This only works when typescript
useDefineForClassFields: false
, which entirely strips class field parts typescript playgroundOn rolldown-vite, I wasn't able to find a way to achieve this and it's likely because Oxc's
setPublicClassFields: true
resets_map
aftersuper
calls.The text was updated successfully, but these errors were encountered: