Summary:
We opt in to version ^5 of the React Native Babel Preset, as required after the bump to Babel 7. This fixes the Objective-C end-to-end test failure in master. (Fixes#19538)
See 34bd776af2 (commitcomment-29024085) for prior discussion.
There have already been several changes made to the repo during the transition to Babel 7. This PR brings all tests back to green and allows us to move forward with the 0.56 branch cut.
We also bump our tests to use Xcode 9.4.0 and iOS 11.4, the latest stable versions of both.
Once the 0.56 branch makes it to stable, we can change `react-native-babel-preset@latest` on npm to point to `react-native-babel-preset@5.0.1` (or newer), and undo the change made to `init.js` we made as part of this diff.
Wait for Circle CI to run: https://circleci.com/workflow-run/e39a66d7-bf8a-4b31-a22f-eef30a2c53bc
[GENERAL] [BREAKING] [Babel] - Bump React Native Babel Preset version used by RN CLI to Babel v7 compliant release
Closes https://github.com/facebook/react-native/pull/19625
Reviewed By: TheSavior
Differential Revision: D8343861
Pulled By: hramos
fbshipit-source-id: 42644d5b0bfb40a8bc592ae3461c5008deef8232
Summary: When a third party library is vendored, both the original copyright header as well as React Native's header are required.
Reviewed By: fkgozali
Differential Revision: D8284116
fbshipit-source-id: 1748eb011c843a87e9ed421597571b66334edfd2
Summary:
Using `EventHandlers` name was a bad idea, and I cannot tolerate it anymore.
The worst part of it is that when you have a collection of `EventHandlers` objects you cannot use plural word to describe it because `EventHandlers` is an already plural word.
And, this object is actually an event emitter, the thing on which we call events.
Reviewed By: fkgozali
Differential Revision: D8247723
fbshipit-source-id: b3303a4b9529bd6d32bb8ca0378287ebefaedda8
Summary:
In this repo we have to require from fbjs/lib/invariant and issues occur when we require directly from invariant/warning. Flow doesn't complain about those requires right now because we have a transitive dependency on invariant and warning causing them to happen to be at the root of node_modules.
This change blacklists requiring directly from invariant and warning using Flow. janicduplessis opened a pull request to do this with ESLint back in 2017: https://github.com/facebook/react-native/pull/13014
Closes https://github.com/facebook/react-native/pull/19634
Reviewed By: hramos
Differential Revision: D8343060
Pulled By: TheSavior
fbshipit-source-id: 9cfc7915b2fb68a567355fc2f5edc4dfcd46f4af
Summary:
During transforming raw prop (`rawProps[<prop>]`) to typed props (`MyProps.<prop>`) we can face three different cases:
* `rawProps` collection has proper serialized value for the key. In this case, we have to set a new value of the typed prop converting value using `fromDynamic`.
* `rawProps` collection does not have value for the key. In this case, we have to copy a value from source prop (`sourceValue`).
* `rawProps` collection has `null` value for the key. This is the special case which means that the prop was removed from the particular component instance and we have to reset it to some *default* value (which is *not* the same as `sourceValue`). Now the default value of the `defaultValue` (sic!) argument is a default value of the type of the value (which may be different from logical default value).
We didn't handle the last case previously and this caused crashes (and unexpected behavior) because `fromDynamic` often cannot handle `null` value.
And yes, all this mean that we also have to update all `convertRawProp` call sites where logical default values are not equal to type-specific default values. This is a potential error-prone place, especially because now we have to specify logical default values in two places (in a prop declaration and in a parameterized constructor). And seems there is no way to avoid that without performance loss (because both of those places are basically constructors).
My hope is that codegen (where default values are also defined in JavaScript) will help with it eventually.
Reviewed By: fkgozali
Differential Revision: D8247652
fbshipit-source-id: 2cbe65f5f5cccd7a0d34aaa19e385aacebfe8cb1
Summary:
RCTSurfaceTouchHandler is a complete rewrite of RCTTouchHandler which uses direct Fabric-specific event dispatching pipeline and several new approaches to managing active events (such as high-performant C++ collections, better management of identifier pool, and so on).
Besides that, the new implementation is much more W3C compliant that it used to be (see old TODOs near `receiveTouches()` implementation in Javascript).
So, touch events work now!
Reviewed By: fkgozali
Differential Revision: D8246713
fbshipit-source-id: 218dc15cd8f982237de7e2497ff36a7bfe6d37cc
Summary: The data model of Touch events and payload serialization. The implementation mimics W3C standard and current React Native implementation.
Reviewed By: fkgozali
Differential Revision: D8246711
fbshipit-source-id: 955b2068674f290d8bdb82da1ebfb796dd32971b
Summary: SUDDENLY, `-[UIFont systemFontOfSize:weight:]` returns incorrect result if `weight` is not exactly equal to any of built-in constants.
Reviewed By: fkgozali
Differential Revision: D8246712
fbshipit-source-id: 13d59cc8d66a4494437f28d791fd93fa83ebe6fb
Summary:
The current implementation of React Native uses `Size` as the underlying type of `textShadowOffset` which is clearly terribly wrong (especially because negative size values makes no sense). This mistake was borrowed from `NSShadow`, I believe.
I don't have time to fix this in every implementation of RN now, so let's use `Size` in Fabric as well.
Reviewed By: fkgozali
Differential Revision: D8246714
fbshipit-source-id: 1f0bf9b9dfa83802ef3faef2971fed5510494bfd
Summary:
Fixes#18637 & #19309
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Check Android `ReactImagePropertyTest` tests pass.
<!--
Does this PR require a documentation change?
Create a PR at https://github.com/facebook/react-native-website and add a link to it here.
-->
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[ANDROID] [BUGFIX] [Unit Tests] - Fix ReactImagePropertyTest SoLoader failure
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/19607
Differential Revision: D8325415
Pulled By: hramos
fbshipit-source-id: 598baa3499646bb50da065815c19bb9f76bf6c87
Summary:
`LayoutableShadowNode.cpp` includes `"LayoutableShadowNode.h"` as well as `<fabric/core/LayoutContext.h>`. In turn, `LayoutContext.h` then includes `<fabric/core/LayoutableShadowNode.h>`. `LayoutContext.h` doesn't actually require `LayoutableShadowNode.h`, but this unnecessary inclusion can cause duplicate definition errors if the two include paths don't map to exactly the same file. This patch removes the unnecessary include.
The CI's build system should cover the testing needed.
[INTERNAL] [MINOR] [fabric] - Remove an unnecessary include in fabric/core/layout.
Closes https://github.com/facebook/react-native/pull/19548
Differential Revision: D8313337
Pulled By: shergin
fbshipit-source-id: 2e01e29ff25131543d9a8601483c2e716c7437be
Summary:
This PR fixes a bug in `deepFreezeAndThrowOnMutationInDev` which did not take into account that objects passed to it may have been created with `Object.create(null)` and thus may not have a prototype. Such objects don't have the methods `hasOwnProperty`, `__defineGetter__`, or `__defineSetter__` on the instance.
I ran into an unrecoverable error in React Native when passing this type of object across the bridge because `deepFreezeAndThrowOnMutationInDev` attempts to call `object.hasOwnProperty(key)`, `object.__defineGetter__` and `object__defineSetter__` on objects passed to it. But my object instance does not have these prototype methods.
Changes:
* Defined `Object.prototype.hasOwnProperty` as a `const` (pattern used elsewhere in React Native)
* Modified calls to `object.hasOwnProperty(key)` to use `hasOwnProperty.call(object, key)` (Per ESLint rule [here](https://eslint.org/docs/rules/no-prototype-builtins))
* Modified calls to deprecated methods `object.__defineGetter__` and `object.__defineSetter__` to instead use `Object.defineProperty` to define get and set methods on the object. (Per guidance on [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/__defineGetter__))
* Added a new test to `deepFreezeAndThrowOnMutationInDev-test` to verify the fix.
I tried to create a reproducible example to post to Snack by passing prototype-less objects to a `Text` component, in various ways, but they appear to be converted to plain objects before crossing the bridge and therefore they do not throw an error.
However, I was able to create a new test to reproduce the issue. I added the following test to `deepFreezeAndThrowOnMutationInDev-test`:
```JavaScript
it('should not throw on object without prototype', () => {
__DEV__ = true;
var o = Object.create(null);
o.key = 'Value';
expect(() => deepFreezeAndThrowOnMutationInDev(o)).not.toThrow();
});
```
The changes in this PR include this new test.
ESLint test produced no change in Error count (3) or Warnings (671)
N/A
Other areas with _possibly_ the same issue:
c6b96c0df7/Libraries/vendor/core/mergeInto.js (L50)8dc3ba0444/Libraries/ReactNative/requireNativeComponent.js (L134)
[GENERAL] [BUGFIX] [Libraries/Utilities/deepFreezeAndThrowOnMutationInDev] -Fix for compatibility with objects without a prototype.
Closes https://github.com/facebook/react-native/pull/19598
Differential Revision: D8310845
Pulled By: TheSavior
fbshipit-source-id: 020c414a1062a637e97f9ee99bf8e5ba2d1fcf4f
Summary:
Change message in Animated.Interpolation to "inputRange must be monotonically non-decreasing" as it's allowed to give the same x's like in the test [example](4435f08771/Libraries/Animated/src/__tests__/Interpolation-test.js (L71))
Simply giving improper value of interpolation input
[GENERAL] [MINOR] [AnimatedInterpolation.js] - Change error message on interpolation improper range error
Closes https://github.com/facebook/react-native/pull/19571
Differential Revision: D8310791
Pulled By: TheSavior
fbshipit-source-id: 803ef55104ad2a36231c5f18c0c089bd14822bf3
Summary:
Bump Prettier to use version 1.13.4
All code changes are caused by running Prettier and should only affect files that have an `format` header.
All other changes caused by yarn.
Reviewed By: ryanmce
Differential Revision: D8251255
fbshipit-source-id: 0b4445c35f1269d72730f2000002a27c1bc35914
Summary:
This updates both [`react-devtools-core`](https://github.com/facebook/react-devtools/issues/941) and [`plist`](04c8ee7646) to include security fixes, reported by `npm audit`.
Fixes#18854
_Only dependencies are updated with security patches, no change in actual code._
_Only dependencies are updated with security patches, no change in actual code._
[GENERAL] [ENHANCEMENT] [react-devtools-core] - Bump to `3.2.2` for a security fix for `ws`
[GENERAL] [ENHANCEMENT] [plist] - Bump to `3.0.0` for a security fix for `xmlbuilder`
Closes https://github.com/facebook/react-native/pull/19373
Reviewed By: sophiebits
Differential Revision: D8149200
Pulled By: hramos
fbshipit-source-id: 732fd627b232c315be60ed2da432742e8256a38a
Summary:
Fix Flow failure by adding a declaration to the Flow config used in open source. This did not get caught internally because we use a different Flow config.
Release Notes
-------------
[INTERNAL] [MINOR] [Flow] - Fix Flow config.
Reviewed By: rafeca
Differential Revision: D8257641
fbshipit-source-id: 3f4b2cbe622b2e76aa018e9369216a6b9ac25f47
Summary:
This uses the reference for `libfishhook.a` from the Products, rather than
the reference from the Frameworks group.
This fixes the build for the new Xcode build system, on both Xcode 9 and
Xcode 10.
Fixes#19569
- Using Xcode 10:
- Open `RNTester/RNTester.xcodeproj`
- Build RNTester, noting build errors
- Using Xcode 9:
- Open `RNTester/RNTester.xcodeproj`
- Switch to using new build system in `File > Project Settings > Build System`, selecting `New Build System (Preview)`
- Build RNTester, noting build errors
none
[IOS] [BUGFIX] [RCTWebSocket] - Fix build for new Xcode build system
Closes https://github.com/facebook/react-native/pull/19579
Differential Revision: D8287487
Pulled By: hramos
fbshipit-source-id: 5bfc9decb09ebc763824df8474b5897099d39ad7
Summary:
This pr makes a little bit simpler to dismiss all warnings (1 click instead of 2)
Sometimes you don't want to use `YellowBox.ignoreWarnings` to remember.
RNTester sceenshot:
<img width="322" alt="screen shot 2018-05-30 at 09 51 25" src="https://user-images.githubusercontent.com/1488195/40701475-1142506a-63ef-11e8-8fc9-ea1696d9cb65.png">
Or RNTester -> Native Animation Example -> Force JS Stalls (in the end of the list) also cause warning to test.
[GENERAL][ENHANCEMENT][YellowBox] - Move `Dismiss All` yellow box button to another place which makes a little bit simpler to dismiss warnings.
Closes https://github.com/facebook/react-native/pull/19501
Differential Revision: D8243823
Pulled By: hramos
fbshipit-source-id: 31887469cddb4adfd7b889ae0c29a3bf41e87b7b
Summary:
As well as nvm.
9d315f4a1e/scripts/react-native-xcode.sh (L56-L60)
Build React Native iOS app with Release configuration and run the script using `node` command which is installed through Homebrew-installed `nodenv` and `node-build`.
None.
[IOS] [ENHANCEMENT] [scripts/react-native-xcode.sh] - Support Homebrew-installed nodenv
Closes https://github.com/facebook/react-native/pull/19509
Differential Revision: D8243181
Pulled By: hramos
fbshipit-source-id: fbd75f377f4aebf89ce35b96a47c59238e62e9ce