Summary: Sets `generateSourceMaps` to true when requesting a bundle in non-dev mode or minified.
Reviewed By: bestander, cpojer
Differential Revision: D4415492
fbshipit-source-id: 9b4dcbd577a535dab143bb7a067210fbd831bf1a
Summary:
This fixes issues that only surface when running with node4 / npm2.
Closes https://github.com/facebook/react-native/pull/11888
Differential Revision: D4415021
Pulled By: bestander
fbshipit-source-id: 8672cd892c9dae41cc7b5b7b3227eb24dd780d22
Summary:
== What ==
Changing the `JSBundleLoader` API, to remove `String getSourceUrl()`, instead `JSBundleLoader.loadScript` now returns the source URL it loaded.
This change has a knock-on effect: We can no longer populate `SourceCodeModule` when we construct it, because at that time, we do not know the source URL.
In order to solve this I have made the following changes:
- Added `CatalystInstance.getSourceURL()`, to return the source URL from the instance after the JS Bundle has been loaded, or `null` otherwise.
- Removed `ReactInstanceManager.getSourceUrl()`, because its only purpose was to populate `SourceCodeModule`.
- Also removed `ReactInstanceManager.getJSBundleFile()` because it was only being used in a test confirming that the `ReactInstanceManager` knew its bundle file as soon as it was constructed, which is no longer necessarily true.
- Initialise `SourceCodeModule` with the `ReactContext` instance it belongs to.
- Override `NativeModule.initialize()` in `SourceCodeModule` to fetch the source URL. When the `SourceCodeModule` is constructed, the context does not have a properly initialised `CatalystInstance`, but by the time we call initialise on it, the `ReactContext` has a `CatalystInstance` and that in turn has a source URL.
== Why ==
The reason for this change is that it allows us to add implementations of `JSBundleLoader`, that cannot determine their source URL until after having performed a load successfully. In particular I plan to introduce `FallbackJSBundleLoader` which will try to load from multiple sources in sequence stopping after the first successful load. As load failures could happen for a variety of reasons, we can't know what the true source URL is without performing the load.
Reviewed By: javache
Differential Revision: D4398956
fbshipit-source-id: 51ff4e289c8723e9d242f23267181c775a6abe6f
Summary:
When something comes in from the right, we swipe from left to
right to move back. That means, when something comes in from the bottom,
we should swipe from top to bottom to get rid of it. This diff makes that
behavior occur - right now it's somewhat nonsensical as both jumpBack
and jumpForward are mapped to the same gesture.
thanks to #11192 for making gestures work on VerticalUpSwipeJumps
Reviewed By: ericvicenti, shergin
Differential Revision: D4412129
fbshipit-source-id: 6a3b202b0a90ca459b4ef106ba5bf48d0b1aec9e
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:
cli / packager was broken on Windows after 28f1c67ced.
Babel `only` regexp option requires paths to use forward slashes only but `__dirname` will use backslashes on windows. This simply adds a replace to normalize to forward slashes.
cc jeanlauliac cpojer
Closes https://github.com/facebook/react-native/pull/11850
Reviewed By: cpojer
Differential Revision: D4409143
Pulled By: jeanlauliac
fbshipit-source-id: a705236630959f762e53100299ab073ec9a29ee1
Summary:
Hi,
The (as of yet unreleased) commit 5537055bf8 added some ListView and ScrollView mocks, but they leave out the original properties passed into them, which broke some of my tests (e.g. by excluding some properties like `testID`, for example, from the render tree) and I assume might break others' as well.
This PR makes it so the ListView mock directly returns the scroll component (instead of wrapping it in a View), and has ListViewMock and ScrollViewMock pass their given properties through.
Closes https://github.com/facebook/react-native/pull/11847
Differential Revision: D4408497
Pulled By: sahrens
fbshipit-source-id: 7ec01c35d6b8efeb97761cddffdb4075d09c7d70
Summary: Adds the `no-const-assign` rule to our `.eslintrc`, because sometime people assign to `const`.
Reviewed By: bestander, jeanlauliac
Differential Revision: D4409485
fbshipit-source-id: c74ad9649ec665e3f2ba2da7843f4e261303c9e7
Summary:
Currently a build warning is thrown by `if (header.BCVersion != runtimeBCVersion) ...` because `runtimeBCVersion` is signed, apparently because `-1` is used to mean that the runtime has no support for bytecode bundles.
This PR splits out the error case of the runtime not supporting BC bundles from the case of a version mismatch.
Tested as much as I could by building and running `UIExplorer` - I haven't attempted to use real bytecode bundles.
Closes https://github.com/facebook/react-native/pull/11806
Differential Revision: D4408608
fbshipit-source-id: a1d868bb2064588e6a20827692629a46b6ba1e74
Summary:
Currently the podspec copies JS files along with the associated Obj-C files (ex: PushNotifications.m and PushNotifications.js are copied together). However the packager looks at `node_modules`, not `Pods`, for the JS source files so these copied JS source files (plus JS unit tests) were always ignored and are cruft.
This is documented as a breaking change but I suspect it won't affect most (if any) configurations. For this to have been useful, you would have had to have had been running the packager under `Pods/..some path to RN../cli.js` instead of with `npm start` or `node_modules/react-native/cli.js`.
Closes https://github.com/facebook/react-native/pull/11761
Differential Revision: D4404934
fbshipit-source-id: a9f372a74f7acb962581f929647e82eae185c5ba
Summary:
On Android with dev mode on, we're seeing a regular SIGSEGV when pushing a lot of animation declarations over the bridge. We tracked this down to being not specific to animations, but the crash is caused in `deepFreezeAndThrowOnMutationInDev`.
Specifically: the provided object to freeze is modified while looping, replacing the current key access to a getter/setter. After the modification, JSC crashes during retrieval of the next key - but only when there are a lot of events passing over the bridge.
We have a hunch that this is due to a bug in JSC object enumeration but did we not look into it further yet. Any help here is welcome. The JS code seems all right at first sight and shouldn't cause a segmentation crash.
The workaround in this PR is to retrieve the keys first from the object and then looping over that array. In our app and in a reduced app test case this fixes the crash.
If needed I can provide the reduced app test case. It's really tricky to make a test for this as it requires to be run
Closes https://github.com/facebook/react-native/pull/11804
Differential Revision: D4403483
Pulled By: davidaurelio
fbshipit-source-id: a31e5cff734e96bfec56e4a39dc1c6854798e245
Summary:
As per janicduplessis recommendation, provide a new synchronous method to replace the necessary synchronous calls and use a warning in the comments (and method name).
**Motivation**
There are currently a number of XCode warnings that show up in a fresh 0.40 install of a react native project. While the project can still be run, this contributes negatively to the development experience -- valid warnings may be ignored and new ones may be added as per https://en.wikipedia.org/wiki/Broken_windows_theory
This addresses one of the warnings, by providing the functionality of a deprecated method in two specific cases where we can't avoid doing synchronous work on the main queue. See https://github.com/facebook/react-native/issues/11736 for more context.
**Test plan (required)**
I ran a project that relied on screen size and it didn't crash...happy to do more involved testing if someone can share better methodology.
Closes https://github.com/facebook/react-native/pull/11817
Differential Revision: D4402911
fbshipit-source-id: 9fd8b3f50d34984b765fe22b1f4512e103ba55a9
Summary:
Fixes the build warning:
```react-native/React/Modules/RCTRedBox.m:406:58: Conversion from value of type 'NSArray<RCTJSStackFrame *> *' to incompatible type 'NSArray<NSDictionary *> *```
This appears because the compiler is left to infer the type of `stack`, and it does so as `NSArray<RCTJSStackFrame *>` based on [RCTRedBox.m#L390](https://github.com/facebook/react-native/blob/master/React/Modules/RCTRedBox.m#L390). In reality `stack` may be either of two types and the function body deals with normalisation.
Mark the stack as explicitly `NSArray<id>` to prevent inference so we're free to make the decision to cast to more specific types.
Closes https://github.com/facebook/react-native/pull/11807
Differential Revision: D4402916
fbshipit-source-id: 356343f244af7638b9b9e91c2c5b7e68de0cbd33
Summary:
`UIActivityViewConroller.completionHandler` has been [deprecated](https://developer.apple.com/reference/uikit/uiactivityviewcontroller/1622010-completionhandler) since iOS 8, when it was replaced by `completionWithItemsHandler`.
Tested the build using `UIExplorer` and XCode 8.2 but I've never seen and can't work out how to activate the `UIActivityViewController` this method relates to, so I haven't tested a real run.
Closes https://github.com/facebook/react-native/pull/11798
Differential Revision: D4396618
fbshipit-source-id: 92a993c434637ede2d5779f4154feb00d2c78d06
Summary:
Motivation: reduce build noise that might worry new users or hide real problems.
This deals with four of the warnings currently in the iOS build. The `__unused` additions are standard and self-explanatory, following the style used elsewhere in RN. I've used `#pragma unused` to deal with parameters named by macros.
Tested by building and running the `UIExplorer` example app in XCode 8.2
Closes https://github.com/facebook/react-native/pull/11797
Differential Revision: D4396611
fbshipit-source-id: 728e9ebb94d147f7a2cbc674a25fe67e66e2e8b2
Summary:
This fixes a broken link in the docs.
Closes https://github.com/facebook/react-native/pull/11453
Differential Revision: D4394773
Pulled By: lacker
fbshipit-source-id: 07b3aaa25017912063ac9e65f336c56a902d7144
Summary:
Sending global events with `eventDispatcher` has been [deprecated](d9737571c4) since 0.28, with a recommendation to subclass `RCTEventEmitter` instead, but there were no docs for this.
This updates the iOS native module to use the recommended way, and also documents the use of `stopObserving` and `startObserving`.
Tested and working in a real app.
cc nicklockwood
Closes https://github.com/facebook/react-native/pull/11792
Differential Revision: D4394626
fbshipit-source-id: 68b26d35944a521bf683a50ec1ab21f03b5e99d8
Summary:
Adds a high performance source map builder that has certain restrictions compared to the `'source-map'` package:
- mappings have to be in the order of the generated source
- source files have to be started/ended separately on the generator. That means building up mappings is optimized for blocks of mappings that all belong to the same source file (or no file)
The implementation avoids allocation of complex value, i.e. strings and objects as much as possible by preallocating a buffer and using numeric character values throughout. The buffer is converted to a string only at the end.
This implementation is ~5✕ faster than using `'source-map'`.
Reviewed By: jeanlauliac
Differential Revision: D4392260
fbshipit-source-id: 406381302d951b919243a2b15e8bb75981e9f979
David Aurelio
Ashok Menon
Pieter De Baets
Andrew Imm
Kevin Lee
Mike Grabowski
Janic Duplessis
Valentin Shergin
Dan Hassin
Jean Lauliac
sunnylqm
Vince Yuan
rh389
Michael Lee
James Ide
Dan Caspi
Albert Brand
Lukas Piatkowski
Stephen Girdlestone
Emil Sjolander
Neil Sarkar
Charles Dick
Yann Pringault
Paul Mestemaker
Rob Hogan
