Repository navigation
Conversation
|
Jest failures are legitimate due to changing some inlining behaviour - looking into that now. I might need to stack a fix under this to do it cleanly. Converting to draft for the moment. |
|
Prerequisite: #59307 |
Summary:
Test only change. RN's own Jest transform (`jest/preprocessor.js`, for this repo's own tests, not public) doesn't include `babel-plugin-jest-hoist`, so `jest.mock` calls run where they're written. Several tests only saw their mocks because inline requires deferred the `require` of the module under test (or of its dependencies) until first use.
That only works for destructured requires like `const {foo} = require('./foo')` while the Babel preset lowers destructuring, which in this config it currently does only as a side effect of lowering generators with regenerator. #59303 removes that, and 114 tests across these 16 suites fail.
This makes the tests install their mocks before the modules under test load, so they pass either way, without diverging Jest's transform from the app's:
- Require modules under test after the `jest.mock` calls that affect them.
- Use mock factories instead of spies or automocks where the code under test binds a function when it loads, or loads an ESM-only package (`octokit/rest`).
- Re-require modules after `jest.resetModules()` where tests reset the registry (`publish-npm`, `Animated`).
The release script tests in particular are dangerous when their mocks silently stop applying - locally, they ran the real version bump against the checkout.
## Changelog:
[INTERNAL] [CHANGED] - Don't rely on inline requires to apply mocks in JS tests
Pull Request resolved: #59307
Test Plan: The full Jest suite passes on this PR (6,284 tests), and with #59303 applied on top (6,285), both under Node 24 with `--no-cache`. Without this PR, #59303 fails 114 tests in 16 suites, matching its CI.
Reviewed By: christophpurrer
Differential Revision: D126757286
Pulled By: javache
fbshipit-source-id: ce39217579aa9805f74786ee9b669bf411e97191
Hermes profiles have lowered generators (with `enableBabelRuntime: false`), `for...of`, `?.`, `??` and optional catch binding in dev builds only since #52651, because Hermes couldn't show local variables when paused on a breakpoint in a native generator. That was a Hermes bug: the generator's resume prologue was stamped with the source location of its last `yield`, so a breakpoint on that line resolved to scope-less entry code. It's fixed in facebook/hermes@d1238c8c6 (hermes-v260318099.0.2), which main has used since #58397. This removes `enableRegenerator`, so Hermes-profile dev output matches release. It also fixes a dev/release divergence - loose `for-of` never calls `iterator.return()`, so breaking out of a `for...of` over a generator skipped its `finally` in dev only. Changelog: [General][Changed] - Babel preset: Hermes profiles no longer lower generators, `for...of`, optional chaining, nullish coalescing or optional catch binding in dev, matching release
474f820 to
405fdcb
Compare
Only in The difference is destructuring of CJS const {foo, bar} = require('./stuff')Is not inlined by It's still lowered and therefore inlined in I didn't spot this in #58965. It's likely to have minimal impact at Meta because there's no change to ESM syntax, but probably a handful of 3P CJS libraries will have lost some inlining. |
Motivation
Summary
Since #52651, Hermes profiles have lowered generators (with
enableBabelRuntime: false),for...of,?.,??and optional catch binding in dev builds only, because Hermes couldn't show local variables when paused on a breakpoint in a native generator.That turned out to be a Hermes bug: a breakpoint on that a
yieldline resolved to scope-less entry code before the body had even run. It was fixed in facebook/hermes@d1238c8 (hermes-v260318099.0.2), which main has used since #58397.This removes
enableRegenerator, so Hermes-profile dev output matches release. It also fixes a dev-only divergence - loosefor-ofnever callsiterator.return(), so breaking out of afor...ofover a generator skipped itsfinallyin dev but not release.Note that with the default
enableBabelRuntime, generators were already native in dev, so in practice the generator change mostly affectsenableBabelRuntime: falsesetups, including RN's own Jest. (There's no good reason generator was ever conditional onenableBabelRuntime === false- it seems to date from #44668 and probably a misunderstanding of what theregeneratorargument to@babel/plugin-transform-runtimedid - it doesn't make that plugin transform generators, it just rewrites the helper import.)Native generator debugging still isn't perfect on .0.2 - stepping through
try/catchcan stop on acatchline that doesn't run, and breakpoints onyield*lines or on athrowafter a resume don't fire. Those already affect every default config though, so there's no regression in most cases. Regenerator has its own problems, eg breakpoints often stop a line early because statements merge into itscaseblocks. Overall, native is now a better experience.Detailed comparison in https://robhogan.github.io/reports/react-native-regenerator-removal/
Changelog
[GENERAL] [FIXED] - Babel preset: Hermes profiles no longer lower generators,
for...of, optional chaining, nullish coalescing or optional catch binding in dev, matching releaseTest Plan
Reproduced the original bug through Hermes's
CDPAgenttest harness withDebugger.setBreakpointByUrl. On hermes-v250829098.0.16 and v260318099.0.1, a breakpoint on a generator's lastyieldline pauses at the generator call with only the global scope, and every local evaluates toundefined. On v260318099.0.2 and .0.4 it pauses at the real code with all locals.AI-driven breakpoint sweep: this preset with
dev: true, enableBabelRuntime: false, before and after this change, over 248 source lines of generator, async function, async generator, exception and loop fixtures. A breakpoint was set on every line, each pause was mapped back through the source map, and every local was evaluated. Same results with eager and lazy compilation.