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:
Error objects logged as part of the arguments to `console.error` such as from [rejected es6 promises](https://github.com/zloirock/core-js/blob/v2/modules/es6.promise.js#L110) contain the error that the user would want to see as the error object's message, but is not captured by `stringifySafe`. Here we modify it to if the logged value is an error object print the error similar to chrome:
```
const error = new Error('error');
stringifySafe(error); // Error: error
```
Versus the current behavior which does not recognize the error type and instead tries to stringify the it as an object:
```
JSON.stringify(new Error('error')) // "{}"
```
## Changelog
[JavaScript] [Changed] - Add support for stringifying error object messages to safeStringify
Pull Request resolved: https://github.com/facebook/react-native/pull/25723
Test Plan:
Tests:
<img width="802" alt="Screen Shot 2019-07-18 at 8 39 52 PM" src="https://user-images.githubusercontent.com/2192930/61501171-39218080-a99c-11e9-8e87-48ea413b3d01.png">
Lint:
<img width="406" alt="Screen Shot 2019-07-18 at 8 43 35 PM" src="https://user-images.githubusercontent.com/2192930/61501318-dc729580-a99c-11e9-9264-c0232515352c.png">
Differential Revision: D16437956
Pulled By: cpojer
fbshipit-source-id: ca3ce9c98ad585beb29c2bfeb81bbd14b2b1c700
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:
I was looking at the coverage report of the JavaScript code in the `Libraries` folder, and found some of the modules and functions to be (partially) untested. I believe that adding tests to them would formally capture their behaviour and avoid future regressions. In this PR, I've added some unit tests for 3 utility components.
Perhaps a more general question: Are these kinds of PRs appreciated? I'd be interested in submitting more of them in the future.
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23903
Differential Revision: D14477601
Pulled By: cpojer
fbshipit-source-id: c0700c5b514cd0df983fecfd91c93fc2bd049f5d
Michael Bolin
Riley Dulin
Dan Reynolds
James Ide
Georgios Andreadis
