Although this rule is recommended by the React team,
it does not report incorrect or wrong code for the `correctness` category.
When turned on by default, I find false positive warnings confusing,
I cannot tell whether my code is wrong or the rule implementation is
wrong - see examples in the affine repo.
```
x eslint-plugin-react-hooks(rules-of-hooks): React Hook "use" cannot be called at the top level. React Hooks must be called in a React function component or a custom React Hook function.
,-[packages/backend/server/src/config/affine.self.ts:80:1]
79 | /* Captcha Plugin Default Config */
80 | ,-> AFFiNE.use('captcha', {
81 | | turnstile: {},
82 | | challenge: {
83 | | bits: 20,
84 | | },
85 | `-> });
86 |
`----
```
Follow-up after #7664.
Generalize `duplicate_object` to produce however many duplicates are required. Use it in `transform_expression_to_wrap_nullish_check`.
This should be slightly more efficient, and will make it fool-proof if we expand `duplicate_object` later to handle other `Expression` types.
The `duplicate_object` is great, it has handled unbound identifiers and `this` expressions, so we can remove a lot of code. But it is still a little bit annoying because we need two `object` here, although we can use `clone_in` it needs a special logic for `Expression::Identifier`.
Follow-on after #7668. Rename `create_var*` methods to `create_uid_var*`.
Previous method name `create_var` might suggest that it creates a binding with the provided name. But actually it creates a UID with name *based on* the name provided.
`BigIntLiteral`'s `raw` field is not an `Option` on Rust side, but this is an internal implementation detail - we may parse bigints to a `BigInt` in future (as we did in the past before we hit a memory leak problem), and make `raw` an `Option`.
So at present, the `raw` field is always non-null in JS-side AST. But update the TS type def to reflect that it should be an optional property. This aligns with ESTree.
Follow-on after #7575. Annoyingly, we have to transform private fields in static prop initializers separately, to make sure the stack of private properties is in sync while visiting them.
Follow-on after #7575. Pure refactor. Move all logic for transforming `delete <chain expression>` into the handler `transform_unary_expression`. Aim is to keep logic in one place and keep the main visitor as simple as possible.
Fix#7254
Changed all "raw" properties of literal types (if they have this property) to `Option<Atom>`.
---------
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
Fully support transforming ChainExpression in class properties. Our implementation has some differences in execution order compared to Babel, but we have passed all execution-related tests.
