Summary: Because we don't want to test for `empty-module.ios.js`, etc. We know the module is supposed to be here. This simpler version makes it easier for me to switch the rest of the `loadAsFile` callsites to the "candidates" system to the "candidates" system.
Reviewed By: davidaurelio
Differential Revision: D5103816
fbshipit-source-id: 7e7d9be27573a1f33d562aeb850759e073fbc72f
Summary: For the Buck integration (work-in-progress), we want to add the ability to do some custom preprocessing similar to the packager server. The signature is different so I prefer to have a separate function for that. Also we don't need the transform options right now, I suggest we don't add them for now and add them later if necessary.
Reviewed By: davidaurelio
Differential Revision: D5094632
fbshipit-source-id: 1775ddef90b331deabc5be3e57a67436bce06c82
Summary:
Not sure if that is how it's supposed to read but tried to correct it
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/14085
Differential Revision: D5103609
Pulled By: javache
fbshipit-source-id: 483661b149761cf6d27fb43990272312d781cc6f
Summary:
Close#13500
I've been bothered by this issue for quite a long time, finally get some time to look into it.
I find the root cause is that after a prop of the native driven node is assigned with a plain value, if you set it to be a `Animated.Value` again , it will take no effect any more, so I just keep it be a `Animated.Value` all the time.
`value --> Animated.Value (✅) --> value (✅) --> Animated.Value (❌)`
ping janicduplessis
Closes https://github.com/facebook/react-native/pull/13885
Differential Revision: D5077094
Pulled By: javache
fbshipit-source-id: 3fb5d8196d94101200394b2bb2b95c776fb1d2f3
Summary:
1, Change bottom to be based� on height of parent.
2, Respect margin value when layout with right/bottom.
Closes https://github.com/facebook/yoga/pull/552
Differential Revision: D5102090
Pulled By: emilsjolander
fbshipit-source-id: dca291413ffc2027d7628f4c8b8eeeb0b4823bc2
Summary:
There are two ways to get started with React Native: using CRNA, or by building native code. The latter requires a set of dependencies that also need to be installed even by people who use CRNA if they have ejected.
There needs to be a clear demarcation between the two approaches as well as clear instructions as to which steps are of interest to CRNA using parties or people adding RN to an existing app.
Separating the two approaches entirely by using tabs can achieve this purpose.
Built and tested the website on Chrome on macOS. Have not yet tested other browsers or OS configurations.
This is a work in progress. Feedback is appreciated. I am not yet happy with the different sets of tabs/buttons, for example.
Closes https://github.com/facebook/react-native/pull/14005
Differential Revision: D5096426
Pulled By: hramos
fbshipit-source-id: cdbf19b148ec87f2f2dfdced345084d0bbff4c26
Summary:
'source' is not available in all shells on Linux (e.g. dash) and will silently fail launchPackager.command when called from runAndroid.js.
react-native run-android will thus silently fail to start the developement server ('JS server').
What existing problem does the pull request solve?
When running "react-native run-android" on the below reasonably vanilla Ubuntu system, the development server / packager script fails to start. It fails because sh defaults to dash (not bash) which doesn't know the command 'source'. dot (.) does the same as source, but works in all shells.
$ uname -a
Linux dallas 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ which sh
/bin/sh
$ readlink -f /bin/sh
/bin/dash
react-native-cli: 2.0.1
react-native: 0.44.0
$ ps aux | grep packager
(nothing)
ps aux | grep packager
sh /home/xxx/code/react-native/AwesomeProject/node_modules/react-native/packager/launchPackager.command
node /home/xxx/code/react-native/AwesomeProject/node_modules/react-native/packager/../local-cli/cli.js start
Closes https://github.com/facebook/react-native/pull/14040
Differential Revision: D5096298
Pulled By: hramos
fbshipit-source-id: 88466e802c9bc4358840391edb37e153f0a6b1f7
Summary: Changes the `sourceMappingURL` comment from multi line to single line.
Reviewed By: johnislarry
Differential Revision: D5094791
fbshipit-source-id: f8fa2efd7f173290cac985564c06b4a118a80aae
Summary: separates modules of the dependency graph from the generated require calls to kick of the app. This is required to make RAM bundle generation work properly'
Reviewed By: jeanlauliac
Differential Revision: D5094635
fbshipit-source-id: fca69a3e2d9b030cdc4d4405c2b5e795b0d55f87
Summary:
There was an issue that sometimes sticky headers would stop moving when re-rendering because we did not reattach events properly. This makes sure that we always detach and reatach on rerender in case the scroll view ref changes.
**Test plan**
Tested that this fixes issues with sticky headers we discovered when updating Expo to RN 0.44.
Closes https://github.com/facebook/react-native/pull/14012
Differential Revision: D5094418
Pulled By: javache
fbshipit-source-id: a56050ae786712e8a3de2a6e3b4e8749a2fde86e
Summary: Releases the dependency map of modules after running the factory in release mode in order to save memory.
Reviewed By: cpojer
Differential Revision: D5086693
fbshipit-source-id: 68c57a2f98182ed1a732e1336e6d4fe5ce27abc3
Summary: RN configuration allows to specify a post-minify hook. This wasn’t called in the new Buck integration so far. Added here.
Reviewed By: cpojer
Differential Revision: D5087325
fbshipit-source-id: 74b58bd3a203716d8f01b5d7ba552b6ad1b575ce
Summary: Internally we use `multipart/form-data` to upload transformed files to the global cache, using the keys as file names. Unfortunately the server would read that and consider only the basename as the key, not the full path. So we wouldn't store the data under the right key. This is definitely a bug in the way upload is implemented: we should transmit the keys separately. But, this changeset offers a quick mitigation by avoiding slashes in the key, so that the whole key is a valid base file name.
Reviewed By: davidaurelio
Differential Revision: D5087780
fbshipit-source-id: 9e4a698c1f57c4c3b91b56b43eef82c1c7dd862b
Summary:
Make more views collapse on Android by designating FLEX_BASIS, FLEX_GROW and FLEX_SHRINK as "layout-only" props.
Relies on existing layout tests.
See Issue #13622
Closes https://github.com/facebook/react-native/pull/13868
Reviewed By: astreet
Differential Revision: D5035864
Pulled By: javache
fbshipit-source-id: d2c9e0b33b07e51b19afc383ef913ac41b70415c
Summary: Moves stack trace formatting logic into its own class to facilitate reusage from custom exception managers.
Reviewed By: javache
Differential Revision: D5086336
fbshipit-source-id: f434a1621c599c5c49991b3bfe5f66d05f84b5c9
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
Currently no subspecs are running on CI which causes us to find bugs in the podspec from time to time we upgrade master.
In order to highlight errors for podspecs users when changes happen we should make sure to run all subspecs even though it might take a bit longer when running the CI
Closes https://github.com/facebook/react-native/pull/14019
Differential Revision: D5079230
Pulled By: javache
fbshipit-source-id: 7b3b5dba5ba147b1fc24e79299ed260f9fc6231b
Summary: Better to have *some* Flow coverage (I'd like 100% of packager covered from when we split it apart) than none.
Reviewed By: davidaurelio
Differential Revision: D5077757
fbshipit-source-id: b23169b3edf2bd3eb0e8a399d099151aa705b198
Summary:
It was hard to type the resolution main algo, I had to put type annotations explicitely everywhere, otherwise Flow would get in some kind of loop and do weird errors. I think it's because the algo is recursive and Flow tries to infer types too deeply because of the generics.
Anyway, apart from that it's good to get this extra type security in the few other places. We require Node v4 minimum, that according to the internets supports the `class` syntax without transform, and I verified that inheriting from `Map` actually works as expected.
Reviewed By: davidaurelio
Differential Revision: D5078023
fbshipit-source-id: 05dfc4acf5b07cdda8a7b36ec9cba216d1810643
Summary: Adds flow to `local-cli/bundle/output/meta.js`, and makes some changes to avoid errors.
Reviewed By: cpojer
Differential Revision: D5077563
fbshipit-source-id: bafb9e6705319f6f2e8ae1c820667ad343191b3c
Summary: Or, a case in point that Flow doesn't saves us from all the ills. I think it didn't complain because `MapWithDefaults` doesn't have proper typing. I'll deal with that separately.
Reviewed By: davidaurelio
Differential Revision: D5077707
fbshipit-source-id: c43623c5046d2dea9964685a44ad4877d060232e
Summary:
After examining how React Native sets up `process.env.NODE_ENV` using `global.__DEV__` from `prelude_dev.js` or `prelude.js` by treating them like polyfills I decided to use the same approach for environment variables. I setup my own rn-project.config.js file like so:
```
const blacklist = require('react-native/packager/blacklist');
const pathJoin = require('path').join;
module.exports = {
getBlacklistRE: function() {
return blacklist([/build\/.*/, /app\/assets\/webpack.*/]);
},
polyfillModuleNames: [pathJoin(__dirname, 'globals.js')]
};
```
I ran the packaging server using:
`react-native start --config=config/react-native/rn-project.config.js --reset-cache`
I expected my polyfillModuleNames to be passed into the Packager properly and be handled the same way the built-in polyfills worked. Unfortunately I noticed the Packager wasn't actually getting `opt.polyfillModuleNames`. Digging into the code a bit, it seems the local-cli wasn't passing the polyfillModuleNames from the config.
There are no specs for runServer.js but this change can be tested by using a config that contains polyfillModuleNames. Sample config and run command provided above simple `global.js` provided below:
```
global.process = global.process ? global.process : {};
global.process.env = global.process.env ? global.process.env : {};
global.process.env['PROJECT_ENV'] = 'staging';
```
Closes https://github.com/facebook/react-native/pull/13725
Differential Revision: D5077615
Pulled By: jeanlauliac
fbshipit-source-id: f66a8a8bda2702cd9a4e5b92f5335f43ab2f9089
Summary: I'd like to start typing the front-end so that it's easier to track adding new options, etc.
Reviewed By: davidaurelio
Differential Revision: D5069868
fbshipit-source-id: 9a18dca52efd486ca18f17d0ec434a5ec1c1649c
Kevin Gozali
Jean Lauliac
Christoph Pojer
Brian Kabiro
Jean Regisser
Neo
Aaron Chiu
yihuang
Pieter De Baets
Hector Ramos
Sebastian Bargmann
David Aurelio
Valentin Shergin
Emil Sjolander
Janic Duplessis
Alexey Lang
Alex Kotliarskyi
Gabe Levi
Greg Herlihy
Andrew Y. Chen
Ashok Menon
Tomas Roos
Kathy Gray
Georgiy Kassabli
eacaps
