[LogBox] Parse bundling errors from Metro Dev Server and avoid symbolicating them

[krystofwoldrich]

Summary:

This PR improves bundling (transform, syntax and internal Metro errors) handling.

Currently LogBox attaches synthetic stack trace to these errors which is misleading.

The synthetic stack trace also triggers symbolication which will fail causing long and duplicate logs in the metro dev server output.

This PR reuses LogBox Exception parsing for Log parsing as Metro errors are logged using console.error.

• https://github.com/krystofwoldrich/react-native/blob/8997dd0d28100be74bbab7ff8edf69ca5ba2db1a/packages/react-native/src/private/webapis/dom/events/EventTarget.js#L386

Changelog:

[GENERAL] [FIXED] - Parse Metro bundling errors and avoid symbolication

Test Plan:

1. This issue only occurs with HMR bundling issues.
2. Start dev server run the app.
3. Create bundling issue, for example importing from non existing module

import "non-existing-module";

4. Observe that the LogBox is showing clear message and doesn't contain any stack trace. ✅

Example after the PR:

Before the PR:

[rickhanlonii]

This doesn't seem right, we were definitely handling this in the past and there are some unit tests for it like this one.

In your screenshot it looks like there's a codeframe in the message. We attempt to detect any babel errors, and then we render the code frame in LogBox so you can see the issue in the app. This is better than your "after" screenshot, which only shows the message.

I think the problem here is that the error type is "UnableToResolveError" but it should be TransformError like in the test above. Do you know where that error type is coming from?

[rickhanlonii]

This is the wrong place for this

[krystofwoldrich]

UnableToResolve Errors are coming directly from Metro, I don't see that as suspicious, but I might have missed something.

• https://github.com/facebook/metro/blob/95f880f48c9bff3255d8ed5846233ae1911a1a14/packages/metro/src/node-haste/DependencyGraph/ModuleResolution.js#L232

Inside of the application this error is received by the HMRClient which repacks and throws this error.

• https://github.com/krystofwoldrich/react-native/blob/8997dd0d28100be74bbab7ff8edf69ca5ba2db1a/packages/react-native/Libraries/Utilities/HMRClient.js#L370

This thrown error is captured by EventTarget implementation.

• https://github.com/krystofwoldrich/react-native/blob/8997dd0d28100be74bbab7ff8edf69ca5ba2db1a/packages/react-native/src/private/webapis/dom/events/EventTarget.js#L386

---

Looking at this now, I agree and better place to change could be the HMRClient to avoid throwing the compilation error.

Changed in 7db31e2 (#53452)

[krystofwoldrich]

Updated after this PR

Repro krystofwoldrich/musical-octo-chainsaw@8850462

[krystofwoldrich]

Hi @rickhanlonii,
I've simplified the fix, now it's only 2 lines, what do you think?

[cortinico]

cc @vzaidman for visibility also

[react-native-bot]

	Warnings
⚠️	❗ JavaScript API change detected - This PR commits an update to ReactNativeApi.d.ts, indicating a change to React Native's public JavaScript API. Please include a clear changelog message. This change will be subject to extra review. This change was flagged as: BREAKING

Generated by 🚫 dangerJS against 93ac7db

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[react-native-bot]

This PR was closed because it has been stalled for 7 days with no activity.