Summary:
When I upgraded React Native to Prettier v2.x, I removed `format` from a few files to reduce the number of changes.
This is a follow-up to bring back `format` and fix any remaining issues.
Changelog:
[Internal]
Reviewed By: zertosh
Differential Revision: D32287259
fbshipit-source-id: 37ea6d2c973b1db5d37c46d73675bdf436fb9a9d
Summary:
We are in the middle of a Prettier upgrade and some of the files which disagree between Prettier v1.x and v2.x are now being flagged by `eslint-plugin-prettier` as lint errors.
The correct fix here is probably to update `eslint-config-prettier` and `eslint-plugin-prettier`, but I am landing this first to unbreak CI.
Reviewed By: mendoncakeegan
Differential Revision: D32129458
fbshipit-source-id: a5206a5ef58f1d7614f9459c99b9e39109be6de9
Summary:
Changelog: [Internal]
This diff replaced all the internal occurrences of "Immediate" with
"ReactNativeMicrotask" in the legacy bridge and then polyfilled the
original immediate APIs during the timer setup phases as aliases of them.
Note that this diff is part of a larger refactoring.
Reviewed By: RSNara
Differential Revision: D29785430
fbshipit-source-id: 7325d2a7358a6c9baa3e9abb8acf90414de5072f
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:
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:
Flow is changing the behavior of object types to no longer be valid supertypes of classes. This replaces object types when they appear as supertypes of classes to be interfaces to avoid errors when this change rolls out.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D27193522
fbshipit-source-id: c3e3fca8a4cacd90770a95b773ff2c659774b9a6
Summary:
Motivation:
`Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication).` is an error that happens rarely, and most SO answers end up recommending to use `react-native bundle` to work around. I stumbled upon this error the other day and it took me a while to figure out that the error was caused by the fact that my `entryFile` path was pointing to an existing but invalid file. I figured it would be nice to mention this because I believe this will be a frequent cause of the error.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Changed] - improve "not a registered callable module error message"
Pull Request resolved: https://github.com/facebook/react-native/pull/28913
Test Plan:
tested locally with RNTester, prints
```
[Sun May 17 2020 18:15:55.396] ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). This can happen when the application entry file path is incorrect.
On Android, verify 'getJSMainModuleName()' in 'MainApplication.java' and 'project.ext.react.entryFile' in 'android/app/build.gradle'.
On iOS, verify '- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge' in 'AppDelegate.m' and 'ENTRY_FILE' env. variable passed to 'react-native-xcode.sh' (if any) in 'Build Phases' -> 'Bundle React Native code and images'.
```
in metro logs
Reviewed By: mdvacca
Differential Revision: D23107228
Pulled By: fkgozali
fbshipit-source-id: 0712ed7e593ba96b041578bafdbefcd09a3994b7
Summary:
Noticed this hanging around when reading MessageQueue, delete it.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D21874609
fbshipit-source-id: 627c6a18cdb859a1aaf2eb596f8744156d18393c
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:
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: Removes the use of `framesToPop` from method wrappers in the RN bridge.
Reviewed By: rubennorte
Differential Revision: D17764986
fbshipit-source-id: f2fac0c33a9a7c821bb920fa65b92a4672150a38
Summary:
I happened to hit this error a couple times and the issue is that if there are let's say 1000 pending callbacks the error would be triggered 500 times and pretty much crash the app. I think it is reasonable to use warn once here so it only happens once.
## Changelog
[General] [Fixed] - Use `warnOnce` for excessive number of callbacks error
Pull Request resolved: https://github.com/facebook/react-native/pull/26508
Test Plan: Tested by reducing the number of pending callbacks required to trigger the error.
Reviewed By: TheSavior
Differential Revision: D17512917
Pulled By: JoshuaGross
fbshipit-source-id: 5ce8e2a0a166805cc6f3fe6d78e2716d6792a80e
Summary: `parseErrorStack` (which uses the `stacktrace-parser` package) can return null file names, line numbers and column numbers. This diff updates the associated types and adds explicit null checks in some call sites.
Reviewed By: rickhanlonii
Differential Revision: D16542176
fbshipit-source-id: b72c73c05b95df0bbcb5b5baa7bc2d42cff1e074
Summary:
We've seen some crashes from exceeding property limits (>200k) from storing callbacks, which is insane since callbacks should be called and cleaned up right away in most cases. Browsing around I never see more than about 50 pending callbacks when firing off a whole much of animations and measures and stuff.
In order to track down the leak, I added some code in `__DEV__` to provide more info - hopefully some developers will hit it and report the issue. Unfortunately it's not easy to get any useful information in prod because we strip all the useful debug info, but if this continues to be a problem we could try capturing that info in prod as well (and maybe other info, too).
Reviewed By: PeteTheHeat
Differential Revision: D16267702
fbshipit-source-id: 8185bb8ff0d646b307c98238616950086b1a608f
Summary:
When a synchronous call from JS to native code throws an error, it doesn't include a useful stack trace from the native side. To improve error attribution, this diff pops the frames in `MessageQueue.js` and `NativeModules.js` from the stack traces of such errors. This uses the `error.framesToPop` convention understood by RN's global error handler.
For now we limit this to errors converted from C++ exceptions in host functions, since those are not likely to ever contain further JavaScript frames at the point where we catch them; if they did, it would violate our assumption that the top two frames of the stack are in the JS bridge code.
Reviewed By: cwdick
Differential Revision: D15805054
fbshipit-source-id: 8c1dd7c81b00b6a88e31473271889af1f88f7263
Summary: Adds a test for synchronous methods (`type === 'sync'`) in NativeModules. This doesn't modify any behaviour.
Reviewed By: amnn
Differential Revision: D15804757
fbshipit-source-id: 4db76dbd0b0b111ed9311d4b7ec35a077c377f01
Summary: Adds a test for promise-returning methods (`type === 'promise'`) in `NativeModules`. This doesn't modify any behaviour.
Reviewed By: cwdick
Differential Revision: D15802452
fbshipit-source-id: 8dc1f862d33742ef4ba355ca36338e0dbabf8edb
Summary:
Types the last 3 members of the `ModuleConfig` tuple (functions, promise method IDs, and sync method IDs) as nullable and immutable arrays. This is in line with how they are used in the code; one debug-only call site had to be fixed to account for nullability.
Also updates the test data in `MessageQueueTestConfig` to explicitly conform to this type.
Reviewed By: amnn
Differential Revision: D15899159
fbshipit-source-id: b6955ba92efc73253de48e2ce7c3034fa91adce3
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary: Force `getConstants` in native modules to return an empty object when they're not defined in their native implementations.
Reviewed By: fkgozali
Differential Revision: D15393585
fbshipit-source-id: cdda9df0d0f0a98ba226340d3cee67fec63e106c
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:
We need to move animated native module calls to synchronous so we can properly thread them in with mounting instructions in Fabric. Some of them take callbacks so we need to add support for that when switching to synchronous.
A side benefit is that we can unify codepaths a little more with async callbacks.
Reviewed By: shergin
Differential Revision: D14790898
fbshipit-source-id: dc222b9e74375e046e8a9b1b19d72f652dc6722c
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary:
Instead of assigning all the constants exported by a NativeModule to the native module JavaScript object itself, we want to instead export a `getConstants()` method that can be used to access native module constants. This change simplifies the API of native modules. Eventually, we'll remove the ability to access constants as native module object properties alltogether, but that's comes later.
**Note**: I didn't need to make any cpp changes because `JSIExecutor::NativeModuleProxy::get` calls `JSINativeModules::getModule` (here: https://goo.gl/QwPDWF), which eventually calls `JSINativeModules::createModule`, which uses `global.__fbGenNativeModule` (here: https://goo.gl/pSxMgE), which is just an alias to `genModule` in `NativeModules` (here: https://goo.gl/u2wjCs).
Reviewed By: fkgozali
Differential Revision: D13207152
fbshipit-source-id: 375aab1346232819187a5d5b272b33c55992346a
Summary:
`new Date().getTime()` is equal to `Date.now()`.
`Date.now()` avoids an allocation, which can save some GC time.
This micro-optimization isn't worth it in most places, but since MessageQueue is one of the hottest pieces of JS in RN, it's worth it.
Reviewed By: javache
Differential Revision: D9972334
fbshipit-source-id: 05d78fd65304f0f27115d76b8b52db11a52c86a0
Summary:
They are bad :D
And they affect us when trying to migrate to the babel runtime helpers
Reviewed By: pvdz
Differential Revision: D9829462
fbshipit-source-id: 15240a56e707e13775d57714646e4960cfe202df
Summary:
NaN is not handled consistently by the bridge in all cases,
so detect it and complain. In order to make the complaint more
obvious, use JSON.stringify on the value, and a replacer so that some
of the censoring which normally takes place doesn't get in the way of
clarity.
Reviewed By: mmmulani
Differential Revision: D9779799
fbshipit-source-id: 6c1a6bfe05ecaa3aeb558acc49dfd54461e1ba74
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:
ag -L --ignore __snapshots__ 'flow strict|noflow|generated|The controller you requested could not be found.' | ag '\.js$' | xargs ag -l 'flow' | sort > ~/temp
cat ~/temp | xargs ag -L 'flow strict' | xargs sed -i '' 's/flow$/flow strict-local/'
until flow check; do flow check --json | jq -r '.errors[].message[0].path' | sort | uniq | xargs hg revert; done
allow_many_files
The controller you requested could not be found.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9004573
fbshipit-source-id: 936bd5741706b781be06bf08b6ad805a69407dfd
Summary:
This makes JSTimers actively register a callback for callImmediates.
Besides being generally tricky, circular dependency prevent compiling React Native code with bundlers that rely on concatenating module sources rather that evaluating code at the time of requiring, like Google Closure Compiler.
Sadly, Google Closure Compiler setup that prompted this change is complicated and brittle. And there are no good public tools to find circular dependencies among Haste-style modules (with unqualified require paths).
So some advice on a good test plan would be useful. Does Facebook have any tools to find circular dependencies with Haste-style requires?
FWIW, a check that worked for me was to replace all import paths in React Native from Haste style to normal relative paths (which I needed anyway) and then run [`madge`](https://www.npmjs.com/package/madge) on the code base:
```
$ ~/node_modules/.bin/madge --circular react-native/Libraries
Processed 390 files (7.4s) (81 warnings)
✖ Found 2 circular dependencies!
1) BatchedBridge/NativeModules.js > BatchedBridge/BatchedBridge.js > BatchedBridge/MessageQueue.js > Core/Timers/JSTimers.js
2) StyleSheet/flattenStyle.js > StyleSheet/StyleSheet.js
```
(The second cycle is already eliminated in https://github.com/facebook/react-native/commit/a8e3c7f5780516eb0297830632862484ad032c10).
[GENERAL] [MINOR] [MessageQueue] - MessageQueue implementation doesn't have a circular dependency on JSTimers.
Closes https://github.com/facebook/react-native/pull/19526
Reviewed By: hramos
Differential Revision: D8458755
Pulled By: yungsters
fbshipit-source-id: e753139b920ba1ad1a6db10f974c03ca195340c7
Andres Suarez
Tim Yung
Xuan Huang
Daniel Sainati
Luna Wei
Vojtech Novak
Rubén Norte
Peter Argany
George Zahariev
Michael Bolin
Riley Dulin
Pieter De Baets
Moti Zilberman
Janic Duplessis
Logan Daniels
Min ho Kim
Spencer Ahrens
James Ide
Christoph Nakazawa
Ramanpreet Nara
Rafael Oleza
Marc Horowitz
Héctor Ramos
Wayne Cheng
Kirill Nikolaev
Nurzhan Bakibayev
Dmitry Zakharov
Eli White