react

Summary Fixes #34378. When a TypeScript function overload signature shares a name with its implementation , babel's returns for the overload-signature id (the binding's path resolves to the impl, so the signature is seen as a reference to it). The BlockStatement hoist analysis in then treats the impl as needing hoisting and lowers it to plus . Inside a reactive memo block the codegen emits: In strict mode (which the compiler output targets, being ESM) the bare declaration is block-scoped to the , so the outer is never assigned and the returned object captures . Consumers then call the destructured and crash with . The fix: skip overload-signature ids () in the hoist visitor. They are type-only and erased at runtime, so they should not influence the lowering of the impl. With the fix, the compiled output for the same input keeps inside the memo block as a local : How did you test this change? Added a fixture reproducing the bug pattern (two TS overload signatures + an impl returned via a hook object). → passes. Full compiler suite: → 1720 Tests, 1720 Passed, 0 Failed. → clean. on touched files → clean. Test verification (RED → GREEN) RED — fixture with the prod fix reverted (the new test fails as expected, since the compiled output crashes at runtime): GREEN — with the prod fix applied:

Summary Fixes #36601 The React Compiler was using a regex check to determine whether a JSX tag is a component or a builtin (host) element. This meant that tags prefixed with underscore (e.g., `a-z{() => }_templowerJsxElementName()BuildHIR.tsbuiltin-jsx-tag-lowered-between-mutationsglobal-jsx-tag-lowered-between-mutationscompiler/.../fixtures/compiler/jsx-underscore-prefixed-tag-is-component.tsx.expect.mdyarn snap -p 'underscore'/^[a-z]/_Bar/^[A-Z]/_Bar` and throws at runtime — diverging from the non-compiled reference. The fixture catches exactly this regression.

Summary Fixes #16589. When was called with a non-function first argument (a common mistake, e.g. passing the memoized value directly instead of a factory), React threw from inside . The stack pointed at React internals and most developers had no idea what referred to — the error didn't name the hook or the component involved. Add a DEV-only warning mirroring the existing warning. The DEV warning fires before the TypeError and names the hook plus the actual of the value received, so the developer sees a component-attributed message pointing at their own code: Expected useMemo() first argument to be a function that returns a value. Instead received: object. in App (at …) Prod behaviour is unchanged — the still surfaces as before. Repro Before: with a stack inside , no hint at which component/hook. After: DEV warning names + the actual type () with a component stack, then the TypeError surfaces if the bug isn't fixed. How did you test this change? New test in — models on the neighbouring tests. : 73 passed / 0 failed (72 baseline + 1 new). : 72 passed / 0 failed — the assertion is a no-op in prod and the still holds. : 96 passed / 0 failed. : 7 passed / 0 failed. — clean. — clean. — clean. 🤖 Generated with Ora Studio _Vibe Coded by Ousama Ben Younes_ _Developed With Ora Studio (Claude Code)_