Summary:
A bit late to the party, but upgraded, tests replaced, all green.
Also updated `pbxproj` so that we are testing against React 0.40 init result, not against something old.
To cherry-pick and land once ships.
Closes https://github.com/facebook/react-native/pull/11868
Differential Revision: D4411362
fbshipit-source-id: c485fd76114979d34a7e288bb70e1ecb9b3baf76
Summary:
Introduces a new mechanism to build source maps that allows us to use real mapping segments instead of just mapping line-by-line.
This mechanism is only used when building development bundles to improve the debugging experience in Chrome.
The new mechanism takes advantage of a new feature in babel-generator that exposes raw mapping objects. These raw mapping objects are converted to arrays with 2, 4, or 5 for the most compact representation possible.
We no longer generate a source map for the bundle that maps each line to itself in conjunction with configuring babel generator to retain lines.
Instead, we create a source map with a large mappings object produced from the mappings of each individual file in conjunction with a “carry over” – the number of preceding lines in the bundle.
The implementation makes a couple of assumptions that hold true for babel transform results, e.g. mappings being in the order of the generated code, and that a block of mappings always belongs to the same source file. In addition, the implementation avoids allocation of objects and strings at all costs. All calculations are purely numeric, and base64 vlq produces numeric ascii character codes. These are written to a preallocated buffer objects, which is turned to a string only at the end of the building process. This implementation is ~5x faster than using the source-map library.
In addition to providing development source maps that work better, we can now also produce individual high-quality source maps for production builds and combine them to an “index source map”. This approach is unfeasable for development source maps, because index source map consistently crash Chrome.
Better production source maps are useful to get precise information about source location and symbol names when symbolicating stack traces from crashes in production.
Reviewed By: jeanlauliac
Differential Revision: D4382290
fbshipit-source-id: 365a176fa142729d0a4cef43edeb81084361e54d
Summary:
We don't need to look for `thisDependency` as we already have it. Small improvement as I am working on other fixes.
Closes https://github.com/facebook/react-native/pull/11867
Differential Revision: D4411177
fbshipit-source-id: 1413eb5457cb4d7916ead90f438ffe158f644cad
Summary:
This is step one on merging the `rnpm` config with the `cli config`. The plan is to remove two sources of truth (rnpm package.json config and rn-cli Javascript config)
Rationale:
As of now, we have `rnpm` config, that used to live in the `local-cli/core/config/index.js` and the `rn-cli` config, living in `default.config.js` and `utils/Config.js`.
This PR moves all the things into one file, called `local-cli/core', simplifies things, enhances types (Config now has better types, added missing properties and fixed descriptions).
One notable addition is that users can now opt-in to override the commands that are loaded at the package level. Previously it was only possible to add a command by writing a plugin. Now, you can just tweak the `rn-cli.config.js`.
This is one of the several improvements I have on my roadmap, with better documentation for the CLI as well.
Closes https://github.com/facebook/react-native/pull/11564
Differential Revision: D4360095
fbshipit-source-id: feaec7c88df63e51cef1f9620c7eedeb738d3d00
Summary:
Currently, while running `react-native run-android` command, React Native's packager is launched, and there is not any way to disable the current behaviour. This is handled somehow on iOS by adding an environment variable `RCT_NO_LAUNCH_PACKAGER` (see #6180).
This is a cross-platform solution that adds the `--no-packager` option both to `run-ios` and `run-android`, which prevents the packager from being launched.
This was tested by building with and without the option, on both environments (Android and iOS) using the device and simulator, working as expected.
Closes https://github.com/facebook/react-native/pull/11735
Differential Revision: D4392170
Pulled By: ericvicenti
fbshipit-source-id: 1c31f109f18715b84cd5ab1b6d5fd758cd0a6efb
Summary:
As mkonicek suggested in [#9568](https://github.com/facebook/react-native/pull/9568#issuecomment-267600043) I did some cleanup
**Test plan (required)**
Only one functional change:
> Run `react-native run-android --deviceId`
Before it was beginning to build the app and then failing because of the missing device "true" :-)
Now it's showing a message and stopping the build:
```
❯ react-native run-android --deviceId
Starting JS server...
Parameter missing (device id)
```
Closes https://github.com/facebook/react-native/pull/11703
Differential Revision: D4376615
Pulled By: ericvicenti
fbshipit-source-id: 3c6e0f12220ab22539c7bc3d390367e02c96728a
Summary:
**Motivation**
New iOS project generation with react-native-cli should allow developers to build for Apple TV as well as iPhone/iPad.
**Test plan**
Added to `scripts/run-ci-e2e-tests.js` and `.travis.yml` to have the new tvOS target automatically built and tested in Travis CI.
Closes https://github.com/facebook/react-native/pull/11591
Differential Revision: D4375593
Pulled By: mkonicek
fbshipit-source-id: 4e241caa400a88e6b2f91416fa26b48ae01cb7b6
Summary:
Fixes#11605
HelloWorld refers to CSSLayout even thought master has moved on and the library is now called Yoga.
Closes https://github.com/facebook/react-native/pull/11606
Differential Revision: D4365469
fbshipit-source-id: e0eaac400449f0ba767bf98f3bd8e8185fb6fd12
Summary:
Running `master` (at 260d68bf8b) I noticed `react-native link` fails when there is no windows project due to a bug in the code that fetches windows project configs (introduced 445182c707).
There's a guard to return early if `csSolution` (the relative path of the windows solution) is null but it needs to be a line earlier, because `path.join` errors when passed a non-string.
Tested locally on a non-windows project, `react-native link` errored previously and now succeeds.
Closes https://github.com/facebook/react-native/pull/11590
Differential Revision: D4362419
fbshipit-source-id: b3b9f6784d8b1d1a7c53abe0ee421b1dc6048571
Summary:
Due to react-native-cli use yarn if yarn is available, we need to add yarn-error.log to .gitignore.
Closes https://github.com/facebook/react-native/pull/11583
Differential Revision: D4359507
fbshipit-source-id: 0c7582215a31e0d03dced138c8275225910713ee
Summary:
At the moment the run-android command from the react-native cli does run all available devices at once. However it would be extreme useful to have the option to choose only one specific device/simulator.
Therefore i've created a new flag for the command 'run-android': --deviceIdFromList 'deviceIdFromList' in order
to install and launch apps on a specific device/simulator from the command line.
'deviceIdFromList' is the id listed on the output of the command 'adb devices'.
I've tested my code with the following commands:
react-native run-android --deviceIdFromList "Not existing id"
react-native run-android --deviceIdFromList
react-native run-android --deviceIdFromList "id of a simulator"
react-native run-android --deviceIdFromList "id of a device"
Output:
) until platforms can better manager their own CLI and packager needs.
Linking 3rd party libraries should be supported first, because then I'd like to do a follow up PR with grabbou to identify how we can effectively move RNPM functionality out of react-native core and eventually housed in each external platform's repo. The goal would be working with cpojer and hopefully andrewimm to help keep external platform needs in their respective repos, for rnpm/packager _et al._ Seeing as this is a major discussion point, I've made this PR first. Making small steps towards this goal, seems to be the approved methodology from all.
Additionally, I have a merged PR that makes an excellent place for documenting the CLI when it advances, as preparatio
Closes https://github.com/facebook/react-native/pull/11282
Differential Revision: D4311391
fbshipit-source-id: be9a836344be4aed6c4732b0ce4947c2a16b6dad
Summary:
This is a simple one line change. When a red box is launching the editor, if `launchEditor.js` is aware of your editor it can also add a line number to open the file at. So if the stacktrace shows an error on like 56 in `ako.js` then it'll try`wstorm /Users/somelady/src/project/ako.js:56` instead of `wstorm /Users/somelady/src/project/ako.js`.
This adds PyCharm's command line launcher, which is named `charm`. There is existing logic to handle other JetBrains editors, so I just did a simple one line addition.
**Test plan (required)**
* Install PyCharm (if needed)
* Set environment variable `REACT_EDITOR` to `charm`
* Open PyCharm
* Add/replace the current `charm` command via `Tools -> Create Command-line launcher...` in PyCharm.
* Run a React Native project with an error in the source code.
* In the generated red box, click on one of the entries in the stack trace
* File should open in PyCharm at the correct line number.
Closes https://github.com/facebook/react-native/pull/11275
Differential Revision: D4295724
Pulled By: javache
fbshipit-source-id: 29dec525f76c2f0a3ee203cac67408eecc8ac6b6
Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary:
I missed this while doing the Yeoman wipeout.
Currently we just print:
Installing React...
Installing Jest...
This diff makes it print the output of those commands.
**Test Plan**
Published react-native to Sinopia, ran `react-native init MyApp`, saw the output:
Installing Jest...
⸨░░░░░░░░░░░░░░░⸩ ⠸ normalizeTree: ...
Reviewed By: bestander
Differential Revision: D4286640
fbshipit-source-id: e554f03a4729c2de85eba527f10f4b727de722e4
Summary:
This module is not actually used inside of React Native. Projects that use this,
can now depend on https://www.npmjs.com/package/signedsource
Reviewed By: yungsters
Differential Revision: D4272511
fbshipit-source-id: 93eb74aa4ccfa8ef8743de2cfa92b5403de91e0a
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:
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 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: Flow was updated in bf901d926e, need to update the config file for the template too.
Reviewed By: mkonicek
Differential Revision:
D4240152
Ninja: OSS tests only
fbshipit-source-id: c20704c43a5d603105125a0316b7926cdc7cd7fd
Summary:
The upgrading process based on Yeoman is a pain. For each file, Yeoman (or the brand new copyAndReplace solution a477aec) compares the newly generated content with the existing one and prompts the user if it differs, with very basic options: overwrite or skip.
I have digged into this problem and came with [rn-diff](https://github.com/ncuillery/rn-diff) (you may have read [this article](https://medium.com/ncuillery/easier-react-native-upgrades-with-rn-diff-5020b5c3de2d#.llvy2dym5)). This repository helps people to upgrade RN on their projects. An alternative upgrading process using `git apply` instead of Yeoman is described [here](https://github.com/ncuillery/rn-diff/blob/master/USAGE.md).
This PR is the integration of this process into the core. I got rid of the drawbacks mentioned in the link below in order to make it a clean, elegant, one-step operation.
This process is based on some Shell operations that:
- Generate the blank sources of both old and new versions
Closes https://github.com/facebook/react-native/pull/11110
Differential Revision: D4237107
Pulled By: mkonicek
fbshipit-source-id: 15e82e030b762415c925ccb2a62ddb354a6e18b9
Summary:
Instead of exposing a `getTransformOptionsModulePath` function in configurations, we can simply expose a `getTransformOptions` *function*. The necessity of exposing a path comes from the olden days, where we had a server listening on a socket, and a client, talking to that server.
Since that architectural gem no longer exists, we can use functions directly, rather than passing paths to modules around.
Reviewed By: cpojer
Differential Revision: D4233551
fbshipit-source-id: ec1acef8e6495a2f1fd0911a5613c144e8ffd7c3
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Warning about new Buffer when init
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#s
Closes https://github.com/facebook/react-native/pull/11153
Differential Revision: D4234591
fbshipit-source-id: a9373f3151de8a50c18342f45fb9684a5c7416a6
Andrew Imm
Mike Grabowski
David Aurelio
Jean Lauliac
joaogranado
Chris Hopman
Mark Oswald
dlowder-salesforce
Tomas Roos
Rob Hogan
Riku Ayanokoji
Steve Kellock
John Shelley
David Gröger
Martin Konicek
Jeff Morrison
Gant
Eric Palakovich Carr
Pieter De Baets
Jan Kassens
Tim Yung
Charles Dick
Nicolas Cuillery
Richard Evans
Lukas Piatkowski
Joel Sánchez
Christoph Pojer
yicheng
