Install globalEvalWithSourceUrl on bridgeless ReactInstance

[abzokhattab]

Summary:

Problem: In a New Architecture (bridgeless) debug app, Metro lazy chunks fail with:

SyntaxError: Parsing source code unsupported: __d(function (global, require, _

This happens on import() / React.lazy() after first paint. The main bundle still loads.

Root cause: Bridgeless never installs global.globalEvalWithSourceUrl. Bridge mode still does, in JSIExecutor::initializeRuntime.

typeof global.globalEvalWithSourceUrl
// bridgeless: "undefined"
// bridge:     "function"

React Native's debug loader (Libraries/Core/Devtools/loadBundleFromServer.js) already uses that helper so Metro source is evaluated through JSI Runtime::evaluateJavaScript instead of JS eval(). Hermes does not support eval() of Metro __d(...) bundles. Without the helper, split chunks fall through to eval() and throw. Native still loads the main bundle with evaluateJavaScript, so that path works.

Fix: Port the existing JSIExecutor binding into ReactInstance::initializeRuntime so bridgeless exposes the same helper.

Changelog:

[General] [Fixed] - Install globalEvalWithSourceUrl on bridgeless ReactInstance so Metro lazy chunks can be evaluated via JSI

Test Plan:

1. ReactInstanceTest.testGlobalEvalWithSourceUrlIsInstalled asserts the helper is installed after initializeRuntime and can evaluate JS.
2. In a bridgeless debug app, run typeof global.globalEvalWithSourceUrl. Expect 'function' after this change (undefined before).
3. On bridge, typeof global.globalEvalWithSourceUrl remains 'function'.
4. Mount React.lazy(() => import('./SomeModule')) after first paint. The split chunk should load without Parsing source code unsupported.

[meta-cla]

Hi @abzokhattab!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[meta-codesync]

@fabriziocucci has imported this pull request. If you are a Meta employee, you can view this in D122329977.

[javache]

I don't think this addresses your problem. "Parsing source code unsupported" comes from Hermes and means the engine was built without eval support (HERMESVM_LEAN)

[abzokhattab]

Thanks for taking a look.

I agree that message is Hermes rejecting runtime parse (no compiler / HERMESVM_LEAN for JS eval()). The reason this still looks like the right fix is the two load paths:

• The main bundle is already evaluated with JSI Runtime::evaluateJavaScript. That succeeds on the same runtime (app starts, then the failure is only the later split chunk).
• Debug lazy chunks go through loadBundleFromServer / fetch-then-eval, which does eval(body) when global.globalEvalWithSourceUrl is missing. That is the throw.

globalEvalWithSourceUrl is not JS eval(). It is the same JSI evaluateJavaScript path the main bundle already uses (what JSIExecutor installs on bridge). On bridgeless it is never installed, so:

typeof global.globalEvalWithSourceUrl
// bridgeless: "undefined"
// bridge:     "function"

If this VM were fully unable to compile source, the main Metro bundle would fail the same way. It does not. The gap is only that split-bundle loaders fall back to JS eval().

Happy to add a more targeted test if you want (call the helper with a small __d(...) factory, not just '1 + 2').

[javache]

Please add a test (eg fantom?) documenting the difference in behaviour between eval and the globalEval

[abzokhattab]

Added the following test:

• Fantom: packages/react-native/Libraries/Core/Devtools/__tests__/globalEvalWithSourceUrl-itest.js
  • asserts typeof global.globalEvalWithSourceUrl === 'function' on bridgeless
  • evaluates Metro-shaped source through the helper
  • if JS eval() throws, records that (Parsing source code unsupported / eval) so the two paths are documented
• C++: ReactInstanceTest.testEvalVersusGlobalEvalWithSourceUrl does the same comparison on the Hermes runtime used by ReactInstance

The first assertion is the bridgeless gap (helper missing → fail; installed → pass).