Summary:
`JSIndexedRAMBundle` used to read scripts including the terminating null bytes. That worked on iOS, but not on Android, where we have an ascii-only optimization.
This changes that behavior to only read the actual script data excluding the terminal null.
Reviewed By: javache
Differential Revision: D4265374
fbshipit-source-id: 7e6f943666aee610d79939cef09b103305803c69
Summary:
The line
`Please make sure you export the correct path for 'ANDROID_HOME' if you did not install the Android SDK using Android Studio.`
was visible twice (one on top of another) in the docs when viewing linux instructions. I removed the block that set it visible on both linux and windows and incorporated it into the existing windows block.
Closes https://github.com/facebook/react-native/pull/11276
Differential Revision: D4269783
Pulled By: hramos
fbshipit-source-id: 423fca3219567cf96d91aefc43d1ddabb2403728
Summary:
Add link with more details of how to resolve warnedMissingNativeAnimated warning.
Closes https://github.com/facebook/react-native/pull/11224
Differential Revision: D4268352
fbshipit-source-id: 679574570aea2f4ec7083247d5b6dcba378e8560
Summary:
By default Android will put extra space above text to allow for upper-case accents or other ascenders. With some fonts, this can make text look slightly misaligned when centered vertically.
We have found that the effect is very noticeable with certain custom fonts on Android. On iOS the font aligns vertically as expected.
Android exposes a property `includeFontPadding` that will remove this extra padding if set to false. This PR exposes that to JS, and adds it to the documentation and UIExplorer.
Closes https://github.com/facebook/react-native/pull/9323
Differential Revision: D4266713
Pulled By: lacker
fbshipit-source-id: f9711254bc26c09b4586a865f0e95ef4bf77cf3f
Summary:
We have changed the release schedule but haven't updated docs yet. This is a small PR that aims to fix it where applicable.
Likely to be cherry-picked to 0.40 branch since its the new one following that system.
Differential Revision: D4266155
Pulled By: mkonicek
fbshipit-source-id: 952af7a0f35a3d984aeadb6efe02f0990830ed8b
Summary:
Let's continue to bring Flow goodness to the codebase, as it will facilitate future refactorings.
I fixed a few of the typing issues by changing the local logic at times, but in a way that should not cause any difference globally.
Reviewed By: cpojer
Differential Revision: D4265347
fbshipit-source-id: a2a7afd7d93cf00ba58e8c9879a9bb6d5bf30358
Summary:
**Motivation**
When running `react-native-git-upgrade` with an unknown version, the error message isn't very helpful
**Test Plan**
- Publish the `master` branch to Sinopia
- Run `react-native-git-upgrade 0.666.0` inside a RN project
- Error message is `SyntaxError: Unexpected end of JSON input`
- Publish this branch to Sinopia
- Run `react-native-git-upgrade 0.666.0` inside a RN project
- Error message should be `Error: The specified version of React Native 0.666.0 doesn't exist.
Re-run the react-native-git-upgrade command with an existing version,
for example: "react-native-git-upgrade 0.38.0",
or without arguments to upgrade to the latest: "react-native-git-upgrade".`
Closes https://github.com/facebook/react-native/pull/11264
Differential Revision: D4265553
Pulled By: mkonicek
fbshipit-source-id: 8597eb09cc3397bfa6d2205a9b3bb30acfad530f
Summary:
6554ad5983 broke assets on windows, this fixes it and add a test to avoid regressions.
Ideally we'd run all the Dependency graph tests on both posix and win32 filesystems but that would probably require doing some sort of factory function to create the tests because I don't think we want to duplicate every test (file is big enough already :)). So for now I just copied that one test and changed the paths manually.
**Test plan**
Run the new test without the fix -> fails
Run the new test with the fix -> succeeds
Closes https://github.com/facebook/react-native/pull/11254
Differential Revision: D4265157
Pulled By: cpojer
fbshipit-source-id: 511470276bd950c2943e94c2dce6840df0fe6d69
Summary:
**Motivation**
If the project is using yarn to manage its dependencies, we should be running 'yarn add' to upgrade the React Native dependency, rather than 'npm install'.
**Test plan (required)**
Running in a project that's in a bad state:
Error: react-native version in "package.json" (0.29.2) doesn't match the installed version in "node_modules" (0.38.0).
Try running "yarn" to fix this.
Removed yarn.lock file, ran again:
Error: react-native version in "package.json" (0.29.2) doesn't match the installed version in "node_modules" (0.38.0).
Try running "npm install" to fix this.
Running inside a folder that doesn't contain a `package.json` file:
Error: Unable to find "/Users/mkonicek/Zero29App/package.json" or "/Users/mkonicek/Zero29App/node_modules/react-native/package.json". Make sure you ran "yarn" and that you are inside a React Native project.
Removed yarn.lock file, ran again:
Error: Unable to find "/Users/mkonicek/Zero29App/package.json" or "/Users/
Closes https://github.com/facebook/react-native/pull/11225
Differential Revision: D4261102
Pulled By: mkonicek
fbshipit-source-id: b44ae91fe46f2c81b14616ca2868cc171692c895
Summary:
Fixes#10433
The code didn't account for the fact that cancelLoad is set by two different threads. It gets set on the URL request queue when the request completes successfully and it gets set on the UI queue during cancelation. This oversight lead to a couple of different kinds of crashes.
1. Attempt to invoke a nil function -- We check that cancelLoad is non-nil and on the next line we call it. However, cancelLoad could have been set to nil by the other thread between the time it was verified to be non-nil and the time it was called. Consequently, the program will attempt to call nil and crash.
2. Block deallocated while it's executing -- Suppose cancelLoad points to a block, it is verified to be non-nil, and it is successfully invoked. In the middle of executing the block, cancelLoad, the last reference to the block, is set to nil. This causes the block to be deallocated and its captured values to be freed. However, the block continues executing and the next time it attempts to use a captured value
Closes https://github.com/facebook/react-native/pull/11145
Differential Revision: D4261499
Pulled By: javache
fbshipit-source-id: 46424c6dd8cfa085cef32d945308de07798040bc
Summary:
**Motivation**
This morning I was trying to test on iPhone 7 with iOS 10 so I booted that device and ran "react-native run-ios" expecting it to notice I had a simulator running and install my app to it. Instead it switched my device to the iPhone 6s iOS 9.2. After digging it was found that run-ios did not handle multiple versions of iOS being installed very well when it came to checking for the booted device. This PR resolves that.
**Test plan (required)**
Tests were added for the situation of multiple iOS versions being installed and a slight change to the code was completed to make the new tests pass and continue to keep the old tests passing.
Closes https://github.com/facebook/react-native/pull/10558
Differential Revision: D4163616
Pulled By: hramos
fbshipit-source-id: 26b44fb73ef402ce252e7a754036279e15359170
Summary:
**Motivation**
As NoelBroda pointed out in https://github.com/facebook/react-native/pull/11104 and https://github.com/facebook/react-native/pull/11123, NPM often produces an unmet peerDependency when upgrading React Native. It causes a failure when running "npm install" with NPM2.
During the git-upgrade, we have to take care of the `react` peerDep: this PR checks if the installed `react` package matches the `react` peerDep of the new `react-native` version. If so, R & RN are upgraded at the same time (in the same `npm install`).
**Test plan**
- Publish `react-native-git-upgrade` to Sinopia,
- Run `react-native-git-upgrade` inside a RN project with version < 0.37,
- Verify that no "unmet peer dependency" warning is displayed
- Open the `package.json` and verify that both R & RN have been updated
Closes https://github.com/facebook/react-native/pull/11226
Differential Revision: D4258007
Pulled By: mkonicek
fbshipit-source-id: cff466d4710807d97fc6161f47bb974097b75261
Summary:
*First PR to React Native.*
After performing a clean install of macOS Sierra on my machine I tried to get RN set up again and noticed that the link provided for installing Java (required by Android Studio) pointed to the [wrong location](https://www.java.com/en/download/mac_download.jsp). After some time researching I found the right package required by Android Studio [here](http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html).
I tried looking for a more general link (as this points to the JDK version 8 and has a weird path: _jdk8-downloads-2133151.html_ - Sadly this was the best I could find.
I also looked through listed issues to try and find a previous attempt to fix this error but couldn't find any references, sorry if I missed anything.
**TL;DR:** JDK download link is incorrect, PR updates it to the correct one.
Closes https://github.com/facebook/react-native/pull/11201
Differential Revision: D4253304
Pulled By: hramos
fbshipit-source-id: be8ffe059bf60f5d7aa1876e5581b270187864c2
Summary:
I was running RN 0.31 on ArchLinux (kernel 4.7), and "react-native start"
was refusing to run on the default (and sometimes required, as I have
noticed) port. I tried executing the suggested lsof command, but that did not
work. Somewhere I found the lsof command I include in this commit, and that
worked (it was a node.js process). So I'm including it, since I found it
helpful.
Closes https://github.com/facebook/react-native/pull/9402
Reviewed By: lacker
Differential Revision: D4144400
Pulled By: hramos
fbshipit-source-id: 6203549455555efc59b7bab0a3ec23957d80b956
Summary:
This PR fixes#11096.
I don't know enough the ReactAndroid's source code so I don't know if this is correct but I hope it is.
In a recent commit (d4b8ae7a8a), the `dispatchUpdates` method now returns a boolean to dispatch or not the `onLayout` event. This works well but if the content is unchanged, the line `nativeViewHierarchyOptimizer.handleUpdateLayout(this);` is never called. I don't know if it was intended but it was this which introduces my issue. I called this again even if the content didn't change. This was the behaviour before 0.38 so I guess I didn't break anything.
**Test plan (required)**
I tested my pretty big app with this fix and every screen is ok.
Closes https://github.com/facebook/react-native/pull/11222
Differential Revision: D4252101
Pulled By: astreet
fbshipit-source-id: 551559234631ac37245a854d81ba568f0ddb02dd
Summary: Removes the `shouldThrowOnUnresolvedErrors` option, as now it is only ever `() => true`
Reviewed By: davidaurelio
Differential Revision: D4237711
fbshipit-source-id: 9460f0f0c50dc0d08d17cb7bdeb995825f7051f3
Summary:
Just some small changes that made the core easier for me to understand as I went through it.
**Test plan (required)**
$ cd react-native
# "Install globally" without using Sinopia :)
$ cp -r react-native-git-upgrade /usr/local/lib/node_modules/
$ cd ~
$ react-native init Zero29App --version=0.29.2
$ cd Zero29App
Made a small change in `MainApplication.java` to introduce a conflict with the new template.
$ git init && git add . && git commit -m "Initial commit"
$ react-native-git-upgrade
Worked, printed the conflicting file. Output: http://pastie.org/10972793
$ git reset --hard
$ react-native-git-upgrade --verbose
Worked, printed the conflicting file. Output: http://pastie.org/10972796
In both cases (with and without --verbose) the output of `git st` was http://pastie.org/10972795
Closes https://github.com/facebook/react-native/pull/11197
Differential Revision: D4251008
Pulled By: mkonicek
fbshipit-source-id: c5bbbeaf996cb5cb46cccc12fd1da7634cc23520
Summary:
This kills fastfs in favor of Jest's hasteFS. It gets rid of a ton of code, including the mocking code in ResolutionRequest which we don't need any more. Next step after this is to rewrite HasteMap, ModuleCache, Module/Package. We are getting closer to a nicer and faster world! :)
Here is what I did:
* Use Jest's HasteFS instead of fastfs. A fresh instance is received every time something changes on the FS.
* HasteFS is not shared with everything any more. Only one reference is kept in DependencyGraph and there are a few smaller functions that are passed around (getClosestPackage and dirExists). Note: `dirExists` now does fs access instead of an offline check. This sucks but stat calls aren't slow and aren't going to be a bottleneck in ResolutionRequest, I promise! When it is time to tackle a ResolutionRequest rewrite with jest-resolve, this will go away. "It gets worse before it gets better" :) The ModuleGraph equivalent does *not* do fs access and retains the previous way of doing things because we shouldn't do online fs access there.
* Add flow annotations to ResolutionRequest. This required a few tiny hacks for now because of ModuleGraph's duck typing. I'll get rid of this soon.
* Updated ModuleGraph to work with the new code, also created a mock HasteFS instance there.
* I fixed a few tiny mock issues for `fs` to make the tests work; I had to add one tiny little internal update to `dgraph._hasteFS._files` because the file watching in the tests isn't real. It is instrumented through some function calls, therefore the hasteFS instance doesn't get automatically updated. One way to solve this is to add `JestHasteMap.emit('change', …)` for testing but I didn't want to cut a Jest release just for that. #movefast
(Note: I will likely land this in 1.5 weeks from now after my vacation and I have yet to fully test all the product flows. Please give me feedback so I can make sure this is solid!)
Reviewed By: davidaurelio
Differential Revision: D4204082
fbshipit-source-id: d6dc9fcb77ac224df4554a59f0fce241c01b0512
Summary:
This change suppresses access checking during reflection which makes reflection faster by decreasing its overhead.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11204
Differential Revision: D4250790
Pulled By: astreet
fbshipit-source-id: 0ee2f40dcadccc695980fcae14fafe1050acb52f