Summary:
Fixes#19069
The --simulator option for the run-ios command now can take an optional
iOS version between parenthesis to further match the desired simulator.
This is useful if you have installed simulators for different iOS
versions and you want to run the app in an especific one. Example:
react-native run-ios --simulator "iPhone 6s (9.3)"
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
Updated tests for the findMatchingSimulator function to include test cases specifying iOS version, and tested on the command line in my app to make sure it has the expected behavior.
[CLI] [ENHANCEMENT] [{/runIOS/findMatchingSimulator.js}] - run-ios command with the --simulator option now allows specifying the iOS version to run an specific simulator if you have multiple versions of the simulator installed. Example: `react-native run-ios --simulator "iPhone 6s (9.3)"`.
Pull Request resolved: https://github.com/facebook/react-native/pull/19079
Differential Revision: D10432487
Pulled By: hramos
fbshipit-source-id: efa50d798b79d83bfe357ee17967a56c7c003bee
Summary:
This diff removes the `sinon` dependency from `metro` and `react-native-github`. It was only used in a handful of tests and having to learn and remember another mocking API just for these cases was not worth it IMO.
While doing the migration, most of the things that `sinon` provides can be done with `jest` in a very similar (and user friendly) way.
I've found, though, two small things that are more user friendly with `sinon`. I'm documenting them here because it may be worth adding them to jest:
With `sinon`:
```
stub.throws(new Error('foo'));
```
With `jest`:
```
mock.mockImplementation(() => {
throw new Error('foo');
});
```
Taking into account that `jest` has a `mockRejectedValue` method for mocks (to return a rejected promise) I don't see any reason why it does not have a `mockThrowError` method.
With `sinon`:
```
expect(mock1.calledBefore(mock2)).toBeTruthy();
```
With `jest`:
```
expect(mock1.mock.invocationCallOrder[0]).toBeLessThan(
mock2.mock.invocationCallOrder[0],
);
```
There's a community matcher that adds this matcher in `jest-extended`: https://github.com/jest-community/jest-extended#tohavebeencalledbefore, but we're not using `jest-extended` in `xplat/js`.
Reviewed By: jeanlauliac
Differential Revision: D10238331
fbshipit-source-id: 5441125b69596ad85bf8f56d203cfd20759bc358
Summary:
this is just a suggestion, but as the iPhone 6 is discontinued by Apple
and the new iPhone line will match the X version, it could be good to update the default simulator.
it could also be the iPhone 8, feel free to suggest other changes!
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/21148
Differential Revision: D9928120
Pulled By: hramos
fbshipit-source-id: 005faa3a8e00b67f98a778c92ecc01b064e14199
Summary:
With the new xcode command line tools (10.1 beta2), running `xcrun simctl list --json devices` seems to gives us a slightly different format than what we were expecting. More specifically, the `availability` key is changed to `isAvailable` and returns `'YES'` if the simulator is available:
Before:
```js
devices: {
'iOS 9.2': [
{
state: 'Shutdown',
availability: '(unavailable, runtime profile not found)',
name: 'iPhone 4s',
udid: 'B9B5E161-416B-43C4-A78F-729CB96CC8C6',
},
{
state: 'Shutdown',
availability: '(unavailable, runtime profile not found)',
name: 'iPhone 5',
udid: '1CCBBF8B-5773-4EA6-BD6F-C308C87A1ADB',
},
...
]
}
```
After:
```js
devices: {
'iOS 12.1': [
{
state: 'Shutdown',
isAvailable: 'YES',
name: 'iPhone 6s',
udid: 'D0F29BE7-CC3C-4976-888D-C739B4F50508',
},
{
state: 'Shutdown',
isAvailable: 'YES',
name: 'iPhone 6',
udid: 'BA0D93BD-07E6-4182-9B0A-F60A2474139C',
},
...
]
}
```
Without this fix, `npm run ios` is not able to launch the simulator correctly and returns the following error:
```
Could not find iPhone 6 simulator
Error: Could not find iPhone 6 simulator
at resolve (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:148:13)
at new Promise (<anonymous>)
at runOnSimulator (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:134:10)
at Object.runIOS [as func] (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:106:12)
at Promise.resolve.then (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/cliEntry.js:117:22)
```
Pull Request resolved: https://github.com/facebook/react-native/pull/21557
Differential Revision: D10248115
Pulled By: TheSavior
fbshipit-source-id: 37197bbf828e4a6e254270d46411a6716a91afe3
Summary: This makes the Metro config type readonly, only a couple of things inside Metro needed to be tweaked :)
Reviewed By: mjesun
Differential Revision: D10028083
fbshipit-source-id: 15f5d957a8ee7384d6156c973639d86240fd251f
Summary:
Due to Kureev's cleanup in https://github.com/facebook/react-native/commit/c4a66a89a28152cd4b81e2b0f80ab3aac34d6872 some arguments are no longer properly passed to metro, but just the default values. This broke the `--projectRoot` and `--watchFolders` arguments used by storybook to change the bundle entrypoint.
This PR simply fixes the regression by assigning these values from argv instead of reading config defaults.
Related: the undocumented `REACT_NATIVE_APP_ROOT` env var is broken, not sure for how long, but I can fix it as a part of this PR or make a new one.
Pull Request resolved: https://github.com/facebook/react-native/pull/21165
Differential Revision: D9929642
Pulled By: hramos
fbshipit-source-id: 00485a0429bd4301de03e5cb455e928878c4ba8f
Summary:
@public
The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow.
This fixes https://github.com/facebook/metro/issues/253
Reviewed By: mjesun
Differential Revision: D9915500
fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Summary:
This PR gives RNPM the ability to look for plugins in `scoped` modules.
The regexes for finding RNPM plugins will match these hypothetical examples:
* `rnpm-plugin-foo`
* `org/rnpm-plugin-foo`
The regexes for finding React Native plugins will match these hypothetical examples:
* `react-native-foo`
* `org/react-native-foo`
* `The controller you requested could not be found./module` (will be useful in the slimmening)
* `The controller you requested could not be found./module`
RNPM plugins will be able to benefit from this immediately, but React Native plugins will run into this Metro issue currently:
https://github.com/facebook/metro/issues/241
Pull Request resolved: https://github.com/facebook/react-native/pull/21082
Differential Revision: D9809094
Pulled By: hramos
fbshipit-source-id: 4b0694ad4119b37dd5664af52c48e48ebe4d7404
Summary:
This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest.
For example, React Native Dom would have an entry like:
```json
{
"rnpm": {
"haste": {
"providesModuleNodeModules": [
"react-native-dom"
],
"platforms": [
"dom"
]
}
}
}
```
Support for more keys (path blacklists perhaps?) could be added in the future.
This succeeds #20662, as per a discussion I had with matthargett.
I've got an open discussion over here as well: https://github.com/react-native-community/discussions-and-proposals/issues/21
Pull Request resolved: https://github.com/facebook/react-native/pull/20825
Differential Revision: D9596429
Pulled By: hramos
fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This diff fixes a couple of edge cases that caused Metro to keep the process running when there were some specific errors (specially around the `dependencies` command and the transformer path).
Reviewed By: jrwats
Differential Revision: D9551834
fbshipit-source-id: 959cefcec9e2687dff89c94a871ae74c50d2dd77
Summary: D9070810 introduced a breaking change, making the `--transformer` CLI argument able to override the generic transformer instead of `babelTransformer`. Since we still have some scripts that assume `--transformer` is being used for overriding the babelTransformer path, we cannot do this breaking change yet, so this diff reverts the CLI handling to the old behaviour.
Reviewed By: jrwats
Differential Revision: D9550157
fbshipit-source-id: 8b4e26fcb5bca6e4b2f63b1e1a014bce23a31452
Summary:
This diff exposes the new more generic way to configure transformers in `Metro` via the config parameter `transformerPath`.
The new generic transformers can be used to transform any kind of file, since they don't call any JS-specific method and their API is generic. They only need to implement a single `transform` method:
```
async function transform(
absolutePath: string,
relativePath: string,
fileContents: Buffer,
options: TransformOptions, // very soon these will be configurable
): Promise<{
output: Array<mixed>,
dependencies: Array<{
name: string,
data: mixed, // very soon
}>,
}> {
// ...
}
```
Metro already had a `transformModulePath` config param, which was used to configure how babel was called in order to generate the AST. In order to avoid confusion, but keep the current open source transformer worker, I've renamed this param to `babelTransformerPath`. We can add a layer of compatibility and detect old config params in order to show a deprecation warning.
Reviewed By: pvdz
Differential Revision: D9070810
fbshipit-source-id: aebde879736026c09537f5d236eae24c06640abf
Summary:
This diff exposes the new more generic way to configure transformers in `Metro` via the config parameter `transformerPath`.
The new generic transformers can be used to transform any kind of file, since they don't call any JS-specific method and their API is generic. They only need to implement a single `transform` method:
```
async function transform(
absolutePath: string,
relativePath: string,
fileContents: Buffer,
options: TransformOptions, // very soon these will be configurable
): Promise<{
output: Array<mixed>,
dependencies: Array<{
name: string,
data: mixed, // very soon
}>,
}> {
// ...
}
```
Metro already had a `transformModulePath` config param, which was used to configure how babel was called in order to generate the AST. In order to avoid confusion, but keep the current open source transformer worker, I've renamed this param to `babelTransformerPath`. We can add a layer of compatibility and detect old config params in order to show a deprecation warning.
Reviewed By: pvdz
Differential Revision: D9070810
fbshipit-source-id: aebde879736026c09537f5d236eae24c06640abf
Summary:
Bump android gradle plugin to 3.1.4. We have been stay to 2.x too long. With 3.x we can have instant run and great performance and new features brought by google.
Also thanks to CFKevinRef great pr to make this possible.
pass all current ci. I have also tested RNTester release version works without crash.
https://github.com/facebook/react-native/pull/17967.
[GENERAL] [ANDROID] [FEATURE] - bump android gradle to 3.1.4
Pull Request resolved: https://github.com/facebook/react-native/pull/20767
Differential Revision: D9437576
Pulled By: hramos
fbshipit-source-id: 6084056a1390582a75a879918f2538b0480f6299
Summary:
Fixes#20769
Release notes
--------------
[CLI] [BUGFIX] [local-cli/server/checkNodeVersion.js] - Disable auto-formatting in `local-cli/server/checkNodeVersion.js` since it introduces ES6 and ES7 syntax (trailing comma in argument list) which in turn makes ES5 engines crash with a `SyntaxError`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20779
Differential Revision: D9468346
Pulled By: hramos
fbshipit-source-id: 24761a377a5fd104e11ed6b6e86da15e96a0e38b
Summary:
@public
This diff fixes the `projectRoot` calculation on React Native when the app does not have a config file. This should fix the issues reported in https://github.com/facebook/react-native/issues/20712
Reviewed By: hramos
Differential Revision: D9444982
fbshipit-source-id: 4cb41fa5224d2addf92976cc119e49dea6a6346b
Summary:
Commit 79e498b7fb claims that "--terminal" has been added as an argument to the "run-android" script which it hasn't. Instead it adds a new environment variable "process.env.REACT_TERMINAL" which seems to be undocumented and nowhere else in the repository.
This commit now allows Linux and OSX users to specify their custom terminal :
react-native run-android --terminal=x-terminal-emulator
Additionally the metro bundler child process "detached" option has been set to false if no terminal has been specified on Linux which fixes an issue where the packager would be running in the background and would have to manually be closed by finding the process.
Fixes#18122
Pull Request resolved: https://github.com/facebook/react-native/pull/20584
Differential Revision: D9234990
Pulled By: hramos
fbshipit-source-id: 60e4cc57b2790c419d5a4f9027add04313ddf6f8
Summary:
The `--reset-cache` argument was not working correctly with the `bundle` command. This ensures the `--reset-cache` arg is passed to metro.
Fixes#20703
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/20706
Differential Revision: D9400548
Pulled By: hramos
fbshipit-source-id: 2c7ed0226cfcdffa8cc77506500c314552baef3f
Summary:
React Native overrides the `metro.config.js` settings for, e.g., `hasteImplModulePath`, which prevents us from adding a `metro.config.js` file to the repo for `react-native-windows` to allow us to resolve Haste modules at the top-level of the repo. This change ensures that if a user has a `metro.config.js` file, those settings are not overwritten by React Native.
Pull Request resolved: https://github.com/facebook/react-native/pull/20705
Differential Revision: D9390146
Pulled By: hramos
fbshipit-source-id: 5ccc137490410ace72d7b0e68f2bafcbb233c59f
Summary:
@public
While debugging a RN 0.57 blocking issue, we found that the `--reset-cache` cli arg is not being passed to Metro (more info: https://github.com/facebook/react-native/issues/20567#issuecomment-412513942).
This diff fixes this issue
Reviewed By: mjesun
Differential Revision: D9295634
fbshipit-source-id: a53ec7abff2b7e684a1fd88c3b53ff0b54a1c3c4
Summary:
The `hmrEnabled` flag was not passed to the metro runServer config which caused HMR to be broken.
Pull Request resolved: https://github.com/facebook/react-native/pull/20605
Differential Revision: D9272070
Pulled By: hramos
fbshipit-source-id: 3765031d9e7806be11781fba92663ce7c4ff2ffb
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:
Just change gradle.properties version number to change gradle version is not the right way. Because sometimes the gradlew and gradlew.bat or even the jar need to be updated too.
I also add the wrapper task to `build.gradle`, so next time, we just need to change the version number and execute `gradlew wrapper`.
pass all current ci.
none
[GENERAL] [BUGFIX] [Android] - fix gradle wrapper issue
Pull Request resolved: https://github.com/facebook/react-native/pull/19976
Differential Revision: D9229655
Pulled By: hramos
fbshipit-source-id: 63d1ddea6174f87778612a4e6711baac5787b0f8
Summary: The controller you requested could not be found.
Reviewed By: pakoito
Differential Revision: D9174188
fbshipit-source-id: 4ec9ef5b6f802964a83b6bc0bd29db7f47b37c21
Summary:
Currently, when the cli tries to determine the package name, it accidentally trims out the entire package name. This makes it appear to the rest of the program as if `react-native link The controller you requested could not be found./my-package` was just `react-native link`. This adds a little regex to prevent that from happening, so that scopes can be passed as parts of packages.
Fixes#18766
Pull Request resolved: https://github.com/facebook/react-native/pull/19828
Differential Revision: D8704742
Pulled By: hramos
fbshipit-source-id: d8183f9b55e8656b8a0acae842e1361a1f428102
Summary:
Regarding [Add devDependenices support for templates](https://github.com/facebook/react-native/commit/c4ab03a18e75e6ed55444b5d86f3ceee435b9a78).
Once a project is created using the custom template command with devDependencies inside, the devDependenices.json file is also copied to the new projects directory.
By adding this to the ignore paths we stop the devDependenices being copied into the new projects directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/20542
Differential Revision: D9182795
Pulled By: hramos
fbshipit-source-id: 543c8ca67612a981c22fc83c8d54a25ddc0ca5fc
Summary:
Follow up to a9792ac4c8 and #20516
This makes sure new projects typecheck properly since RN can use this syntax.
Pull Request resolved: https://github.com/facebook/react-native/pull/20517
Differential Revision: D9169268
Pulled By: TheSavior
fbshipit-source-id: f2b08598bdc6979931e987c9a275d75f08751754
Summary:
Instead of overriding the config at the end we now do it right after applying default
config and before the user config is applied.
Reviewed By: rafeca
Differential Revision: D9131758
fbshipit-source-id: 15e575fc11a781187f3ee2fa7cf81c227cf6a088
Summary:
We ignore some `metro` flowtypes, which made `flow check` fail on `metro-config`. I now also added the `metro` stubs needed by `metro-config` to make `flow check` pass.
Closes https://github.com/facebook/react-native/issues/20431
Pull Request resolved: https://github.com/facebook/react-native/pull/20429
Reviewed By: hramos
Differential Revision: D9036903
Pulled By: CompuIves
fbshipit-source-id: 6e348e929b7c36520787bb860f5a18aa588455c3
Summary:
This adds `react-native-dom` to `hasteImpl.js` because it's not currently possible to configure it from an out of tree platform. Also adds the relevant `providesModuleNodeModules` and `platforms` values to the default RN CLI config. This should hopefully be able to be removed once better support for out of tree platforms is implemented.
Pull Request resolved: https://github.com/facebook/react-native/pull/20393
Differential Revision: D9007186
Pulled By: hramos
fbshipit-source-id: 67077860dc1fb191d80300fb980599ed76d5f91c
Summary: Change the internals of Metro to use the new configuration instead of `ServerOptions`.
Reviewed By: rafeca
Differential Revision: D8734685
fbshipit-source-id: 1215f799419fcaa0e5fb7814683da1cbba96795c
Summary: Change the public react-native CLI to use the new configuration of Metro.
Reviewed By: rafeca
Differential Revision: D8801217
fbshipit-source-id: 112e4812b430ebee1ed41489f803b90c182ccdb4
Summary: In this diff I change the internal react-native cli to use our new configuration. Another change here is that Metro starts using the new configuration already as its entry points (like `metro#runMetro`).
Reviewed By: rafeca
Differential Revision: D8728612
fbshipit-source-id: 9f43dee31ebaccd35cf6274d5c4dec0a227a6eec
