Summary:
This should resolve the following npm deprecation warning:
```
WARN deprecated node-uuid@1.4.7: Use uuid module instead
```
Existing tests should cover this already.
Closes https://github.com/facebook/react-native/pull/13194
Differential Revision: D4796723
Pulled By: javache
fbshipit-source-id: 2783f5d04c696b887de2ab2d32805e4661484a83
Summary:
> Explain the **motivation** for making this change. What existing problem does the pull request solve?
Of the three dependencies I have that rely on `glob`, react-native is the only one not on 7.x. If react-native can upgrade, then npm can deduplicate the glob dependency.
```console
$ npm ls glob
├─┬ eslint@3.13.1
│ └── glob@7.1.1
├─┬ jest@18.1.0
│ └─┬ jest-cli@18.1.0
│ └─┬ istanbul-api@1.1.0
│ ├─┬ fileset@2.0.3
│ │ └── glob@7.1.1
│ ├─┬ istanbul-lib-report@1.0.0-alpha.3
│ │ └─┬ rimraf@2.5.4
│ │ └── glob@7.1.1
│ └─┬ istanbul-lib-source-maps@1.1.0
│ └─┬ rimraf@2.5.4
│ └── glob@7.1.1
└─┬ react-native@0.39.2
├── glob@5.0.15
└─┬ rimraf@2.5.4
└── glob@7.1.1
```
**Test plan (required)**
> Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull req
Closes https://github.com/facebook/react-native/pull/11893
Differential Revision: D4796721
Pulled By: javache
fbshipit-source-id: 6e7424dd731329f982c2f6c05b40dec8febf2e57
Summary:
fs-extra's first stable release is out since 1 of November.
I think its time to upgrade to 1.0.0. We've been running 1.0.0 locally and is having no problems with it.
**Test plan (required)**
Walked through the commits from 0.30 to 1.0.0 and no breaking changes has been made to the repository. https://github.com/jprichardson/node-fs-extra/compare/1.0.0...1.x
Closes https://github.com/facebook/react-native/pull/11542
Reviewed By: zertosh
Differential Revision: D4444576
Pulled By: hramos
fbshipit-source-id: 520311af8dc0911c026c08bdb74bec6572e7e17f
Summary:
Moves stack trace symbolication to a worker process.
The worker process is spawned laziliy, and is treated as an exclusive resource (requests are queued).
This helps keeping the server process responsive when symbolicating.
Reviewed By: cpojer
Differential Revision: D4602722
fbshipit-source-id: 5da97e53afd9a1ab981c5ba4b02a7d1d869dee71
Summary: Renaming since a file with the same name as a package confuses packager
Reviewed By: cpojer
Differential Revision: D4613215
fbshipit-source-id: 5cfae71d0bb1eef2675689b37a9b42596d25678d
Summary:
Created a containerized environment to run unit and integration tests for both javascript and android as well as a Jenkinsfile using the new 2.0 Pipeline syntax for integration into a Jenkins CI cluster.
Here is a quick summary of the changes:
* The android image is built from two separate dockerfiles. There is a base image that handles the heavy lifting of dependencies that are infrequently changed while the secondary image extends the base and allows for much quicker incremental builds on code updates.
* The javascript image is simple and is relatively quick to build, therefore there is no base image for any react specific javascript dependencies and it is all packaged in a single docker image.
* A new `scripts/docker` has been created including some javascript files and shell scripts to aid in the running of the tests
* The instrumentation test runner script can be passed various flags to control which tests run since the entire suite takes a significant amount of time to run synchronously
* Jen
Closes https://github.com/facebook/react-native/pull/11902
Differential Revision: D4609238
Pulled By: ericvicenti
fbshipit-source-id: a317f3ac3be898180b009254a9604ca7d579a8b9
Summary:
The first time I tried to commit this changeset, it was causing many new packages to be installed, because the dependency would depend on newer versions that what we have installed. So, I had made a diff so upgrade all the babel packages. Unfortunately this caused some problem as the newer versions of Babel are more strict on some syntaxes. Of course, these have to be addressed, but I don't want this changeset to be coupled with Babel upgrades and the issues that arise from it.
So instead, I decided to install the slightly older version of the async-to-generator module. At first I tried with just doing:
yarn add babel-plugin-transform-async-to-generator@6.16.0
But, `yarn` is stubborn: because this module depends on a caret version of `babel-helper-remap-async-to-generator`, it installs the very last version of it, that itself needs more recent versions of other Babel modules. So, instead, I add to install a slightly older version of the dependency manually, then then the plugin:
yarn add babel-helper-remap-async-to-generator@6.16.0
yarn add babel-plugin-transform-async-to-generator@6.16.0
This allows us to have a `yarn.lock` with only a minimal amount of changes, and uncouple this change from any Babel upgrades. Because we only have a few new modules, the `node_modules` folder also stays the same, 133M, and it gives us confidence this will not cause significant startup time regressions.
Reviewed By: cpojer
Differential Revision: D4578733
fbshipit-source-id: deb0f720b895b7196aaf432adec3e56f18663940
Summary:
allow-large-files
By using async/await the code is (1) less nested, (2) more compact and (3) more robust (no exceptions running away, and much less risks of forgetting to call the callback/resolve, or mistakenly calling it twice). I now tend to think we could switch to it for all the callsites that are not in a perf-critical path.
I switched from 'request' to 'node-fetch' because 'request' has an annoying callback with 2 arguments. So it's simpler to use an interface that's (1) already returning a Promise and (2) that is becoming standard.
This changeset was a way for me to start experiment with introducing async/await in packager codebase, and it looks pretty good so far.
Reviewed By: cpojer
Differential Revision: D4559167
fbshipit-source-id: 89a328c5766c2ba890e9d0e67a81a38dac6cfc73
Summary:
Syncs the latest changes from the React GitHub repo and takes a dependency on React 16 alpha.
I had to hide the type checker stuff behind `__DEV__` because they now throw in production.
Also disabled flow for findNodeHandle for now since we have some further clean up to do.
Reviewed By: spicyj
Differential Revision: D4526535
fbshipit-source-id: af5d282e75afbb293560b62fc72657461c24bdd1
Summary:
We should unmock React just because we do that elsewhere and tests work better
that way. I was trying to get React tests working in this repo but because
we do so many special things in the React Core repo I gave up.
These test run in the React Core repo already.
Reviewed By: spicyj, bvaughn
Differential Revision: D4541126
fbshipit-source-id: ffbb1b76aac910a976222db91b80b8839fcecc60
Summary:
This downloads, uncompresses, and configures folly and its
dependencies: boost, double-conversion, and glog.
Reviewed By: bestander
Differential Revision: D4434066
fbshipit-source-id: 8f9d18448ef139e450a8c45a64d6a066d731ac8f
Summary:
We stopped using Yeoman in https://github.com/facebook/react-native/pull/10786
I almost forgot to remove the now-unused dependency :)
**Test Plan**
- Published react-native to Sinopia
- Ran `react-native init MyApp`
- The app was generated correctly
- The app's node_modules folder doesn't contain Yeoman
Reviewed By: cpojer
Differential Revision: D4291619
fbshipit-source-id: 44c1ef8035fa2d8c40d4e8c505207245e1a95d3c
Summary:
This removes support for `require('image!…')`, which has been deprecated for a long time.
It is still possible to use images that are already bundled by the native app using the `nativeImageSource` module.
Check http://facebook.github.io/react-native/docs/images.html for detailed documentation.
Reviewed By: matryoshcow
Differential Revision: D4231208
fbshipit-source-id: 05ec4c1ca0fabdc3fbb652f8ad1acdf240a67955
Summary:
This is the manually imported version of https://github.com/facebook/react-native/pull/10786
This was mostly straigthforward by replacing the local-cli folder with the version I had in my local git checkout,
plus a few other files I listed with git diff --name-only.
Reviewed By: hramos
Differential Revision: D4201118
fbshipit-source-id: 4d0fb54b0edda9de1abba427958e420fd2ac105c
Summary:
* `module-deps` isn't unused anywhere - though it once was part of the packager.
* `jstransform` is used in `/website`, but that has its own `package.json` - which is meant to be installed when you're going to push a site update (see the README).
* `JSONStream`,`duplexer`, `opener` and `split` are used internally (that's why they're devDeps).
Reviewed By: davidaurelio
Differential Revision: D4147609
fbshipit-source-id: 75c5f3568a55c49cd2802165cd1f23aa84c07943
Summary:
This diff updates `lodash` so that it's optimally deduped, resulting in:
* reducing the packager's load time by ~300-400ms.
* reduces the size of `node_modules` from ~225MB to ~148MB.
* reduces the time to do a clean `yarn install` from 35s to 18s.
Lots of dependencies (including every `babel-*`) use `lodash@4`, by having `lodash@3` as a root dependency, each package had to have it's own copy of `lodash@4`. Now, there's only one.
The uses of `lodash` in RN are restricted to the CLI/packager, and the uses are pretty basic. The breaking APIs don't really seem to affect us https://github.com/lodash/lodash/wiki/Changelog#v400.
Reviewed By: bestander
Differential Revision: D4124836
fbshipit-source-id: 0849c385fcafe10b463e684fea47be6775982386
Summary: Modified `node-haste` implementation to use the much faster `jest-haste-map` under the hood. The underlying `fastfs` now gets passed the entire file list from the `jest-haste-map` rather than crawl the filesystem.
Reviewed By: cpojer
Differential Revision: D3724387
fbshipit-source-id: 447d58ea0edf283662ec23d1e2deee992cf8d240
Summary: The newer versions of `source-map` fixed some bugs related to decoding mappings.
Reviewed By: bestander
Differential Revision: D3923727
fbshipit-source-id: cc1c87bbadeb128316965823d81ef5ca46a6845c
Summary:
**Motivation**
This is originally a follow up of PR #6327 by dewe and jeremyong
And mkonicek indicated this should split into a separate PR.
Now philikon takes over #6327 as #6961
**Test Plan:**
According to #6961 and #6889
Load WebSocketExample in UIExplorer app and start websocket test server script and test sending binary data on both iOS and Android
Closes https://github.com/facebook/react-native/pull/6937
Reviewed By: javache
Differential Revision: D3669596
Pulled By: mkonicek
fbshipit-source-id: 342e29eb34de882bcbd9f297aab71dd6bb236748
Summary:
(I changed a ton from when I previously submitted this PR so please take another look if you already did.)
PROBLEM: the no-longer-maintained `esprima-fb` parser does not support class properties, leading our website docgen to die if we use class properties, which we're gonna do real soon now
SOLUTION: use `flow-parser` instead, which the flow team is maintaining including all the fancy-pants ES? stuff that FB uses internally.
This removes the `esprima-fb` parser from jsdocs and replaces it with `flow-parser`. It's almost the same, I checked by diffing all the parser json output and it only had a few irrelevant differences. I had to add a file of constants so that we could remove esprima-fb altogether, too.
This also adds a couple unit tests, so that we can test that jsDocs works programmatically. They don't run if you run the regular RN tests, you have to run `npm test` from the `/website/` subdirectory.
Closes https://github.com/facebook/react-native/pull/9890
Differential Revision: D3865629
Pulled By: bestander
fbshipit-source-id: 8f561b78ca4a02f3f7b45e55904ec2fa911e3bb6
Summary:
This piece of code can assemble all transitive dependencies of a set of entry modules. It is supposed to replace `ResolutionRequest.getOrderedDependencies`.
It has the following advantages:
- has minimal API surface to other components of the system (uses two functions, exposes one function)
- allows to separate concerns into loading + transforming files, resolving dependencies, gathering all modules belonging to a bundle (this code), and bundling
- allows to specify multiple entry points
- allows to use any kind of dependency ID as entry point (haste IDs, node module IDs, relative paths, absolute paths – depends on the resolver)
- allows to skip files, which allows callers to incrementally update previously retrieved collections of modules
Reviewed By: cpojer
Differential Revision: D3627346
fbshipit-source-id: 84b7aa693ca6e89ba3c1ab2af9a004e2e0aaed3d
Summary:
Adding jest and its presets to the react-native init command
**Test plan (required)**
run react-native init foo (using `npm link` to use the local `react-native` version)
inside foo there are now a .babelrc file and the package.json is set up as described by
https://facebook.github.io/jest/docs/tutorial-react-native.html#setup
Closes https://github.com/facebook/react-native/pull/9719
Differential Revision: D3843037
Pulled By: bestander
fbshipit-source-id: 004e27ebd3f257a202ed43f378d6fe6cc23ced52
Summary:
Currently we just try to resolve a rn-cli.config.js file by walking up the tree from node_modules/react-native. In non-standard uses of RN, when your copy of RN may not live within node_modules, it's impossible to use rn-cli.config.js. This PR adds a "config" flag to the cli that let's you pass in a path to rn-cli.config.js.
cc ide
Closes https://github.com/facebook/react-native/pull/7883
Differential Revision: D3382823
Pulled By: bestander
fbshipit-source-id: b946f3bb355050fc2fe99273d0e99e441dbed111
Summary:
React 15.3.0 was officially released. We especially should try not depend on RCs in RN releases and npm doesn't handle RC versions well.
Closes https://github.com/facebook/react-native/pull/9279
Differential Revision: D3683587
fbshipit-source-id: fc4f8a030769232b7697434a419e1e07e482e308
Summary:
This is an initial step of rewriting the CLI interface to use `rnpm` one (commander, plugins etc.).
It's scope is to move all existing commands to use rnpm CLI interface, so that we get plugins, flags and our existing ecosystem working out of the box.
<s>This is still WIP and some of the commands are left commented out.</s>
For the `config` of `rnpm` (functions get info about project and dependency), <s>I am thinking we can merge them with</s> we decided to merge it with [`default.config.js`](e57683e420/local-cli/default.config.js (L33)), so they are available on the `new Config()` [instance](e57683e420/local-cli/cliEntry.js (L59)) (which means we don't have to change anything and current plugins, like runIOS and runAndroid can just start using it [w/o depending on any extra argument](https://github.com/grabbou/react-native/blob/e57683e420210749a5a6b802b4e
Closes https://github.com/facebook/react-native/pull/7899
Differential Revision: D3613193
Pulled By: bestander
fbshipit-source-id: 09a072f3b21e5239dfcd8da88a205bd28dc5d037
Summary:
Since jest stopped using node-haste a while ago, we are the only client left.
This brings back node-haste back to fbsource to allow us to iterate faster.
Reviewed By: bestander
Differential Revision: D3641341
fbshipit-source-id: a859f8834765723a3515e2cf265581b9dd83997c
Summary:
There were several fixes to how calls to propType checkers. This is to
account for the new deprecation warning - React.PropTypes will not be
part of production builds in the future.
Note: There is still a warning about an invalid argument to `React.PropTypes.oneOf` (React is running that validation sooner now). Specifically [both of these](b1e49832ef/Libraries/Components/Touchable/TouchableWithoutFeedback.js (L44-L45)) because `View.AccessibilityTraits` is actually undefined in tests (didn't look into why you conditionally set that).
**Test plan (required)**
`npm test` & fixed all warnings due to proptype secret
Closes https://github.com/facebook/react-native/pull/8758
Reviewed By: zpao
Differential Revision: D3564288
Pulled By: bestander
fbshipit-source-id: 1ff1f90907f41855e364048aa730ccd239c522b4
Summary:
Installing react-native gives a warning because of outdated version of yeoman-generator. The warning is ```npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue```.
This MR will update the yeoman-generator version to 0.21.0 to resolve this warning.
Closes https://github.com/facebook/react-native/pull/8859
Reviewed By: matryoshcow
Differential Revision: D3580087
Pulled By: bestander
fbshipit-source-id: 4daddd804679ab8e95e59cf0d0005f87d2f48e1c
Summary:
This PR solves a problem when video assets are used from third-party React Native components (e.g. [react-native-video](https://github.com/brentvatne/react-native-video). The video will not work while the assets are served from the react native packager because the used video component (iOS) relies on HTTP range requests.
I added a small fix that allows ranged requests (e.g. mp4) to be served in ranges.
To test this:
1. make new react native project
1. add [react-native-video](https://github.com/brentvatne/react-native-video) to xcode project
1. add video component to your project
```
import Video from 'react-native-video';
var resolveAssetSource = require('react-native/Libraries/Image/resolveAssetSource');
/* ... /*
render() {
let source = resolveAssetSource(require('./someVideoFile.mp4')) || {};
return <Video /*....*/ source={source} />;
}
```
That should not work (if video is smaller than a few megabytes, open app a few times). Then add my fix, that should do the trick.
Closes https://github.com/facebook/react-native/pull/8219
Reviewed By: davidaurelio
Differential Revision: D3542485
Pulled By: frantic
fbshipit-source-id: e4f2e4d3aaafa8445e965259bf04ad107dba8a4f
Summary: This removes `node_modules/react` from the list of directories that are used for haste module resolutions. Modules required from React are now imported with `require('react/lib/…')`.
Reviewed By: astreet
Differential Revision: D3509863
fbshipit-source-id: 32cd34e2b8496f0a6676dbe6bb1eacc18124c01e
Summary: This should have literally no changes from the RC that affect RN -- just a version bump.
Reviewed By: vjeux
Differential Revision: D3511116
fbshipit-source-id: 5bb3a330c0d2e78a2f3dfbb0e948c99607d2e66e
Summary:
Notable changes (excluding DOM-only things):
- Improved warning messages for propTypes and key warnings
- Production error codes
- Improved performance in DEV mode
- More accurate data in ReactPerf instrumentation
- Experimental JSON test renderer
- Minor bug fixes
Full changelog: fef495942a...c66f40f749.
Reviewed By: AaaChiuuu
Differential Revision: D3442002
fbshipit-source-id: 940fc65ba5d0b742417bbe2fcbd36eb9dc7443e1
Summary:
React has some internal code related only to React Native.
Some times React needs to update them which will result in a breaking change for React Native but it would not be a breaking change for React public API, so no major version bump will happen.
It means that a non breaking API bump may result in a break for React Native.
That is why React Native should not depend on a ^ of React version.
However React is a peer dependency to React Native and we want to give some flexibility to users to update React independently, so we don't fix the version strict and use ~ to allow patches.
This will be fixed once we extract RN specific code from React into an independent dependency.
Reviewed By: avaly
Differential Revision: D3398202
fbshipit-source-id: cca520f4b80c9ed5ae6fb1444f3d0bf7ffb9c9dd
Summary:
`fbjs-scripts` 0.4.0 has Babel 5 as a dependency, which causes some amount of havoc when you're trying to use `react-native` in a project that's otherwise dependent on Babel 6 and using the flat-installing npm >=3.
Closes https://github.com/facebook/react-native/pull/7855
Reviewed By: frantic
Differential Revision: D3371679
Pulled By: steveluscher
fbshipit-source-id: 9f7643171d89da0de0492e7e97875f472725e990
Summary:
React is a peer dependency and apps may depend on a wider range of versions of React, so strict dependency is not a good choice.
Also `react-native init` does `npm install react` internally creating package.json with `react: ^0.15.x`, this change makes versions consistent as well.
Reviewed By: matryoshcow
Differential Revision: D3365433
fbshipit-source-id: d2810662c36129ff9af184c359ac190544db75da
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
Fixing a bug detailed in Issue #7526 where Android app was crashing when using a binary number.
**Test plan:**
- Build & Run UIExplorer
- Build & Run UIExplorer with `const binaryNumber = 0b101010` inserted into UIExplorerApp.android.js
- Use `react-native init` to create a new blank project, then replace files in node_modules and insert `const binaryNumber = 0b101010` into index.android.js.
Closes https://github.com/facebook/react-native/pull/7730
Reviewed By: avaly
Differential Revision: D3353119
Pulled By: bestander
fbshipit-source-id: 098442da32a29c369f5932b7a4004e8d7f4cb91f
Summary:
Update to node-haste 2.12.0 to support pass through configuration of supported platforms.
Closes https://github.com/facebook/react-native/pull/7660
Differential Revision: D3335034
Pulled By: mkonicek
fbshipit-source-id: d238b90a90d51654301d61251ceb26d183fef57a
Summary:
The packager was failing with below error after a fresh clone
npm ERR! peerinvalid The package react@15.1.0 does not satisfy its siblings' peerDependencies requirements!
Changed the dependancy for **^react@15.1.0-alpha.1** to **^react@15.1.0** and it was fixed.
Closes https://github.com/facebook/react-native/pull/7692
Differential Revision: D3334425
fbshipit-source-id: ee86fc2e3c6f19b2430658d91d0a88c50bcf11de
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Reviewed By: bestander
Differential Revision: D3301008
Pulled By: davidaurelio
fbshipit-source-id: 504180d158a1e50bc03e28fb0d1e53d0731ce32f
Summary:
This is initial (first step) in the merging process. For now, we are just going to move our code as is into `local-cli` folder (first commit). There were other tweaks made in separate commits to make it easier to go through the code as the diff is expected to be rather large. The purpose of this is to make it easier to start working in small batches and improving the CLI incrementally on a daily basis.
Current codebase will still leave in `rnpm` organisation on Github where we keep working on new features, bugs and ship releases to `npm` until we finish our integration and provide a nice interface for users to migrate (in case it changes at all)
Flow, Jest and npm will ignore this folder for now until we integrate it properly.
Tests are to be rewritten from mocha to jest in `rnpm/link`. We will hook them all up as soon as we start using them in local-cli.
For now, there's no point in having them running and possibly breaking the builds.
We will announce next steps with Kureev later this week
Closes https://github.com/facebook/react-native/pull/7550
Differential Revision: D3327772
Pulled By: mkonicek
fbshipit-source-id: 90faa4bd78476d93ed21b1253e0d95c755d28a30
Summary:
Putting this up as request for comments.
The PR adds [transform-react-jsx-source](https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-react-jsx-source) to the list of plugins that come by default with the `react-native` preset. It will enable the use of a bunch of really cool tooling around JSX, however those are generally useful only in development mode. Is changing `react-native` preset the right thing to do in this case? Is there a way to enable this transform only in DEV? Should I add this somewhere else?
Closes https://github.com/facebook/react-native/pull/6351
Differential Revision: D3302906
Pulled By: frantic
fbshipit-source-id: 012d3a4142168f9f90d30d1686115d4dc3996eb9
Summary:
The babel plugin transform-es2015-constants was replaced by check-es2015-constants.
References:
T2970
rBW0a3b3b03dbcfc8d1e809a0eaf6270eec8de80763
T3053
This patch updates the babel preset to use check-es2015-constants which should be more future-proof and will receive bug fixes.
Closes https://github.com/facebook/react-native/pull/6943
Reviewed By: davidaurelio
Differential Revision: D3189222
Pulled By: bestander
fb-gh-sync-id: a5ec23e297e1d3591d51641dd567049f4310b107
fbshipit-source-id: a5ec23e297e1d3591d51641dd567049f4310b107
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Differential Revision: D3242754
Pulled By: eczarny
fb-gh-sync-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
fbshipit-source-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Differential Revision: D3242754
Pulled By: davidaurelio
fb-gh-sync-id: 02880c841c10562d5f107e1c975d668e55cc619f
fbshipit-source-id: 02880c841c10562d5f107e1c975d668e55cc619f
Summary:
react-native is about to do a branch cut for the next stable release. We want
this version to use a stable release of react so we released one.
This should be the same as the previous alpha. The is mostly changes to DOM / testing and not RN:
https://github.com/facebook/react/commits/15.0.2-dev
AFAIK there are no behavior changes to RN.
I had to add ReactPropTransferer from downstream since this moved out of React Core and into www.
Reviewed By: zpao
Differential Revision: D3245046
fb-gh-sync-id: 7e460315699fd5bff36d89751ce94edb75dd4733
fbshipit-source-id: 7e460315699fd5bff36d89751ce94edb75dd4733
Summary: This upgrades to node-haste@2.10.0 and allows to expose folders as additional node modules from rn-cli.config.js
Reviewed By: bestander
Differential Revision: D3232595
fb-gh-sync-id: dffca66fec55a79a2b3af1d6ec1b8799b2bbcf59
fbshipit-source-id: dffca66fec55a79a2b3af1d6ec1b8799b2bbcf59
Summary:HMR e2e test red-screened because of the wrong path to react.
**Test plan (required)**
Make sure e2e tests pass
Closes https://github.com/facebook/react-native/pull/7209
Reviewed By: mkonicek
Differential Revision: D3218896
Pulled By: bestander
fb-gh-sync-id: 8c5c4ceda34bd2d273e9de16ed670592d1fde3b9
fbshipit-source-id: 8c5c4ceda34bd2d273e9de16ed670592d1fde3b9
Summary:Adding the react native renderer dependency and various fixes to support React 15.
Don't use dispatchID for touchableHandleResponderGrant
This callback argument was removed because "IDs" no longer exist. Instead, we'll
use the tag from the event target.
The corresponding PR on React Core is: https://github.com/facebook/react/pull/6338
Reviewed By: spicyj
Differential Revision: D3159788
fb-gh-sync-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
fbshipit-source-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
Summary:Fixes an issue where if you implement `renderScrollComponent` and have a `ref` callback on the returned element, the ref used to be clobbered by the ref that ListView adds to the element.
This is accomplished by converting the ref from a legacy string-based ref to a callback-based ref, and then using `cloneReferencedElement`, which is a simple utility to compose callback refs.
Closes https://github.com/facebook/react-native/pull/6441
Differential Revision: D3064250
Pulled By: mkonicek
fb-gh-sync-id: 2d55d04e2144a1cc08900a57a1fc0dab07c87eea
fbshipit-source-id: 2d55d04e2144a1cc08900a57a1fc0dab07c87eea
Summary:In https://github.com/facebook/react-native/pull/5241 ide updated the version number to be a fake one so that people wouldn't send in PRs just bumping the version.
Unfortunately, this leads to compatibility issues when developing against `master` with 3rd-party components that declare React Native as a `peerDependency`. For example, I'm using [react-native-orientation](https://github.com/yamill/react-native-orientation) which has a peerDependency of `"react-native": ">=0.5"`.
I see a few ways to deal with this:
1. Only develop against the releases on npm, not git snapshots.
2. Ask ecosystem projects to not include a minimum version of `react-native` in their peerDependencies.
3. Track the RN release numbers in the git repository (eg it would be 0.19 right now).
4. Make the release number on master huge (1000 in this PR) so it's obviously a fake number but will still comply with >= checks.
I don't think option 2 is good because it's reasonable for a package author to want to specify a minimum R
Closes https://github.com/facebook/react-native/pull/5556
Differential Revision: D3110274
fb-gh-sync-id: 8638157d44ee99945337fbf585936b50699f0341
fbshipit-source-id: 8638157d44ee99945337fbf585936b50699f0341
Summary:The goal is to minimize the number of files we need to bootstrap. This allows us to make the upgrade process smoother for everyone.
If someone needs to customize the file, we already provide some config options. The ability to copy the file and modify it is always there for those few who need it.
**Test plan**
Generate a new project with the updated template. The app should build and run fine both in debug and production mode.
Related #6292
Closes https://github.com/facebook/react-native/pull/6610
Differential Revision: D3109099
Pulled By: foghina
fb-gh-sync-id: 13fc89e60daed30bf6349e532a140c1b6f8f053a
fbshipit-source-id: 13fc89e60daed30bf6349e532a140c1b6f8f053a
Summary:Tests seem to be broken on CI due to failing dependency of `babel-eslint` on `eslint` < `2.0.0`.
cc bestander
Closes https://github.com/facebook/react-native/pull/6669
Differential Revision: D3102085
fb-gh-sync-id: a9fe36725aac293fbe60f282342297f776d715b2
fbshipit-source-id: a9fe36725aac293fbe60f282342297f776d715b2
Summary:This change adds the `flow/` folder to the generated `.flowconfig` in new/upgraded projects. The absence of this folder was causing flow bugs to appear in projects consuming react-native that weren't visible in react-native itself. By including the same definition in consuming projects these errors disappear. Fixes https://github.com/facebook/react-native/issues/6428.
**Test plan (required)**
Tested `react-native upgrade` with this change and ensured that the generated `.flowconfig` works and didn't throw flow errors.
Closes https://github.com/facebook/react-native/pull/6430
Differential Revision: D3071701
fb-gh-sync-id: f28f4d8f7e63669386766b6f226144adeda32c85
shipit-source-id: f28f4d8f7e63669386766b6f226144adeda32c85
Summary:- lint bot is now managed by Circle CI
- checked that flow and lint errors are caught both by bot and CI
- flow fix for npm 3
- Travis is now using npm 2 and Circle CI npm 3
- Refactored Travis script to be able to be able to fail on multiple lines
Closes https://github.com/facebook/react-native/pull/6508
Differential Revision: D3069500
Pulled By: davidaurelio
fb-gh-sync-id: 02772bf1eae5f2c44489c2e3a01899428a9640cb
shipit-source-id: 02772bf1eae5f2c44489c2e3a01899428a9640cb
Summary:Changing the order of transformation and extraction of dependencies made the order of modules dependent on the time when the worker pool returns a result.
node-haste v2.9.1 addresses this issue and makes the order of dependencies deterministic.
This also bumps the packager versions to enforce cache invalidation.
Reviewed By: martinbigio
Differential Revision: D3065063
fb-gh-sync-id: 1d45b066e45c3f64092f779c3fce3becf6739409
shipit-source-id: 1d45b066e45c3f64092f779c3fce3becf6739409
Summary:This work allows automated release deployment.
Previous semi-automation lived in release.sh and I split it into two pieces:
- test-manual-e2e.sh - that just tests that current commit is buildable and makes a quick e2e installation for manual testing
- publish-npm.js - that makes publish based on what current branch and tags are on commit that is tested/deployed by CI
This simplified `Releases.md` guide and requires you to just run
```
git checkout -b 0.22-stable
git tag v0.22.0-rc
git push origin 0.22-stable --tags
```
to have a successful npm release.
Closes https://github.com/facebook/react-native/pull/6453
Reviewed By: mkonicek
Differential Revision: D3047938
Pulled By: bestander
fb-gh-sync-id: dbebf4c3a0bc2c2a0ef75c54595ab5654f91b8ea
shipit-source-id: dbebf4c3a0bc2c2a0ef75c54595ab5654f91b8ea
Summary:This is the last bits needed to fix Windows compatibility on master, most of the work was done in node-haste.
**Test plan**
Run npm test
Run the packager using Windows and Mac
cc cpojer davidaurelio
Closes https://github.com/facebook/react-native/pull/6260
Reviewed By: dmmiller, bestander
Differential Revision: D3005397
Pulled By: davidaurelio
fb-gh-sync-id: e16847808ebfa8b234315b2093dba204c9c1e869
shipit-source-id: e16847808ebfa8b234315b2093dba204c9c1e869
Summary:If website has node_modules installed `npm tests`
**Test plan (required)**
```
cd website && npm install
cd .. && npm test
```
Before this fix we see this error:
Error: Failed to build DependencyGraph: providesModule naming collision:
Duplicate module name: ViewportMetrics
Paths: react-native/node_modules/react/lib/ViewportMetrics.js collides with react-native/website/node_modules/react/lib/ViewportMetrics.js
Closes https://github.com/facebook/react-native/pull/6170
Differential Revision: D3001147
Pulled By: bestander
fb-gh-sync-id: a040edf097183e6899c0ff49785ff36bd465eb61
shipit-source-id: a040edf097183e6899c0ff49785ff36bd465eb61
Summary: We need a newer release of uglify in order not to include //# sourceMappingURL= comments
Reviewed By: martinbigio
Differential Revision: D3025104
fb-gh-sync-id: f39a2fa859c3279908abd47e84288ef6a0a17e4a
shipit-source-id: f39a2fa859c3279908abd47e84288ef6a0a17e4a
Summary:See comments on https://github.com/facebook/react-native/pull/6346
We cannot publish the shrinkwrap file to npm and make the same file
work with the internal fb infra.
We've never had the shrinkwrap file in a release of RN, keeping it
that way for now should be ok.
Reviewed By: bestander
Differential Revision: D3024260
fb-gh-sync-id: 477509eb9a9890c1955a957ece922d692cd35aab
shipit-source-id: 477509eb9a9890c1955a957ece922d692cd35aab
Summary:PR does as it says -- updates Babel dependencies to latest versions.
In general, this changes nothing for 99.9% of users (everyone that isn't FB). If they were to `npm install react-native` right now, they would get all of these dependencies anyway.
However, this does revert a previous change where we were using "~" instead of "^" in front of the Babel deps in order to attempt to lock them to minor dependencies. However, due to the fact that each Babel package uses "^", and there are so many interdependencies, this actually would cause an issue where multiple versions of babel-core, et. al. to be installed.
*Edit* - In addition, we add React to `devDependencies` so that it behaves properly in testing, now that it's a peer dependency.
Closes https://github.com/facebook/react-native/pull/5811
Reviewed By: davidaurelio
Differential Revision: D2931184
Pulled By: martinbigio
fb-gh-sync-id: 7b9fc640d37fb2d98fc1808860f9f64074aff475
shipit-source-id: 7b9fc640d37fb2d98fc1808860f9f64074aff475
Summary:Using local version of the Flow make it easy to have project specific version instead of relying on the user to have the correct version installed globally. For example, React Native uses an older version of Flow, while I have the latest version installed. Now I cannot typecheck the code because my version doesn't match the `.flowconfig`.
**Test plan (required)**
Run `npm run lint` and `npm run flow` to run `eslint` and `flow`.
cc bestander mkonicek
Closes https://github.com/facebook/react-native/pull/6145
Reviewed By: dmmiller
Differential Revision: D2976616
Pulled By: bestander
fb-gh-sync-id: bb08f6f8ceb09f644ec1d45c40b4cb7a9d3cfef5
shipit-source-id: bb08f6f8ceb09f644ec1d45c40b4cb7a9d3cfef5
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary: This updates to the latest published node-haste version, and also adapts code and tests to that version. Future upgrades should be easier.
Reviewed By: bestander
Differential Revision: D2963144
fb-gh-sync-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
shipit-source-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
Summary: This restricts the version range of node-haste to >=2.0.0 <2.1.0, because 2.1.0 has a breaking change.
Reviewed By: mkonicek
Differential Revision: D2958263
fb-gh-sync-id: b8a1c39857731865fd16f5287af53ad0536781c2
shipit-source-id: b8a1c39857731865fd16f5287af53ad0536781c2
Summary: This installs the 2.0 version of node-haste, removes the DependencyResolver and fixes up all the tests.
Reviewed By: davidaurelio
Differential Revision: D2943416
fb-gh-sync-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
shipit-source-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
Summary:This updates jest to 0.9 which will result in *much* faster startup time (1s vs. 10-15s) and better runtime overall (2-3x).
The route gen and cli integration tests are failing locally, but also on master. javache is this expected right now or is this related to my changes?
Reviewed By: javache
Differential Revision: D2943137
fb-gh-sync-id: 8b39ba5f51e30fbc5bacb84d67013ab0a4061f6e
shipit-source-id: 8b39ba5f51e30fbc5bacb84d67013ab0a4061f6e
Summary:Turns out also having sources (besides binaries in /android) in npm is useful:
https://facebook.github.io/react-native/docs/android-building-from-source.html
Reviewed By: mkonicek
Differential Revision:D2947237
Ninja: oss-only
fb-gh-sync-id: 80e3e79c9c5a5f54fd54e91ac147249a68c74847
shipit-source-id: 80e3e79c9c5a5f54fd54e91ac147249a68c74847
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: javache
fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: davidaurelio
fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary:
This PR moves `react` from dependencies to peerDependencies.
In general, this would have only been important for those people using packages that depend on `react` and were using npm@2...npm@3 would automatically de-dupe.
However, when #5812 gets merged, dependencies will be scoped to react-native (on both npm@2 & npm@3), thus breaking projects that are using a package like `react-redux` for example, which depends on `react`. There would be two copies of React installed, and due to the use of haste modules in `react`, this would break the packager and cause naming collisions.
This PR does three things -
1. Moves the dependency from dependencies to peerDependencies
2. Updates the local-cli to run `npm install react --save` when a new project is initialized.
3. Updates `react-native upgrade` to warn if `react` is not listed in the package.json's dependencies.
**Note: This will require a shrinkwrap update.**
Closes https://github.com/facebook/react-native/pull/5813
Reviewed By: svcscm
Differential Revision: D2918380
Pulled By: androidtrunkagent
fb-gh-sync-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
shipit-source-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
Summary:
This lets us say goodbye to Maven Central. This will greatly simplify
and speed up the release process as releasing Android artifacts to
Maven Central adds a lot of [complexity](https://github.com/facebook/react-native/blob/master/Releases-publish.md)
and delays the whole release by several hours when we have to wait
for the artifacts to propagate.
This diff assumes there's a local Maven repo at
`node_modules/react-native/android`.
The second part once this lands is to change our `release.sh` script to
output the artifacts under `react-native/android` before publishing to
npm.
This adds 3.7MB to the size of `node_modules` of any app. However,
we just download eagerly what we'd normally download later via Gradle.
**Test plan**
Released RN including a local Maven repo into Sinopia:
$ cd react-native
# Updated version in gradle.properties to 0.21.0
$ ./gradlew ReactAndroid:installArchives
# Moved everything in .m2/repository/com/facebook/react to react-native/android
$ ls react-native/android
com/facebook/react/react-native/0.21.0/react-native-0.21.0.aar
com/facebook/react/react-native/0.21.0/react-native-0.21.0.pom
com/facebook/react/react-native/maven-metadata.xml
...
# Set version in package.json to 0.21.0
$ npm set registry http://localhost:4873/
$ npm publish
Created and ran an app:
$ cd /tmp
$ react-native init AndroidNpm
$ cd AndroidNpm
$ react-native run-android
It worked.
Checked that we're using the artifacts from node_modules/react-native/android:
$ cd android
$ ./gradlew app:dependencies
compile - Classpath for compiling the main sources.
+--- com.android.support:appcompat-v7:23.0.1
| \--- com.android.support:support-v4:23.0.1
| \--- com.android.support:support-annotations:23.0.1
\--- com.facebook.react:react-native:+ -> 0.21.0
+--- com.google.code.findbugs:jsr305:3.0.0
+--- com.facebook.stetho:stetho-okhttp:1.2.0
...
Checked that Android Studio can find the source jars (you can navigate to RN sources in Android Studio). Opened the new project as described in the [docs](https://facebook.github.io/react-native/docs/android-setup.html#editing-your-app-s-java-code-in-android-studio).
public
Reviewed By: bestander
Differential Revision: D2912557
fb-gh-sync-id: 251c180518a3fb9bb8e80963b236e982d65533be
shipit-source-id: 251c180518a3fb9bb8e80963b236e982d65533be
Summary:
Rather than specifying Babel plugins in the `.babelrc` packaged with react-native, leverage a Babel preset to define the plugins (https://github.com/exponentjs/babel-preset-react-native).
This allows for a much better user experience for those who want (or need) to override options in their project's `.babelrc`.
Prior to this PR, if a user wanted to use a custom babel-plugin (or a custom set of babel plugins), they'd have either 1) manually override the `.babelrc` in the react-packager directory (or fork RN), or 2) specify a custom transformer to use when running the packager that loaded their own `.babelrc`. Note - the custom transformer was necessary because without it, RN's `.babelrc` options would supersede the options defined in the project's `.babelrc`...potentially causing issues with plugin ordering.
This PR makes the transformer check for the existence of a project-level `.babelrc`, and if it it's there, it _doesn't_ use the react-native `.babelrc`. This prevents any oddities with Babel plug
Closes https://github.com/facebook/react-native/pull/5214
Reviewed By: davidaurelio
Differential Revision: D2881814
Pulled By: martinbigio
fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c
Summary:
I talked about this a bunch before. node-haste2 will resolve this issue. Right now node-haste1 looks into eevery single node_module recursively even though we only need to look into a finite-set of them. Some node_modules are huge so it takes a long time. haste2 doesn't eagerly look into node_modules so it doesn't have this issue. This diff blacklists the modules from node-haste but since we use the `resolve` npm module as a fallback we'll still be able to require them.
public
Reviewed By: kassens
Differential Revision: D2852384
fb-gh-sync-id: 113f1bd9c66fcd712c2549a7110a3e752b0e4a69
Summary:
The current versions in these files is 0.12.0, which is out of date. Better to claim no version than the wrong version, so this diff changes the versions to 0.0.0-master.
Release branches will still have the correct versions.
Closes https://github.com/facebook/react-native/pull/5241
Reviewed By: svcscm
Differential Revision: D2819277
Pulled By: javache
fb-gh-sync-id: 99d4682e5d1f571e241f306caf309b2944483909
Summary:
One consequence we didn't predict after introducing the Internal Transform Pipeline, was that when the workers would get started, we won't require the external transformer the user specified up until the first time each worker received a job. There're 2 visible consequences of this: (1) the transform progress bar seems to get stuck for about 5 seconds the first time the packager receives a request and (2) the first N (# of cores) HMR requests take way longer (about 4 seconds with FB's transformer instead of << 1 second) as we need to require lots of modules.
This diff creates a temporary file for the js transformer workers that requires the user-specified transform file eagerly.
That makes sure workers have imported babel and the transforms before receiving the first request.
There are better ways to do this, like adding an `init()` method to the workers and call that eagerly. I will follow with another diff doing that.
public
Reviewed By: javache
Differential Revision: D2812153
fb-gh-sync-id: 15be316b792d1acd878ed9303bea398aa0b52e1d
Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
Summary:
Adds support for tracking unhandled rejections with `console.warn` (= yellow box).
I will create a follow-up with proper error stack formatting.
related: #4971fixes: #4045, #4142
public
{F59857438}
{F59857439}
Reviewed By: bestander
Differential Revision: D2803126
fb-gh-sync-id: 376b33e42a967675a04338cbff3ec315a77d1037
Summary:
It is required from the RN app JS, so it needs to be in prod dependencies.
cc martinbigio
Closes https://github.com/facebook/react-native/pull/5091
Reviewed By: svcscm
Differential Revision: D2798891
Pulled By: martinbigio
fb-gh-sync-id: 976ccf4d96338c8e3d7e457710559be51c4f7405
Summary:
public
Attempt to fix https://travis-ci.org/facebook/react-native/builds
Steps:
cd .../react-native-github
npm install fbjs-haste@0.3.4
# manually update npm-shrinkwrap.json (normally done using npm shrinkwrap --dev but the shrinkwrap file is out of date)
Reviewed By: zpao
Differential Revision: D2755259
fb-gh-sync-id: c5237adcc14e9e21cc09dfad765eff16ddf28484
Summary: fixes https://github.com/facebook/react-native/issues/3997
the root cause is in
Mon, 09 Nov 2015 13:22:47 GMT ReactNativePackager:SocketServer uncaught error Error: listen EACCES C:\Users\donald\AppData\Local\Temp\react-packager-9248a9803ac72b509b389b456696850d
This means that the socket server cannot create the socket.
cfr https://gist.github.com/domenic/2790533 the socket name is not a valid windows socket name.
Closes https://github.com/facebook/react-native/pull/4071
Reviewed By: mkonicek
Differential Revision: D2699546
Pulled By: davidaurelio
fb-gh-sync-id: 6c6494c14c42bb17506b8559001419c9f85e91e3
Summary: Not many changes. Notably, this includes https://github.com/facebook/react/pull/5166 which fixes Chrome debugging in RN (in a web worker, `window.dispatchEvent` is available but `document` is not).
Fixesfacebook/react-native#4007.
public
Reviewed By: sebmarkbage
Differential Revision: D2638788
fb-gh-sync-id: f6838af54fb0da855bac7edba0adce5d0094d0d9
Summary: public
Update package.json and npm-shrinkwrap.json with all the packages necessary for babel 6.
Reviewed By: davidaurelio
Differential Revision: D2631290
fb-gh-sync-id: 3ec4cbf902379256478f940f2711cab5de5f7e6e
Summary: Install react-haste and fbjs-haste, remove react-tools, update npm-shrinkwrap.json. This only updates the npm packages; the subsequent commit will update the repo to work correctly with this new version.
public
Reviewed By: vjeux
Differential Revision: D2608597
fb-gh-sync-id: a372e4033f7c5091fa15b068853dd00ee69f5f75
Summary: This adds the moduleNameMapper config which corresponds to the same config in flow.
public
Reviewed By: voideanvalue
Differential Revision: D2582879
fb-gh-sync-id: f116b86a7d4196c39faa366a521fe8401769b173
Summary: This version should be more stable and has the `moduleNameMapper` feature that frantic was asking for - I will send a follow-up diff for that. I also fixed an issue with `module.parent` and a module inside of yeoman that thought it was owning the universe.
See https://github.com/facebook/jest/blob/master/CHANGELOG.md#061 for a changelog since 0.5.6.
public
allow-crlf-text
Reviewed By: javache
Differential Revision: D2579041
fb-gh-sync-id: cb918875557f219239f49fc0ad49ac61d0884173
Summary: public
This was introduced by vjeux on 0a5967d and removed on 0686b01. I guess it was removed accidentally as this this is a nice warning to have that should prevent n00bs from commiting a common mistake
Reviewed By: frantic
Differential Revision: D2563885
fb-gh-sync-id: 9fae145bbec587514f118d1d28d076b1d82f0630
Summary: public
We cannot remove `local-cli` because is referenced by the global cli explicitly. If we do so, people would have to upgrate this global thin cli which will cause some pain. So, lets move `private-cli` commands into `local-cli` instead.
Reviewed By: frantic
Differential Revision: D2571983
fb-gh-sync-id: 712c29430203660fb6f0d5f23813cb2a7156ee48
Summary: We need to keep both babel and babel-core top level. `npm-shrinkwrap` defines that to be at the top level but that's only used when cloning the github repo. When publishing to npm and installing from npm, it has no effect (it's not published anywhere).
This file assumes `babel-core` is at the top level: https://github.com/facebook/react-native/blob/master/packager/babelRegisterOnly.js
public
Reviewed By: davidaurelio
Differential Revision: D2565054
fb-gh-sync-id: 7d6a079d88e09c1ba0478cf4041948e330da639a
Summary: Fixes#2797 for me.
Most times git://github.com/facebook/react-tools times out. So adding
http as a fail-over so that if git protocol doesn't work while cloning
the react-tools repo as a dependency, http would atleast work and ensure
that a simple "react-native init myProject" doesn't fail.
Submitting a PR so that http is used as a failover when cloning. (I guess that is what git+http does in package.json)
Closes https://github.com/facebook/react-native/pull/3514
Reviewed By: svcscm
Differential Revision: D2561417
Pulled By: spicyj
fb-gh-sync-id: ac421a7f57474124875a5cabdc5a34801019f6cd
Janic Duplessis
Andres Suarez
Jan Kassens
Gabe Levi
Joon Ho Cho
Hawken Rives
Brian Vaughn
Marc Horowitz
Brent Vatne
Mike Lambert
Tomas Roos
Jeff Morrison
Andrew Clark
David Aurelio
Bhuwan Khattar
Nicholas Tate
Cristian Carlesso
Jean Lauliac
Sebastian Markbage
Dan Abramov
Martin Konicek
Tim Yung
Christoph Pojer
Joe Savona
Konstantin Raev
Matthew Dapena-Tretter
Ovidiu Viorel Iepure
zxcpoiu
James Ide
Kevin Lacker
kentaromiura
Pieter De Baets
Prashanth Sampath Kumar
Paul O'Shannessy
Adam Miskiewicz
Mike Grabowski
Paul O’Shannessy
Bart den Hollander
Mark Oswald
tychota
Ian Childs
Ben Alpert
Sam Pepose
Peter deHaan
James
Basil Hosmer
Steven Luscher
Robert Rose
Eric Rozell
Shiran Ginige
Alex Kotliarskyi
Adam Ernst
Kelvin Sherlock
Gabe Levi
Martin Bigio
Satyajit Sahoo
Kyle Corbitt
Kureev Alexey
Konstantin Raev
Johan Lindskogen
Christopher Chedeau
Christopher Chedeau
Bram
Tadeu Zagallo
Flavio daCosta
Tadeu Zagallo
Alex Kotliarskyi
Samarendra M Hedaoo
