Summary:
It depends on symbols that are not available.
Closes https://github.com/facebook/react-native/pull/13950
Reviewed By: cwdick
Differential Revision: D5053724
Pulled By: javache
fbshipit-source-id: 9d5676ce5e4ad3ceeb20aeb8c48429319d48799e
Summary:
Not only is this function is building a custom Regex for every single file, but it's also duplicating some of the work of the inner function, that is already splitting up the platform/extension. This changeset refactors both function to have a more strict and legible logic to extract asset information. We extract the base name first, then we extract the resolution from it, instead of rematching platform and extension.
I stumbled on this while looking into refactoring the asset resolution logic of `ResolutionRequest#_loadAsAssetFile()`. The next step would be to reuse the exact same function for resolving assets instead of using a custom regex there as well.
Reviewed By: davidaurelio
Differential Revision: D5060589
fbshipit-source-id: b48d9a5d8e963be76cad5384c6bfb3e214a73587
Summary:
Added a missing license header to UnimplementedView.js
No code logic got changed, just added a comment. So the regular CircleCI tests should be fine.
Closes https://github.com/facebook/react-native/pull/13952
Differential Revision: D5056778
Pulled By: javache
fbshipit-source-id: feb106946a9a34cfdf2df63de21305ac779296f4
Summary:
And clean it up.
**TestPlan**
No more warning when launching RNTester
LayoutAnimationExample still works, also without warnings.
Reviewed By: fkgozali
Differential Revision: D5055050
fbshipit-source-id: a3a6cdf25632dc4f9455d795e8a2e3c00f968e09
Summary:
This three liner addresses the issue described by Rovack here: #9935
Basically, changing the React Native Packager port from 8081 to, say, 8088 does work, *except* if you want to debug your code with ChromeDevTools (i.e. selecting "Debug JS Remotely" from the Android app dev menu).
The analysis of Rovack, pointing to a hard-coded port in DevServerHelper.getHostForJSProxy() was *spot on* - many thanks to him.
Closes https://github.com/facebook/react-native/pull/12095
Differential Revision: D5044330
Pulled By: mkonicek
fbshipit-source-id: c07f59f700683ffba84f03d44f82b394e2e899c1
Summary: Add Flow types, revealing a few problems, such as `isHaste` having the wrong return value in the "pseudo-mocks". But since the buck worker is in fact working, I guess these functions were never called... The point of typing this file is that I'm going to start aggressively pruning dead code in `node-haste` and hopefully, eventually, get rid of `Moduleish` and `Packageish`.
Reviewed By: davidaurelio
Differential Revision: D5052379
fbshipit-source-id: dab3f18f05fcf43fbbc48b589170b1cf367d6a48
Summary: This does not appear to be used anywhere anymore.
Reviewed By: cpojer
Differential Revision: D5052224
fbshipit-source-id: 142fdcdf48f4ad16a04bb747b41d623f214f7a68
Summary: Default arguments are dangerous, and it shows here again. `Server` was calling that function without passing down the platforms, meaning custom platform would not be accounted for, possibly causing all kinds of bugs for OSS use cases. Additional, the typing of `platform` across the stack was wrong: it can be `null`, in which case we resolve the files without extension. The reason Flow didn't detect that issue before is because we use `Object.assign` to re-export the function from `DependencyGraph`, but Flow is not smart enough to propagate the types in that particular case. I'll remove all the other re-export, as it may uncover further type errors.
Reviewed By: davidaurelio
Differential Revision: D5052070
fbshipit-source-id: 7b427ec036ca74b5dcd7c88f7dfa0df541b8eb6b
Summary: in new-style builds, the prelude is not wrapped into an IIFE, so `global` is not available. Since the bundle as a whole is not running in strict mode, we can access the global object with `this`.
Reviewed By: jeanlauliac
Differential Revision: D5051731
fbshipit-source-id: 4003b5e57ba8626e38e68e92d5778c2c59ca69a5
Summary:
A quick fix to ensure RNTest works. This PR changes the process root for where packager is run, resulting in the right `cwd` directory path when RN launches RNTester.
Closes https://github.com/facebook/react-native/pull/13947
Differential Revision: D5052093
Pulled By: davidaurelio
fbshipit-source-id: 506a8cd63f1709c948bcc4586467020d380ba85e
Summary:
The `env` option has been broken in Babel for a while (https://github.com/babel/babel/issues/4539), and will be deprecated (https://github.com/babel/babel/issues/5276).
I am changing this code to the way Babel < 6.10 interpreted the `env` option. This should fix the `__source` JSX transform which was applied in DEV in the past, but stopped getting applied because of the Babel bug.
I also changed the `filename` passed by Babel to be relative (currently, to `fbsource` but open to other options). This way DEV builds are still reproducible.
This still needs some help from davidaurelio to make the root location more foolproof. I'd also appreciate zertosh taking a look in case there's a better way to "anchor" the relative path. All I need is to for `react-third-party/react-devtools/react-devtools` and `babelTransformer.js` to agree on what the relative path base is.
Closes https://github.com/facebook/react-native/pull/13893
Reviewed By: gaearon
Differential Revision: D5035892
Pulled By: davidaurelio
fbshipit-source-id: 19ffeb867d7ed5928e9de05dcec9ba85bf961dd5
Summary: I stumbled on this while refactoring that function, and i realised that, I believe it doesn't make sense to take into account the platform extension of the "potiential" file path. The reason is, if you try to require "foo.ios.png", the returned asset name would be "foo", and thus we'd try to find "foo.${ext}.png" where `ext` could actually be `android` or anything else! So it's confusing. There's no reason we should allow callsites to specify platform anyway I think. With this changeset we're not losing any functionality, but it might require people to fix some incorrect callsites.
Reviewed By: cpojer
Differential Revision: D5051791
fbshipit-source-id: 2a1ec7a8bfa6791b6016213305a72bc0b81f23b9
Summary: I found myself a few times wanting that transform, that makes it slightly simpler to have bound method. So I propose we add it. Not a big deal though. Note it also allows static properties with the same syntax, that is handy.
Reviewed By: davidaurelio
Differential Revision: D5051579
fbshipit-source-id: 7ebf7c709bf52a30a525550c1eda1a6a2f7b8e1e
Summary:
Hi,
Today I upgraded from RN 0.44 to 0.45.0-rc.0 and noticed I add to include either `CxxBridge` or `BatchedBridge` in the React subspecs in my Podfile to get my project to compile again (https://github.com/facebook/react-native/issues/13010).
Adding `BatchedBridge` works fine. However I wanted to try `CxxBridge` as described in 5aca739cc2 but couldn't do it since the required `third-party-podspecs` folder with `Folly.podspec`, `GLog.podspec` and `DoubleConversion.podspec` hadn't been included in the npm release.
So here is the fix for that.
It should be included in the next 0.45.0-rc release.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/13922
Differential Revision: D5051477
Pulled By: javache
fbshipit-source-id: e5c527f1ee9c84734d3e3a3d85ec3f1e5d648bef
Summary:
Pass `localPath` to transformers to allow usage of plugins like `transform-react-jsx-source` that don’t conflict with x-machine caches, e.g. Buck or our own global cache.
These caches don’t work properly if paths local to a specific machine are part of cached outputs.
Reviewed By: jeanlauliac
Differential Revision: D5044147
fbshipit-source-id: 1177afb48d6dd9351738fcd4da8f9f6357e25e81
Summary:
Changes the global cache to use *local paths* rather than base names of files for the cache key. This is to enable correct usage of babel transforms like `transform-react-jsx-source` that use file paths in their output.
It remains a responsibility of the transform implementer to pass relative paths to babel if the global cache is being used.
Reviewed By: jeanlauliac
Differential Revision: D5044028
fbshipit-source-id: 2ef1e1545e510a18ab49a307053d91b4f40269b2
Summary: `transformModulePath` used to be an optional string, because `ConfigT` allowed for an optional `getTransformModulePath` method. Effectively, we required it to be present. This builds on top of the cleanups around `ConfigT` and gets rid of the flow error suppressions
Reviewed By: jeanlauliac
Differential Revision: D5037466
fbshipit-source-id: bc5c9cbc566e7aa74e7f6397e69fa87cdac7bc00
Summary: That's a bit of an experimental changeset, I wanted to experiment how we can track with more precision the resolution and this is what I come with. That allows us to know what has been tested if we canot find a match. It also uses a simpler control flow with early `return`s all across. Finally, this reflect the strategy I want to apply for the rest of the resolution. (Right now the error is still not great, as it may be deeply nested, as in the case of packages resolution.)
Reviewed By: davidaurelio
Differential Revision: D5044040
fbshipit-source-id: 2e256174506f80d90ee83175057666d530785788
Summary:
`PushNotificationIOS` is a library that makes use of the
`PushNotificationManager` native module.
This commit adds a jest mock for its native module so that code that
uses `PushNotificationIOS` can be tested using jest.
In order to enable behaviour in unit tests it is possible to replace or
overwrite the mock implementation, see the [jest guide on
mocks](https://facebook.github.io/jest/docs/mock-functions.html).
By doing something similar to:
```javascript
import { NativeModules } from 'react-native';
const { PushNotificationManager } = NativeModules;
// mock 'checkPermissions' to return a different value than the default:
PushNotificationManager.checkPermissions.mockImplementationOnce((callback) => {
// execute callback in next tick to enable async behaviour
process.nextTick(() => callback({
alert: false,
badge: false,
sound: false
}));
});
// execute unit tests for code that makes use of 'PushNotificationIOS'
```
Closes https://github.com/facebook/react-native/pull/13410
Differential Revision: D5043904
Pulled By: cpojer
fbshipit-source-id: 11e73cd215ba6854d06f4ac7a5aea0ab4be26584
Summary: Internally when adding `format` we have a lint rule that automatically reformat using `prettier` and the project rule. I'm concerned how we can ensure this stays consistent when merging PRs though. It's not a big issue because the volume of PRs is low, but we'll have to figure it out later on.
Reviewed By: davidaurelio
Differential Revision: D5035830
fbshipit-source-id: 6f2bc9eb8212938ff785a34d2684efd1a9813e1a