Summary:
This adds an option to the Error Reporting pipeline of React Native to attach custom extra data to Exceptions passed to the native ExceptionsManager. This allows for error logging abstractions such as Meta's FBLogger to attach extra fields to the reported error. This can help with more detailed error reports without having to stringify all data in the error message.
Note: The field (which is technically on ExtendedError) is keyed using a Symbol. This is to make sure that any use of this ability is extremely deliberate, as (accidentally) adding tons of data (or unserializable data) can cause issues we send down the data to the native ExceptionsManager implementation. Data sent using this method should be strictly controlled, hence opting in is a concious effort using the symbol in ExceptionsManager
Changelog:
[Internal] [Added] - Ability to add custom data to extraData field of exceptions passed to the ExceptionsManager
Reviewed By: yungsters
Differential Revision: D36099191
fbshipit-source-id: ce3f0dae52acd742de98b71868323c5878eaa677
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary:
We're replacing console.disableYellowBox (untyped, global hack, only warnings) with LogBox.ignoreAllLogs() (typed, local method, handles errors and warnings). rickhanlonii made the initial deprecation of this >2 years ago in https://github.com/facebook/react-native/commit/87f1e22434210ad22f526422bbda0413f59786ce . This diff finally removes the support of `console.disableYellowBox`. Users of LogBox should be using `LogBox.ignoreAllLogs`. This removal also allows us to move LogBox to strict mode flow.
Changelog: [BREAKING] [Removed] Removed console.disableYellowBox in favor of LogBox.ignoreAllLogs.
Reviewed By: rickhanlonii, yungsters
Differential Revision: D34689343
fbshipit-source-id: 3b2865a4918de703e47cd722e3f396475254c65a
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
Changelog: [Internal]
This diff add types to some of the common globals so uses of
them through `global` are now typed.
All the globals are marked as read-only for their intented uses.
However, some of them do have write cites (mostly are in tests to
deliberately set up a special test environment). Those write cites
are considered as "necessary evil" and annotated as `FlowFixMe`.
Reviewed By: yungsters
Differential Revision: D30158145
fbshipit-source-id: 93a99063361a4b7a1e33d9fc97a661be30a4d8f9
Summary:
As suggested by motiz88 on D28421692 (https://github.com/facebook/react-native/commit/883e0d5752b952c829c8d45504d3532f52bb272f), make sure to still report fatal "warnings".
Changelog:
[General][Fixed] Report fatal errors even if its `type` is "warn".
Reviewed By: motiz88
Differential Revision: D28815228
fbshipit-source-id: 8d3b77958ef687a4ce64bdfccbf6ce2dc5557eaf
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Changes `ExceptionsManager` in React Native so that errors with a `type` property equal to `'warn'` are not reported.
This change is banking on the fact that `type` is a non-standard and uncommon property on `Error` instances. If this ends up being problematic, we can instead change this to use a `unstable_type` or `unstable_level` property instead.
Changelog:
[General][Changed] - ExceptionsManager will no longer report exceptions with `type === 'warn'`.
Reviewed By: motiz88
Differential Revision: D28421692
fbshipit-source-id: 3ca19e29f32c8c5cad6dac637dcb930944fb24ed
Summary:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Cleans up `reactConsoleErrorHandler` in `ExceptionsManager` using modern language features, and fixes a minor edge case with how warning-like errors are handled.
Changelog:
[General][Fixed] - Avoid downgrading `console.error` when passed warning-like objects.
Reviewed By: GijsWeterings
Differential Revision: D28418488
fbshipit-source-id: 394e8608c2c81c794c9a0fc155142dcfcfe1c661
Summary:
Some components are using `LogBoxData` directly, forcing logs to be shown on the screen even when LogBox is uninstalled. This changes all accesses to `LogBoxData` to go through `LogBox` so `uninstall` is used correctly.
It also changes when LogBox is installed, moving it from `AppContainer` to `InitializeCore` (which happens earlier) so we can capture more logs in LogBox.
Changelog: [General][Changed] Initialized LogBox earlier and centralized access in LogBox module
Reviewed By: rickhanlonii
Differential Revision: D27999361
fbshipit-source-id: 1115ef6b71e08cc33743d205da0064fbe9a74a0e
Summary:
I want to be able parse error stacks in contexts where I have a call stack string but no error object.
This diff changes parseErrorStack to only accept the stack, instead of a whole error object.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22752048
fbshipit-source-id: b4b1cd58802eefe736130d48a82bc091241a11ee
Summary:
## Changelog:
[Internal][Changed] - Prevent symbolicating stacktrace and no logbox when running in express route
Context:
ExpressRoute doesn't support some things (like promises) due to the limited initialization we do.
Right now the app will crash when trying to evaluate those entrypoints in express route if they depend on such initialization. Ideally a redbox would warn the developer that express route would break if they modify their express-route compatible entrypoint. Displaying a redbox seems to require a bit of refactoring as it can't easily be triggered from native/express-route -- something more to investigate. Occasionally one does appear (when trying the attached test plan) but it is inconsistent and seems dependent on timing of bridge, express route initialization.
The plan:
* Since we are going to roll out an opt-in for each surface (note there are two flags, `fetchWithExpressRouteIfAvailable` and `useExpressRouteIfInitialized` - the former being for using `getPreloadProps` to parallel fetch and the latter as a flag to get route information) we have more control of the roll out of express route.
Things still to improve:
* It's obviously not great that we don't get better errors -- something to address if that is really the next blocker to rolling out ExpressRoute
Reviewed By: sahrens, ejanzer
Differential Revision: D22026444
fbshipit-source-id: 7698109f5921f82a2d0bc9a8346e12b67defca27
Summary:
I was doing some bundle inspection and noticed the LogBox module was included. It does amount to around 15kb so I think it is worth making sure it is not there.
To fix it I moved some imports to require inside __DEV__ blocks to make sure metro is able to remove these imports.
## Changelog
[General] [Fixed] - Make sure LogBox is not included in production bundles
Pull Request resolved: https://github.com/facebook/react-native/pull/28984
Test Plan: Tested using react-native-bundle-visualizer and made sure nothing from LogBox was included in the bundle after these changes.
Reviewed By: TheSavior
Differential Revision: D21794466
Pulled By: rickhanlonii
fbshipit-source-id: 6cb0c0a89633e9850019bd61478c35e9c21638dc
Summary: This enables redbox in bridgeless mode, by removing a dep on the bridge. It also disables full screen logbox, since I couldn't figure out how to get it working without the bridge.
Reviewed By: rickhanlonii, ejanzer
Differential Revision: D21440233
fbshipit-source-id: cb1730fefe1639135fdf06039031975d53f95229
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
In heap snapshots, it was found that really large (20 MB) strings representing network data
were being logged as part of `Systrace.beginEvent` strings from `MessageQueue` in DEV mode.
To combat this, use `JSON.stringify` with limits to keep the depth, strings, arrays, and objects
in check.
Changelog: [Internal] Change `stringifySafe` to have max limits on string size
Reviewed By: yungsters
Differential Revision: D20016501
fbshipit-source-id: e123016557bc154e4210e0b4df44360570da8016
Summary:
This diff replaces YellowBox with LogBox so that it can be deprecated and removed.
After this diff, it will no longer be possible to go back to YellowBox and all paths referencing it will be gone.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949695
fbshipit-source-id: 28a55866e514020bdcc6854aae565cffbbe8af58
Summary: changelog: [General] `console.error` calls, and uncaught exceptions are now displayed in the Metro logs as well
Reviewed By: passy
Differential Revision: D19743075
fbshipit-source-id: a665a06cfc7854ae785af177af8f2478bb1d76b0
Summary:
This diff adds a new `unstable_enableLogBox` function to opt-into the new LogBox experience. If LogBox is not enabled early enough, we show an error with instructions.
With this, LogBox can be enabled with:
```
require('react-native').unstable_enableLogBox();
```
Changelog: [General] [Adds] unstable_enableLogBox
Reviewed By: zackargyle, rubennorte
Differential Revision: D18808940
fbshipit-source-id: 4b0234ddc4d1646515bf63110d5b02133780512e
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
The React team wants exceptions thrown during render to pop over the screen as fatals.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18439258
fbshipit-source-id: dded7b9d93271c1a4eff682be521c7567dfe7d7e
Summary:
This diff changes the LogBox to show the code frame for the first non-collapsed stack frame. Let me know what you think about this change!
Changelog: [Internal] LogBox changes
Reviewed By: rickhanlonii
Differential Revision: D18372456
fbshipit-source-id: ddf6d6c53ab28d11d8355f4cb1cb071a00a7366e
Summary:
This diff adds error handling to logbox so that if there is an error either when parsing logs or when rendering LogBox, we show a native redbox with the error that was thrown and a message explaining that it's an internal React Native error.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18394788
fbshipit-source-id: 5d74d58e4b28ef6d863079e83677fb23ef4ccb34
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
Summary:
This diff adds support for thrown exceptions to redboxes, and hides the native redbox when we show an error in LogBox.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18212064
fbshipit-source-id: 92031d554968bcb079f81568673ae85697c8f5ad
Summary:
Renders frames in RedBox in a greyed-out style when their `collapse` field is set to `true`. This avoids outright hiding information in the stack trace while still drawing attention to frames that are likely to be more meaningful.
Changelog: [General] [Changed] - Render collapsed JavaScript frames in RedBox
Reviewed By: rickhanlonii
Differential Revision: D18039438
fbshipit-source-id: 527588f11c0bff495842be7036cd1293bab65eb9
Summary:
Removes support for the non-standard `framesToPop` error property from React Native. Redboxes will now ignore this field. The way to skip uninformative frames in stack traces going forward is to use Metro's `customizeFrame` config option, for which the React Native CLI ships useful defaults (see: https://github.com/react-native-community/cli/pull/596, https://github.com/react-native-community/cli/pull/780)
Changelog: [General] [Removed] - Remove support for framesToPop from ExceptionsManager
Reviewed By: rickhanlonii
Differential Revision: D17877444
fbshipit-source-id: 04aa332c45ad35a99ae20e05fb87b34c91a557ab
Summary: Reuse preprocessed exception message when sending the symbolicated update to the redbox, in case `preprocessException` has actually modified it.
Reviewed By: cpojer
Differential Revision: D17318008
fbshipit-source-id: 8b4c606c662140fb44c5305e2f3c7faa0b60f0ee
Summary: Adds a way for the app to add information to an exception report before it is sent to native. This API is not final.
Reviewed By: rubennorte
Differential Revision: D16984151
fbshipit-source-id: 8450356d608e05deaed437e2a35094cd16962027
Summary:
* Adds Flow types to `error-guard.js` and propagates them via the `ErrorUtils` module.
* Fixes some call sites to account for the stricter (correct) types.
Differential Revision: D16619538
fbshipit-source-id: c006ff2736ec380763956c4b89702cf44dd4deb0
Summary:
# Context
In https://github.com/facebook/react/pull/16141 we imported `ReactFiberErrorDialog` unchanged from React. That implementation was not idempotent: if passed the same error instance multiple times, it would amend its `message` property every time, eventually leading to bloat and low-signal logs.
The message bloat problem is most evident when rendering multiple `lazy()` components that expose the same Error reference to React (e.g. due to some cache that vends the same rejected Promise multiple times).
More broadly, there's a need for structured, machine-readable logging to replace stringly-typed interfaces in both the production and development use cases.
# This diff
* We leave the user-supplied `message` field intact and instead do all the formatting inside `ExceptionsManager`. To avoid needless complexity, this **doesn't** always have the exact same output as the old code (but it does come close). See tests for the specifics.
* The only mutation we do on React-captured error instances is setting the `componentStack` expando property. This replaces any previously-captured component stack rather than adding to it, and so doesn't create bloat.
* We also report the exception fields `componentStack`, unformatted `message` (as `originalMessage`) and `name` directly to `NativeExceptionsManager` for future use.
Reviewed By: cpojer
Differential Revision: D16331228
fbshipit-source-id: 7b0539c2c83c7dd4e56db8508afcf367931ac71d
Summary: These warnings are both noisy and unactionable to product developers when you disconnect a Metro server. You also see them *after* the redbox is closed anyway, so you kind of already know if symbolication didn't work. So I'm downgrading it to a simple log.
Reviewed By: motiz88
Differential Revision: D16285591
fbshipit-source-id: c0e4c9168f66f4573404aa336ab889e4e9da0c22
Summary:
@public
`reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated.
In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`).
This change is backwards compatible in two senses:
1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable.
2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`.
Naturally, both fallbacks mentioned above discard `extraData`.
NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback.
While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes.
Reviewed By: mmmulani
Differential Revision: D16133080
fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
Summary:
Metro symbolication can be expensive in large apps. However, there is no need to symbolicate _runtime stacks from compile errors_. Those are pretty much useless anyway.
This will reduce the workload on Metro workers, and the delays when iterating with Fast Refresh, as the server will be busy much less often.
So I'm special-casing them and not sending the symbolication request anymore.
Reviewed By: rickhanlonii
Differential Revision: D16030087
fbshipit-source-id: 41f83ac01780c0a60cca777014e4ed95c0f3d14b
Summary: If some stack frames in a trace fail to symbolicate (or are genuinely unmapped), their `frame` field will be null, and `ExceptionsManager.js` will currently crash. This diff lets it recover gracefully and show whatever information is available.
Reviewed By: dcaspi
Differential Revision: D15296220
fbshipit-source-id: 2b1006b1354295171b25bfc6230c5b3e0c57f67f
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
On iOS, `RCTRedBox` will not update the displayed stack trace if the message string sent with the update differs from the original error message. As JS errors are shown in two stages - before and after symbolication - there was previously a case where the message would differ between the two `updateExceptionMessage` calls, blocking the update and leaving only the unsymbolicated trace visible. This diff fixes that.
Longer term, we should also change `RCTRedBox`'s logic to rely on the JS-provided `exceptionID` instead of the message string - similar to what we do on Android.
Changelog:
[iOS] [Fixed] - Fix redbox JS symbolication when adding JS engine tag to the message
Reviewed By: sahrens
Differential Revision: D15202524
fbshipit-source-id: 237fc090e88b0c609865e0aed842d6a609c1239a
Summary:
To avoid "js engine: ..." appearing everywhere, only add this information
to the error message when react native is reporting errors to the server.
Reviewed By: yungsters
Differential Revision: D9754371
fbshipit-source-id: a8001480c75ccf93c953c79f26470df678871cb3
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Gijs Weterings
Pieter Vanderwerff
Andres Suarez
Tim Yung
Lulu Wu
Xuan Huang
Daniel Sainati
Rubén Norte
Rick Hanlon
Luna Wei
Janic Duplessis
Peter Argany
Michael Bolin
Riley Dulin
Michel Weststrate
George Zahariev
Christoph Nakazawa
Moti Zilberman
Logan Daniels
Dan Abramov
Michał Pierzchała
James Ide
Yue Xu
Héctor Ramos
Eli White
