Install globalEvalWithSourceUrl on bridgeless ReactInstance

[abzokhattab]

Summary:

Problem: On the New Architecture (bridgeless), fetching and evaluating a Metro split bundle in development (lazy=true, import(), React.lazy()) can fail with:

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

The main bundle still loads.

Root cause: global.globalEvalWithSourceUrl is never installed on bridgeless. Bridge mode installs it in JSIExecutor::initializeRuntime.

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

The debug loader (Libraries/Core/Devtools/loadBundleFromServer.js) prefers that helper and only falls back to JS eval() when it is missing. The two paths are not equivalent in Hermes:

• eval() / Function go through evalInEnvironment, which raises Parsing source code unsupported when RuntimeConfig::EnableEval is false (and, on legacy Hermes, when the engine is built lean).
• globalEvalWithSourceUrl goes through Runtime::evaluateJavaScript, the same entry point used to run the main bundle. It is not gated by EnableEval, and it attaches the given source URL to stack traces.

So on a runtime where EnableEval is off (or the engine is lean), the main bundle loads but every split bundle falls into eval() and throws. Bridgeless has no way to reach the JSI path from JS today.

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

Changelog:

[General] [Fixed] - Install globalEvalWithSourceUrl on bridgeless ReactInstance so debug bundle loaders can evaluate split bundles via JSI instead of eval()

Test Plan:

1. ReactInstanceTest.testGlobalEvalWithSourceUrlIsInstalled: helper is absent before initializeRuntime and present after.
2. ReactInstanceTest.testGlobalEvalWithSourceUrlMatchesEvalWhenEvalIsEnabled: with the default RuntimeConfig, eval('1 + 2') and globalEvalWithSourceUrl('1 + 2', 'chunk.js') both return 3.
3. ReactInstanceWithoutEvalTest.testGlobalEvalWithSourceUrlWorksWhenEvalIsDisabled: runtime built with RuntimeConfig::Builder().withEnableEval(false); eval('1 + 2') throws Parsing source code unsupported, globalEvalWithSourceUrl('1 + 2', 'chunk.js') returns 3.
4. Fantom Libraries/Core/Devtools/__tests__/globalEvalWithSourceUrl-itest.js: helper is installed on bridgeless; eval() and the helper evaluate the same source to the same result; an error thrown from the helper carries the given source URL in its stack while the eval() one does not; wrong arity throws.
5. In a bridgeless debug app, typeof global.globalEvalWithSourceUrl is 'function' and a React.lazy(() => import('./SomeModule')) split bundle loads 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).

[javache]

There's no assertions about the result of the eval.

Put the assert on evalError inline in the catch - although fantom tests should never run in Lean mode...

[abzokhattab]

Agreed, that version only exercised the helper. Reworked in c19158b:

Fantom (globalEvalWithSourceUrl-itest.js), no try/catch or lean branch anymore:

• eval(source) and the helper both return 17 and set the same global.
• An error thrown from the helper has the given source URL in its stack; the eval() one does not.
• Wrong arity throws.

C++ (ReactInstanceTest.cpp), which is where the behavioural difference can be forced deterministically: the fixture now takes a RuntimeConfig, and ReactInstanceWithoutEvalTest builds the runtime with withEnableEval(false). There eval('1 + 2') throws Parsing source code unsupported while globalEvalWithSourceUrl('1 + 2', 'chunk.js') returns 3. The default fixture asserts both return 3.

On the lean point: looking at lib/VM/JSLib/eval.cpp and API/hermes/hermes.cpp, raiseEvalUnsupported is reached from eval() when RuntimeConfig::EnableEval is false (and from the lean ifdef on legacy Hermes), but Runtime::evaluateJavaScript has no EnableEval gate. In the case I hit the main bundle was plain Metro source and loaded fine, so the compiler was present and the gate that fired was EnableEval, not a lean build. Either way the helper reaches the path the main bundle already uses. Updated the PR description to say that precisely.