Summary: Activity events now have a `silent` boolean option that specifies whether or not the event phases are to be logged to the console. Defaults to `false`, preserving current behaviour for events that do not explicitly have this option set.
Reviewed By: davidaurelio
Differential Revision: D3810802
fbshipit-source-id: 38d14b9e6c6502fbc73eece9466f20b60d19965e
Summary:
When bringing back `node-haste` to React Native, I left an `fdescribe` in a test that led to ~70 tests being skipped.
This re-enables these tests, and fixes test failures
Reviewed By: cpojer
Differential Revision: D3811225
fbshipit-source-id: 67a16f385759bb829f1f3f559862eab7e78f2097
Summary: Updating an existing bundle is now logged as a telemetric event.
Reviewed By: davidaurelio
Differential Revision: D3804754
fbshipit-source-id: adab3b054a161bd9535ad01d52573fb7bb177d43
Summary:
Revised the Activity implementation
- added flow annotations
- fixed some lint warnings
- added event `options`, specifically a `telemetric` option which indicates that events tagged in this manner are relevant for telemetry. The duration of these events is now highlighted in the Activity log
Reviewed By: bestander, kentaromiura
Differential Revision: D3770753
fbshipit-source-id: 6976535fd3bf5269c6263d825d657ab0805ecaad
Summary: The logic of assigning module IDs to the initial require calls of a bundle was faulty, counting up from -1 instead of counting down. This change ensures that IDs are -1, -2, ...
Reviewed By: matryoshcow
Differential Revision: D3735560
fbshipit-source-id: 89efa3e73b39c2f8bfed8a6a30487733d1a8b145
Summary: If a bundle failed to build, a file change would trigger the *update bundle* path, without ever being able to resolve the bundle. If a bundle can't be updated, we evict it from the cache.
Reviewed By: cpojer
Differential Revision: D3726567
fbshipit-source-id: a342f00c5a41364551194c33082718e5483fd7a4
Summary: Rejected promises in the cache would prevent the cache from persisting. This removes rejected promises from the cache, so that subsequent successful cache updates can be persisted.
Reviewed By: cpojer
Differential Revision: D3726691
fbshipit-source-id: ddec03676a7a89264fe64b4af4b183cbead638fb
Summary:
This clears the packager server cache for potential changes of module resolutions.
We will make this a lot better in the future, but for now this crude mechanism will have to do.
Reviewed By: cpojer
Differential Revision: D3713143
fbshipit-source-id: 7c81f40e8ec71404c3369211b29f63928d6634b9
Summary:
This is a very hacky solution to make reloads from packager faster for simple file changes.
Simple means that no dependencies have changed, otherwise packager will abort the attempt to update and fall back to the usual rebuilding method.
In principle, this change avoids re-walking and analyzing the whole dependency tree, and just updates modules in existing bundles.
Reviewed By: bestander
Differential Revision: D3713704
fbshipit-source-id: ba182325c4f4003c0a7402ea87444a94c75ebaf8
Summary:
This is a very hacky solution to make reloads from packager faster for simple file changes.
Simple means that no dependencies have changed, otherwise packager will abort the attempt to update and fall back to the usual rebuilding method.
In principle, this change avoids re-walking and analyzing the whole dependency tree, and just updates modules in existing bundles.
Reviewed By: bestander
Differential Revision: D3703896
fbshipit-source-id: abc2a41144536baf969d346522a17044c1c9558b
Summary:
This is a very hacky solution to make reloads from packager faster for simple file changes.
Simple means that no dependencies have changed, otherwise packager will abort the attempt to update and fall back to the usual rebuilding method.
In principle, this change avoids re-walking and analyzing the whole dependency tree, and just updates modules in existing bundles.
Reviewed By: bestander
Differential Revision: D3703896
fbshipit-source-id: 671206618dc093965822aed7161e3a99db69a529
Summary:
We have a weak build machine for React Native app: a poor Mac Book Air with HDD, which is very slow.
So, fs operations sometimes fail because of timeout.
We likely don't care about build time, but it's pretty annoying to restart builds sometimes.
In this PR I make timeout injectable via environment variable.
__USAGE__:
export this variable into environment. It's measured in miliseconds.
Example, for 1 minute timeout:
`export REACT_NATIVE_FSOP_TIMEOUT=60000`
If you don't specify it, it will remain default value: `15000`
This should not break anything, but repair slow builds.
Related to : #9373 , #8794 (I think so)
This PR should handle case of issue and close#9373
Closes https://github.com/facebook/react-native/pull/9374
Differential Revision: D3709325
Pulled By: bestander
fbshipit-source-id: b00c89e10d05362314546faea7a4524f3d327c97
Summary: This removes asset data that is not used at runtime from the bundle.
Reviewed By: javache
Differential Revision: D3628486
fbshipit-source-id: 33cd579c904e0b0e29502df39a4ff92cad43367c
Summary:
https://github.com/facebook/react-native/pull/8219 adds range requests to the asset server, but there was an off-by-one-error that made responses end prematurely. This made (for example) react-native-video not work for video assets. This change fixes the off-by-one error and react-native-video works with assets.
**Test plan (required)**
Try the test in the original pull request for range requests: https://github.com/facebook/react-native/pull/8219
Closes https://github.com/facebook/react-native/pull/9254
Differential Revision: D3680070
fbshipit-source-id: 3f2a18ba9f35b45b340f4a1046bc099b8444eb7d
Summary: Looks like react-addons-perf is sometimes missing entries. This prevents it from crashing.
Reviewed By: davidaurelio
Differential Revision: D3669007
fbshipit-source-id: 18a1102b5ad8dcfd9b80d39e1172ba85ad0e9dd2
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: This shows at max 5 progress updates per second on the terminal, which results in a minor speedup of reloads.
Reviewed By: bestander
Differential Revision: D3620164
fbshipit-source-id: d1a30f2f29f7088602d276b8ad3fc8ff1b74c79d
Summary:
This changes the jest preprocessor so that files targetet at node.js will be run with the node-specific transform.
It also adapts tests that relied on inline requires.
Benefit: packager tests run faster now.
Reviewed By: cpojer
Differential Revision: D3562007
fbshipit-source-id: e06c86d545926a5c546458025f505dca115e7ea8
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 pull request fixes a small typo when a module fails being transformed through the React Packager.
Closes https://github.com/facebook/react-native/pull/8596
Differential Revision: D3522272
Pulled By: mkonicek
fbshipit-source-id: e117a26bab5a99573ac68fb0e7618df0a14325a4
Summary:
Looks like spaces in function names can happen, but the lib we use for parsing stacktraces doesn't support that. As result, when error is thrown in global scope, new JSC puts "global code" as function name, our parser chokes on it and thinks "global code@http://...." is a file name and sends it to packager. The packager can't resolve that URL and fails the whole symbolication request.
Longer term fix here: https://github.com/errwischt/stacktrace-parser/pull/5
Reviewed By: astreet
Differential Revision: D3516741
fbshipit-source-id: 7f14b52a50a118dc95a3463aee842941e904e984
Summary:
Looks like spaces in function names can happen, but the lib we use for parsing stacktraces doesn't support that. As result, when error is thrown in global scope, new JSC puts "global code" as function name, our parser chokes on it and thinks "global code@http://...." is a file name and sends it to packager. The packager can't resolve that URL and fails the whole symbolication request.
Longer term fix here: https://github.com/errwischt/stacktrace-parser/pull/5
Reviewed By: astreet
Differential Revision: D3516741
fbshipit-source-id: 4f2bb70084437ed9d37495cd775622a8c981fad1
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:
* Next version of Jest doesn't allow non test files in __tests__ folders.
* I'm trying to switch all tests off of jsdom on react-native. This should save 500ms of time when running a single test because jsdom is slow to load and react-native is also not supposed to run in a DOM environment, so let's not pretend we are providing the DOM in tests.
* Make the bridge config configurable so that when we disable automocking and we reset the registry we can redefine the value.
Oh also, stop using lodash in Server.js. First off, lodash 3 doesn't work in Jest's node env because it does some crazy stuff, second because we don't need to load all of lodash for debounce.
Reviewed By: davidaurelio
Differential Revision: D3502886
fbshipit-source-id: 1da1cfba9ed12264d81945b702e7a429d5f84424
Summary:
When an asset is included in a module, and the directory for that asset can't be found in any of the roots, it is hard to debug that, because the error message contains neither the name of the requested file, the sub directory it is located in, nor the roots that have been searched for it. It becomes more difficult, because that exception is created asynchronously. It contains the calling promise code.
This diff makes the error message more useful by including the name of the file, the sub directory, and the roots.
Reviewed By: bestander
Differential Revision: D3456738
fbshipit-source-id: 60b81f04626ad386f7120247c5f5361c81c52968
Summary:
This makes sure that `getModuleId` is called on modules in the order returned by `node-haste`, rather than waiting for a couple of promises to resolve before calling the function.
Related: #7758
Reviewed By: frantic
Differential Revision: D3450853
fbshipit-source-id: 7f26590b39b94ade32c73a8db9fd31d283d57549
Summary:
When trying to access the debug dependency graph through the `/debug/graph` endpoint of the packager server (documented in the packager README and listed as well when hitting the root `/debug` endpoint), all I am getting back is a nasty HTTP 500 error :'(
What triggers this HTTP 500 is a `TypeError` being thrown while trying to access a function that doesn't exists (anymore). Here is the error log of the packager when trying to access this endpoint :
```
TypeError: this._depGraph.getDebugInfo is not a function
at Resolver.getDebugInfo (index.js:270:27)
at Bundler.getGraphDebugInfo (index.js:575:27)
at Server._processDebugRequest (index.js:369:28)
at Server.processRequest (index.js:423:12)
at next (/Users/blemair/Code/DependencyGraphTest/node_modules/connect/lib/proto.js:174:15)
at Object.module.exports [as handle] (cpuProfilerMiddleware.js:17:5)
at next (/Users/blemair/Code/DependencyGraphTest/node_modules/connect/lib/proto.js:174:15)
at Object.module.exports [as
Closes https://github.com/facebook/react-native/pull/8117
Differential Revision: D3445582
fbshipit-source-id: cf5af8bbba293f39773f32814a3b388b7ff67bf7
Summary:
When remote debugging is enabled, stack traces start at `/debuggerWorker.js`. Since this is not a valid bundle URL, the packager fails to decipher it to find its sourcemap.
This changes the packager to skip the `/debuggerWorker.js` stack frame if one exists.
Reviewed By: frantic
Differential Revision: D3418341
fbshipit-source-id: 7434aa45dea7d120d9d77c060101dd9403989d0c
Summary: We are already inlining `Platform.OS`. This diff adds support to inline calls to `Platform.select` with an object literal as first argument. The transform will replace the call with the property value corresponding to the platform, or `undefined` if it does not exist.
Reviewed By: frantic
Differential Revision: D3385391
fbshipit-source-id: bb068d17948ed84e381707faeaa0450399c2f306
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 way we currently symbolicate JS stack traces in RN during development time
(e.g. inside the RedBox) is the following: we download the source map from RN,
parse it and use `source-map` find original file/line numbers. All happens
inside running JSC VM in a simulator.
The problem with this approach is that the source map size is pretty big and it
is very expensive to load/parse.
Before we load sourcemaps:
{F60869250}
After we load sourcemaps:
{F60869249}
In the past it wasn't a big problem, however the sourcemap file is only getting
larger and soon we will be loading it for yellow boxes too: https://github.com/facebook/react-native/pull/7459
Moving stack trace symbolication to server side will let us:
- save a bunch of memory on device
- improve performance (no need to JSON serialize/deserialize and transfer sourcemap via HTTP and bridge)
- remove ugly workaround with `RCTExceptionsManager.updateExceptionMessage`
- we will be able to symbolicate from native by simply sending HTTP request, which means symbolication
can be more robust (no need to depend on crashed JS to do symbolication) and we can pause JSC to
avoid getting too many redboxes that hide original error.
- reduce the bundle by ~65KB (the size of source-map parsing library we ship, see SourceMap module)
Reviewed By: davidaurelio
Differential Revision: D3291793
fbshipit-source-id: 29dce5f40100259264f57254e6715ace8ea70174
Summary:
This pull request is a prerequisite to enabling the react-native-windows platform extension.
In the Resolver component, we need to add 'windows' to the list of platforms that are allowed in the DependencyGraph. We also need to add 'react-native-windows' (the name of the Windows platform extension NPM module) to the `providesModuleNodeModules` option. This allows the node_module folder check in the DependencyGraphHelper from node-haste to be bypassed for *.windows.js files in the Windows NPM package.
For good measure, I also included a change to blacklist.js to ensure .windows.js files are ignored when the packager is parameterized on a platform.
Closes https://github.com/facebook/react-native/pull/7639
Differential Revision: D3327771
Pulled By: mkonicek
fbshipit-source-id: d1080b045ff6aa0cbf05d8070ceb0eb4cdb6dceb
Summary:
This got broken recently. As a result of this, when a module throws while being required, either by regular load or hot reload, the module object is marked as `hasError`. Form that point all subsequent HMR updates will fail because it will think the module failed while executing the factory but the failure could have been on an old run of an old factory.
The fix is very simple: just reset `hasError` to false when accepting a module.
Closes https://github.com/facebook/react-native/pull/7567
Differential Revision: D3310685
fbshipit-source-id: 2f0b48ab7432b7c221d0c88a019a28969a8862b2
Summary:
grabbou pointed out this issue.
We recently started cleaning out the factory function after module are required to save some memory. This broke HMR on some edge cases because sometimes the factory function may need to be re-executed. This PR just wraps the optimization into `__DEV__` to make sure we don't use it while developing.
Closes https://github.com/facebook/react-native/pull/7568
Differential Revision: D3305120
Pulled By: martinbigio
fbshipit-source-id: 741cffbb327d118f0bd0ec34dc1af53d4f94880e
Summary:
The code to require modules by their name (rather than their numeric ID) was buggy, because it didn’t check whether the module factory was already executed and the module already existed.
This diff checks the already loaded modules, too, when loading modules by name.
Reviewed By: lexs
Differential Revision: D3281350
fbshipit-source-id: cef236e152fe5484f21c877d6cee37433fa11c76
Summary:
This intends to make the devx story better after switching to numeric module IDs:
- `require('<verbose-name>)` works again for dev builds
- In dev builds, Systrace will use the verbose names of modules for markers
Reviewed By: bestander
Differential Revision: D3253318
fb-gh-sync-id: 3425d5086ce28634653a6c8c7f5f11afa1614902
fbshipit-source-id: 3425d5086ce28634653a6c8c7f5f11afa1614902
Summary: Apparently what we're using for console.trace is not really the same as what Chrome does (we don't log a stacktrace). Add `console.debug` with the same functionality as `console.trace`, just so we don't crash between browser and local execution.
Reviewed By: davidaurelio
Differential Revision: D3235053
fb-gh-sync-id: 4bed17ac8aa4c8c100f15cf0aabbc25101c913c1
fbshipit-source-id: 4bed17ac8aa4c8c100f15cf0aabbc25101c913c1
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:This PR fixes a bug where when using relative roots for the packager server, asset paths would be deemed invalid by the recently introduced security check. Resolving the root to an absolute path fixes that problem.
I'd be happy to write a regression test for this but I had a hard time setting up a mock file system with relative paths. If it is required, some help would be appreciated...
Closes https://github.com/facebook/react-native/pull/7161
Differential Revision: D3214840
fb-gh-sync-id: 08e13fb9f94a98206fd2d090f74a8b63ba2bf80f
fbshipit-source-id: 08e13fb9f94a98206fd2d090f74a8b63ba2bf80f
Summary:The require functions will keep the generate bytecode + lexical environment in
memory unnecessarily, since we can be sure that it will be executed at most once
Reviewed By: davidaurelio
Differential Revision: D3168257
fb-gh-sync-id: 038e1bc08abea94ee52d0390b6aced5fb652f493
fbshipit-source-id: 038e1bc08abea94ee52d0390b6aced5fb652f493
Summary:The WebView component in iOS currently does not support displaying PDFs without providing a remote URI or manually including the assets in the xcodeproj itself. This is because the packager has not whitelisted the 'pdf' extension.
I've gone ahead and whitelisted the 'pdf extension according to the recommendation by nicklockwood
GH comment: https://github.com/facebook/react-native/issues/1846#issuecomment-199302488
Closes https://github.com/facebook/react-native/pull/7004
Differential Revision: D3196019
Pulled By: nicklockwood
fb-gh-sync-id: 10a86a9232095f98f277506141de0b8af5b21ab4
fbshipit-source-id: 10a86a9232095f98f277506141de0b8af5b21ab4
Summary:We weren't passing `transformOptions` to `getShallowDependencies`, and therefore, when this method was called on a module, it would bust the cache and cause a retransform of the file. This was resulting in a complete retransforming of all files when the HMR Client connected to the packager.
Closes https://github.com/facebook/react-native/pull/6843
Differential Revision: D3145306
Pulled By: martinbigio
fb-gh-sync-id: 3619c27801b2fc07b758fafed47fcc892bb8e6db
fbshipit-source-id: 3619c27801b2fc07b758fafed47fcc892bb8e6db
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Tested HMR on Windows and found 2 small issues related to paths that made it not work. Now it works nicely :)
**Test plan (required)**
Tested HMR in UIExplorer on Windows.
Closes https://github.com/facebook/react-native/pull/6678
Differential Revision: D3138379
fb-gh-sync-id: f27cd2fa21f95954685c8c6916d820f41bc187be
fbshipit-source-id: f27cd2fa21f95954685c8c6916d820f41bc187be
Summary: The HMR codepath is currently broken because of a recent change that tries to compute the absolute entryFile path (needed for RAM Bundling). HMR Bundler's bundles are special as they contains a single file (the file that was transformed). However, for performance reasons we recycle an existing resolution response which contains the polyfills and the module system modules.
Reviewed By: sam-swarr
Differential Revision: D3098069
fb-gh-sync-id: 23d61aa304cd6f59d4df4840965f5eedda05dc31
fbshipit-source-id: 23d61aa304cd6f59d4df4840965f5eedda05dc31
Summary:Source maps are broken on Genymotion right now as they aren't being loaded from the correct URL. refer - https://github.com/facebook/react-native/issues/5338#issuecomment-188232402
**Test plan**
Build and install UIExplorer from master branch in genymotion and enable hot reload. When you change a file and save it, you'll see a Yellow box due to source map fetching failed, as per the referenced comment.
Doing the same for this branch doesn't produce any yellow boxes.
Closes https://github.com/facebook/react-native/pull/6594
Differential Revision: D3088218
Pulled By: martinbigio
fb-gh-sync-id: 0d1c19cc263de5c6c62061c399eef33fa4ac4a7b
shipit-source-id: 0d1c19cc263de5c6c62061c399eef33fa4ac4a7b
Summary:We found that moving the preloaded modules to the startup section of the RAM Bundle improves TTI quite a bit by saving lots of through the bridge calls and injecting multiple modules at once on JSC. However, doing this on a non hacky way required a lot of work. The main changes this diff does are:
- Add to `BundleBase` additional bundling options. This options are fetched based on the entry file we're building by invoking a module that exports a function (`getBundleOptionsModulePath`).
- Implement `BundleOptions` module to include the `numPreloadedModules` attribute as a bundle additional option. This value is computed by getting the dependencies the entry file has and looking for the first module that exports a module we don't want to preload. The `numPreloadedModules` attribute is then used to decide where to splice the array of modules.
- Additional kung fu to make sure sourcemaps work for both preloaded and non preloaded modules.
Reviewed By: davidaurelio
Differential Revision: D3046534
fb-gh-sync-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
shipit-source-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
Summary:`/assets/...` requests previously supported path-traversal potentially exposing and serving (private) files outside roots.
**Test plan**
Prior to patching perform the a path-traversal request to the server:
```
GET /assets/../../../../etc/hosts HTTP/1.1
Cache-Control: no-store
Host: 127.0.0.1:8081
Connection: close
Accept-Encoding: gzip
User-Agent: okhttp/2.5.0
```
Apply patch and verify a `404` response with body: `Asset not found`
Test normal asset requests work.
Closes https://github.com/facebook/react-native/pull/6398
Differential Revision: D3034857
Pulled By: shayne
fb-gh-sync-id: f0e6714e4e3c5a63a3a402634a1eb5f3186d3561
shipit-source-id: f0e6714e4e3c5a63a3a402634a1eb5f3186d3561
Summary:We recently refactor the packager to transform the module names into numeric IDs but we forgot to update the HMR call site. As a consequence, HMR doesn't work the first time a file is saved but the second one.
This is affecting master as of 3/20. If we don't land this before v0.23 is cut we'll have to cherry pick it. This rev does *not* need to be picked on v0.22.
Reviewed By: bestander
Differential Revision: D3075192
fb-gh-sync-id: 410e4bf8f937c0cdb8f2b462dd36f928a24e8aa8
shipit-source-id: 410e4bf8f937c0cdb8f2b462dd36f928a24e8aa8
Summary:This adds support for source maps that can be used for “random access modules” / “unbundles”
- source maps contain an extra custom field: `x_facebook_offsets`
- this field maps module IDs to line offsets
- the source map is built as if all files were concatenated
Decoding/symbolication works as follows:
- when decoding a stack trace, and a stack frame comes from a filename that contains only numbers and ends with `.js`, look up the additionally needed line offset in the offset map and add it to the original line of the stack frame.
- consume the source map as usual
Reviewed By: martinbigio
Differential Revision: D3072426
fb-gh-sync-id: 827e6dc13b1959f02903baafa7f9e4fc2e0d4bb9
shipit-source-id: 827e6dc13b1959f02903baafa7f9e4fc2e0d4bb9
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:We use a few different modules to output logs to stdout when building a bundle with the packager:
- ##js/react-native-github/packager/react-packager/src/Activity/index.js##
- ##js/react-native-github/local-cli/util/log.js##
- ##https://www.npmjs.com/package/progress##
This diff also adds a ##silent## option to the packager ##Server##, which, when ##true##, will not create a ##progress## instance for the transformer.
Reviewed By: martinbigio
Differential Revision: D3048739
fb-gh-sync-id: a4c6caf36f5127946593f4a0a349fa145ad0d4e6
shipit-source-id: a4c6caf36f5127946593f4a0a349fa145ad0d4e6
Summary:This brings back "Use numeric identifiers when building a bundle", previously backed out.
This version passes on the correct entry module name to code that decides transform options.
Original Description:
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2855202
fb-gh-sync-id: 9a011bc403690e1522b723e5742bef148a9efb52
shipit-source-id: 9a011bc403690e1522b723e5742bef148a9efb52
Summary:This rev adds support for production sourcemaps on RAM.
When we inject a module into JSC we use the original `sourceURL` and specify the `startingLineNumber` of the module relative to a "regular" bundle. By doing so, when an error is thrown, JSC will include the provided `sourceURL` as the filename and will use the indicated `startingLineNumber` to figure out on which line the error actually occurred.
To make things a bit simpler and avoid having to deal with columns, we tweak the generated bundle so that each module starts on a new line. Since we cannot assure that each module's code will be on a single line as the minifier might break it on multiple (UglifyJS does so due to a bug on old versions of Chrome), we include on the index the line number that should be used when invoking `JSEvaluateScript`. Since the module length was not being used we replaced the placeholder we have there for the line number.
Reviewed By: javache
Differential Revision: D2997520
fb-gh-sync-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
shipit-source-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
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:After starting to minify off the main process, the order of module transport objects in `Bundle` instances became less deterministic.
These changes guarantee that module transports appear in addition order, not in order of minification completion.
Reviewed By: bestander
Differential Revision: D3029588
fb-gh-sync-id: 80e83c05d7f78ed7e69583d7e3aa2831bd5ae4d0
shipit-source-id: 80e83c05d7f78ed7e69583d7e3aa2831bd5ae4d0
Summary: We also need a more recent version of uglify that supports this
Reviewed By: martinbigio
Differential Revision: D3024959
fb-gh-sync-id: f9efdddceda4f726567c39884c844a8e74e6e09d
shipit-source-id: f9efdddceda4f726567c39884c844a8e74e6e09d
Summary: Don’t rebuild bundles automatically after they have been requested once. This helps to not lock developer machines.
Reviewed By: martinbigio
Differential Revision: D3019751
fb-gh-sync-id: 98367b4fb89c5ae22c00444eabc1194ba6832dba
shipit-source-id: 98367b4fb89c5ae22c00444eabc1194ba6832dba
Summary:Make packager transform files before extracting their dependencies.
This allows us to extract dependencies added by transforms (and to avoid including them manually).
It also allows for better optimization and to get rid of the “whole program optimization” step:
This diff utilizes the new worker introduced in D2976677 / d94a567 – that means that minified builds inline the following variables:
- `__DEV__` → `false`
- `process.env.NODE_ENV` → `'production'`
- `Platform.OS` / `React.Platform.OS` → `'android'` / `'ios'`
and eliminates branches of conditionals with constant conditions. Dependency extraction happens only after that step, which means that production bundles don’t include any modules that are not used.
Fixes#4185
Reviewed By: martinbigio
Differential Revision: D2977169
fb-gh-sync-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
shipit-source-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
Summary:This limits the number of spawned transformation workers depending on the number of available cores (`n`):
```
n < 3 → n
n < 8 → floor(3/4 * n)
n < 24 → floor(3/8 * n + 3) // factor going from 3/4 to 1/2
n >= 24 → floor(n / 2)
```
Reviewed By: bestander
Differential Revision: D2999894
fb-gh-sync-id: 0163240b5f066432f9ba07161c0dfa2ec767ba58
shipit-source-id: 0163240b5f066432f9ba07161c0dfa2ec767ba58
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 adds a new worker implementation that
- uses the existing transforms to transform code
- optionally inline `__DEV__`, `process.env.NODE_ENV`, and `Platform.OS`
- optionally eliminate branches of conditionals with constant conditions
- extracts dependencies
- optionally minifies
This will land as part of a multi-commit stack, not in isolation
Reviewed By: martinbigio
Differential Revision: D2976677
fb-gh-sync-id: 38e317f90b6948b28ef2e3fe8b66fc0b9c75aa38
shipit-source-id: 38e317f90b6948b28ef2e3fe8b66fc0b9c75aa38
Summary:In order to be able to Hot Load Redux stores and modules that export functions, we need to build infrastructure to bubble up the HMR updates similar to how webpack does: https://webpack.github.io/docs/hot-module-replacement-with-webpack.html.
In here we introduce the minimum of this infrastructure we need to make this work. The Packager server needs to send the inverse dependencies to the HMR runtime that runs on the client so that it can bubble up the patches if they cannot be self accepted by the module that was changed.
This diff relies on https://github.com/facebook/node-haste/pull/40/files which adds support for getting the inverse dependencies.
Reviewed By: davidaurelio
Differential Revision: D2950662
fb-gh-sync-id: 26dcd4aa15da76a727026a9d7ee06e7ae4d22eaa
shipit-source-id: 26dcd4aa15da76a727026a9d7ee06e7ae4d22eaa
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 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:As discussed here #1194 . This add an getter the default handler, so that custom handler can be added (monkey patch?) without overwriting the default handler
Closes https://github.com/facebook/react-native/pull/5575
Differential Revision: D2948994
fb-gh-sync-id: 2b6d1619cfe68f78b326c6d232b9bf57c489c45d
shipit-source-id: 2b6d1619cfe68f78b326c6d232b9bf57c489c45d
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: Users don't know what an accept callback is. Lets be more explicit on what type of modules we currently support hot loading.
Reviewed By: weicool
Differential Revision: D2945438
fb-gh-sync-id: d0fc228ab23833371f8fbbd86ed18e81c8ba0ebf
shipit-source-id: d0fc228ab23833371f8fbbd86ed18e81c8ba0ebf
Summary:public
At the moment, the packager's cache can only be broken by changing packager's `package.json` version,by supplying a different `cacheKey` or by updating the `mtime` of the transformer. We need to add support for breaking the cache key when a plugin the transformer use gets updated. To do so, lets introduce a property on the transformer, namely `cacheKey`.
Reviewed By: davidaurelio
Differential Revision: D2940267
fb-gh-sync-id: 82c937d06c73abd32708bf97afe5f308c2a3b565
shipit-source-id: 82c937d06c73abd32708bf97afe5f308c2a3b565
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:
public
Remove the unused feature for async dependencies / bundle layouts. We can bring it back later, if needed.
Reviewed By: cpojer
Differential Revision: D2916543
fb-gh-sync-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
shipit-source-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
Summary:
The bundler class had duplicated code and parts that were hard to follow, because functions accepted heterogenous arguments, leading to a lot of conditionals.
This commit tries to remove duplication between build steps of different type of bundles, and by accepting less different types of arguments. These differences are now handled further up the call stack.
public
Reviewed By: sebmarkbage
Differential Revision: D2905807
fb-gh-sync-id: ef85ea0d461a9a06a4a64480e014a5324c4ef532
Summary:
Now that String.prototype.includes is there, we should remove the .contains one which has not been standardized.
For fb reviewers, this needs to land after D2910339 which updates internal callsites.
Closes https://github.com/facebook/react-native/pull/5794
Reviewed By: svcscm
Differential Revision: D2910855
Pulled By: vjeux
fb-gh-sync-id: 8fd216222385f038995d1ed10e8a2c4c34c7e928
Summary:
public
The packager currently assumes that all assets that are not JSON or JS files must be images. Although it is possible to add other extension types, they crash the packager if you try to require them, because it attempts to get their dimensions, assuming that they are an image.
This is a crude workaround for that problem, which skips the image-specific processing for non-image assets, but really it would be better if the packager was properly aware of different asset types and treated them differently (e.g. for sounds it could include the duration, for HTML pages it could parse and include linked CSS files, etc).
I've also added an example of using `require('...')` to load a packager-managed HTML page in the UIExplorer WebView example. In future I anticipate that all static asset types (sounds, fonts, etc.) could be handled in this way, which allows them to be edited or added/removed on the fly instead of needing to restart the app.
Reviewed By: martinbigio
Differential Revision: D2895619
fb-gh-sync-id: cd93794ca66bad838621cd7df3ff3c62b5645e85
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:
node-haste shouldn't ever call process.exit and should leave it up to clients to shut down properly. This change just moves it out into the `Resolver` class – I'll leave it up to David and Martin to improve error handling for the rn packager :)
public
Reviewed By: davidaurelio
Differential Revision: D2889908
fb-gh-sync-id: 6f03162c44d89e268891ef71c8db784a6f2e081d
Summary:
Right now, a mock called `debug.js` shadows a node module called `debug`. When I made mocking more strict I didn't realize that it didn't include those mocks any more because requiring `debug` would result in a module like `debug/node.js` which doesn't have a mock associated with it. This diff changes it so it looks at the associated `package.json` to match the name up to mocks. This is the least invasive non-breaking change I can make right now. Yes, mocking strategies are basically fucked but I don't want the haste2 integration to have even more breaking changes right now. Consider this code to be temporary, I'll fix this and make the mocking system more sane mid-term.
public
Reviewed By: davidaurelio
Differential Revision: D2889198
fb-gh-sync-id: 58db852ed9acad830538245f7dc347365fe4de38
Summary:
Uses `fastfs.readWhile` to build the haste map
- cuts the time needed to build the haste map in half
- we don’t need to allocate memory for all JS files in the tree
- we only read in as much as necessary during startup
- we only read files completely that are part of the bundle
- we will be able to move the transform before dependency extraction
public
Reviewed By: martinbigio
Differential Revision: D2890933
fb-gh-sync-id: 5fef6b53458e8bc95d0251d0bcf16821581a3362
Summary:
The feature added in D2862850 only adds the module that requests shallow dependency resolution to the dependencies of a module. The reason why this is happens is because `collect` calls `response.addDependency` but if `recursive` is set to `false`, dependencies don't call `collect` and therefore don't get added to the resolution response. This fixes it by adding dependencies outside of the `collect` call.
public
Reviewed By: davidaurelio
Differential Revision: D2885152
fb-gh-sync-id: 8ab3b6c6b7cd45d59615a99ac87984a41b5d7025
Summary:
This syncs a couple of changes from GitHub that are necessary for jest:
* Expose `set` on Cache
* Add a function to `getAllModules` from the graph
* Explicitly dontMock `graceful-fs` in the fastfs test. node-haste2 has this manual mock which is still used in automocked tests (ugh!).
public
Reviewed By: davidaurelio
Differential Revision: D2885112
fb-gh-sync-id: b2060d5474ebee5aa13e6ba2bdf5879b46f3fd5f
Summary:
The FS as seen by an instance of a dependency graph is useful for clients of node-haste. This provides an accessor to fastfs so that the partial view of the filesystem can be queried. I was thinking of splitting out the fastfs creation to outside the constructor but the necessary refactoring doesn't seem worth it. The fastfs is intrinsically tied to the dependency graph and the `DependencyGraph` instance is meant to be a base-class for clients anyway. Both in react-packager and jest we are wrapping it with higher-level client specific containers, Resolver and HasteResolver respectively.
public
Reviewed By: davidaurelio
Differential Revision: D2885217
fb-gh-sync-id: 47a408b2682516bee9d6a4e6c61b9063817aaf22
Summary:
public
This fixes the problem that graceful-fs exposes an unpatched `close()` method, that will never trigger retries.
This behavior deadlocks the packager when trying to use graceful-fs’s `open()`/`read()`/`close()` methods.
See: isaacs/node-graceful-fs#56
Reviewed By: cpojer
Differential Revision: D2885512
fb-gh-sync-id: 71112d2488929bf1775fe9f8566fa03fd66b6bea
Summary:
Jest needs this for efficient caching of resolution responses.
public
Reviewed By: voideanvalue
Differential Revision: D2873291
fb-gh-sync-id: fee27d2ffdfe64bd68fdb4d9e4259e721b33631f
Summary:
public
The HMR listener needs to be invoked on the non debounced callback to avoid loosing updates if 2 files are updated within the debounce configured time.
Also, improve the time it takes to send HMR updates by avoiding rebuilding the bundle when the listener is defined. Instead just invalidate the bundles cache so that if the user reloads or disables Hot Loading the packager rebuilds the requested bundle.
Reviewed By: davidaurelio
Differential Revision: D2863141
fb-gh-sync-id: 3ab500eacbd4a2e4b63619755e5eabf8afdd1db9
Summary:
public
At the moment, when the user changes a file we end up pulling the dependencies of the entry point to build the bundle. This could take a long time if the bundle is big. To avoid it, lets introduce a new parameter to `getDependencies` to be able to avoid processing the modules recursively and reuse the resolution responseto build the bundle.
Reviewed By: davidaurelio
Differential Revision: D2862850
fb-gh-sync-id: b8ae2b811a8ae9aec5612f9655d1c762671ce730
Summary:
public
Adds the new polyfill to the relevant tests (Resolver/BundlesLayout)
Reviewed By: martinbigio
Differential Revision: D2878697
fb-gh-sync-id: 9681f16dd19a0b337aac63101450c703bf387346
Summary:
public
Adds the ability to read files partially with `readWhile` to `Fastfs`
This feature will be used by for building the haste map, where we only need to read the doc block (if present) to extract the provided module name.
Reviewed By: martinbigio
Differential Revision: D2878093
fb-gh-sync-id: 219cf6d5962b89eeb42c728e176bf9fcf6a67e9c
Summary:
public
`babel-plugin-react-transform` doesn't support to run on transformed code (it doesn't detect some react components). The reason why HMR was originally on the internal transform was so that it worked with non JS code (TypeScript, Coffeescript, etc), but looks like this is not very popupar in the community, maybe because the JS ecosystem is getting better everyday.
So long story short, for now lets move HMR to the external transformer. This should also give us a perf boost.
Reviewed By: davidaurelio
Differential Revision: D2870973
fb-gh-sync-id: 68ca8d0540b88b9516b9fef10643f93fc9b530d2
Summary:
public
This adds an option to `Module` (and its callers) that allows to transform code before extracting dependencies. The transform function has to return a promise that resolves to an object with `code`, and optionally `dependencies` and/or `asyncDependencies` properties, if standard dependency extraction cannot be applied
Reviewed By: cpojer
Differential Revision: D2870437
fb-gh-sync-id: 806d24ba16b1693d838a3fa747d82be9dc6ccf00
Summary:
With an upgraded Babel dependency, failing tests correctly found this typo.
It does not currently cause a test failure in the current version of master, however,
which is concerning. I found it when testing #5214.
cc martinbigio just because it was your code :)
Closes https://github.com/facebook/react-native/pull/5601
Reviewed By: svcscm
Differential Revision: D2876386
Pulled By: androidtrunkagent
fb-gh-sync-id: 378da39be79ac1b9a950ea9a7442ac24c0c3a87d
Summary:
public
To make sourcemaps work on Hot Loading work, we'll need to be able to serve them for each module that is dynamically replaced. To do so we introduced a new parameter to the bundler, namely `entryModuleOnly` to decide whether or not to process the full dependency tree or just the module associated to the entry file. Also we need to add `//sourceMappingURL` to the HMR updates so that in case of an error the runtime retrieves the sourcemaps for the file on which an error occurred from the server.
Finally, we need to refactor a bit how we load the HMR updates into JSC. Unfortunately, if the code is eval'ed when an error is thrown, the line and column number are missing. This is a bug/missing feature in JSC. To walkaround the issue we need to eval the code on native. This adds a bit of complexity to HMR as for both platforms we'll have to have a thin module to inject code but I don't see any other alternative. when debugging this is not needed as Chrome supports sourceMappingURLs on eval'ed code
Reviewed By: javache
Differential Revision: D2841788
fb-gh-sync-id: ad9370d26894527a151cea722463e694c670227e
Summary:
This reverts commit 888749220dac26382412f2c38ac5f9205cc842e5.
The original commit didn't handle cases like .(ios|android|native).js, and vjeux is in favor of standardizing on .js instead of custom extensions like .jsx or .es6 everywhere.
> Unfortunately this pull request doesn't implement with .ios.jsx. But, when/if it does, it raises more questions like what happens if you have both ios.js and ios.jsx?
>
> Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. We now live in a world where we have many transforms for es6, flow, jsx... Why would we add .jsx but not .flow or .es6. Supporting more extensions is only going to fragment tools even more.
https://github.com/facebook/react-native/pull/5233#discussion_r49682279
Closes https://github.com/facebook/react-native/pull/5296
Reviewed By: svcscm
Differential Revision: D2830784
Pulled By: bestander
fb-gh-sync-id: 9a7a4745803acbcbc5dba176b971c629c904bacd
Summary:
public
This is needed to bring numerical module IDs back.
The numerical ID of the main module will always be `0` and is therefore of no use when used as conditional. We have to pass on the name, which will be preserved, when requesting transform options.
Reviewed By: martinbigio
Differential Revision: D2855106
fb-gh-sync-id: f9bc40e753b1b283ce0b00068e3c9964a541ad9b
Summary:
public
The reverted change doesn’t play nice with inline requires, let’s revert it for now.
I will bring it back after fixing it or adapting inline requires
Reviewed By: martinbigio
Differential Revision: D2854771
fb-gh-sync-id: 32fdbf8ad51240a9075b26502decb6328eed4b29
Summary:
public
Adds two feature to the require implementation for unbundled code:
- Ports Systrace from `require.js`
- Prevents already loaded modules from being overwritten by repeated calls to `nativeRequire` with the same ID
Reviewed By: martinbigio
Differential Revision: D2850345
fb-gh-sync-id: 122e2d5d4a64b2e868d4cf6e5079810f59b1db18
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
Summary:
public
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2842418
fb-gh-sync-id: 97addd28e964ac5f2b5081dcd3f36124d2864df8
Summary:
public
We had a bug a few weeks ago which caused transform errors not to be shown properly. The problem was on this piece of code, so lets unit test it.
Reviewed By: davidaurelio
Differential Revision: D2849990
fb-gh-sync-id: 9f6bb8a8b7d59bbaa3577c29cee37fb23a50d66f
Summary:
There's a long standing issue on open source (https://github.com/facebook/react-native/issues/4968). Until someone gets some free bandwidth to fix it lets at the very least improve the error message to guide users to the issue and suggest workarounds.
public
Reviewed By: mkonicek
Differential Revision: D2849051
fb-gh-sync-id: ef7913442ceabcab2076141bd13ab1ceeb529759
Summary:
At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one.
This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed.
This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16Fixes#5316
Closes https://github.com/facebook/react-native/pull/5422
Reviewed By: svcscm
Differential Revision: D2846422
Pulled By: davidaurelio
fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56
Summary:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
public
- Tweak OSS server to enable the HMR connection
- Remove client gating code.
- Resolve internal transforms plugins
After this diff, Hot Loading should work on OSS.
Reviewed By: javache
Differential Revision: D2803620
fb-gh-sync-id: b678180c884d2bfaf454edf9e7abe6b3b3b32ebe
Summary:
We used to only cache the `dependencies` and `name` of a Module but we were actually accessing two more fields (async dependencies and the `isHaste` field) which meant we were always reading every single file from disk. In D2644383 I noticed that but realized that the Promise was cached, meaning we would read every file once *per instance* and I didn't think about cross-instance reads over time. My initial version added more caching (but also missed the `isHaste` field) but then I got rid of the cache call for `dependencies`. So my change from before didn't make anything worse but it also didn't make anything better. This change now caches everything until the contents of the file actually changes.
public
Reviewed By: martinbigio
Differential Revision: D2831569
fb-gh-sync-id: 74081abc0ce3ca96b4e56c3c9b6d24aa84f7496c
Summary:
It's possible that a mock doesn't have an associated real module that it maps to. This is actually very common in www, where we have JS mocks for dynamic PHP JS modules. The implementation I chose seems like the smartest one for now: if a module cannot be resolved, we look up whether we have a mock with the same id. If we do, we just resolve it. That's it! And it also only does the minimum amount of resolution necessary.
public
Reviewed By: martinbigio
Differential Revision: D2822277
fb-gh-sync-id: 7c9fbb6f69a0c0c85157c0650f5719d94a02410e
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:
public
Fixes a terrible bug due to which when Hot Loading enabled when the user reloads we'll serve them the first `hot` bundle he requested. This happened because when HMR enabled we bailed out after sending the HMR updates and didn't rebuild any of the bundles the user requested before. As a consequence, when they reload we'd sent him the first and only one we ever built.
The fix is to tweak the hmr listener to return a promise. This way we can run the remaining code on the file change listener just after the HMR stuff finishes. We need to do it this way to avoid the remaining stuff to compete for CPU with the HMR one and give the best possible experience when HMR is enabled.
Reviewed By: davidaurelio
Differential Revision: D2811382
fb-gh-sync-id: 906932d71f35467485cf8a865a8d59f4d2ff41a0
Summary:
public
We're not planning to accept file removals in the short term on the HMR interface so lets bail when a file is removed (before this this we were throwing when trying to get the shallow dependencies).
Reviewed By: yungsters
Differential Revision: D2810534
fb-gh-sync-id: f2733382f4a2619e22bdf1163aa4180694fff9f8
Summary:
public
We want to support Hot Loading on the packager itself instead of on the transformer. This will allow us to enable it on OSS (and for any scripting language, yay!).
For now to enable Hot Loading the packager's internals transforms need to be manually enabled (start packager with `--enable-internal-transforms`). I think the internal pipeline should always be enabled as it doesn't affect performance if there're no transforms and the user can disable Hot Loading through the setting on the app though. I'll tweak this on a follow up commit.
Reviewed By: vjeux
Differential Revision: D2801343
fb-gh-sync-id: 563984d77b10c3925fda6fd5616b814cdbea2c66
Summary:
public
Requires are transformed when building the bundle but we forgot doing so when building the HMR one.
Reviewed By: vjeux
Differential Revision: D2801319
fb-gh-sync-id: ae70612945ab81a05154b14d6b756ef390770542
Summary:
public
Fixes an issue on the transforms pipeline which caused not to pipe errors that occured on the external transformer to JSTransformer.
Reviewed By: yungsters
Differential Revision: D2806498
fb-gh-sync-id: c9347d1957a3a9320b3f177ff9b19bf3802087a0
Summary:
public
Before this diff we were only accepting the module that was modified but the user. This works fine as long as the user doesn't modify the dependencies a module has but once he starts doing so the HMR runtime may fail when updating modules' code because they might might a few dependencies. For instance, if the user changes the `src` a `Image` has to reference an image (using the new asset system) that wasn't on the original bundle the user will get a red box. This diff addresses this by diffing the modules the app currently has with the new ones it should have and including all of them on the HMR update. Note this diffing is only done when the we realize the module that was modified changed it's dependencies so there's no additional overhead on this change.
Reviewed By: vjeux
Differential Revision: D2796325
fb-gh-sync-id: cac95f2e995310634c221bbbb09d9f3e7bc03e8d
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary:
We don't (yet) treat these the same as any other modules because we still have special resolution rules for them in the packager allowing the use of `providesModule`, but I believe this allows people to use npm react in their RN projects and not have duplicate copies of React. Fixesfacebook/react-native#2985.
This relies on fbjs 0.6, which includes `.flow` files alongside the `.js` files to allow them to be typechecked without additional configuration. This also uses react 0.14.5, which shims a couple of files (as `.native.js`) to avoid DOM-specific bits. Once we fix these in React, we will use the same code on web and native. Hopefully we can also remove the packager support I'm adding here for `.native.js`.
This diff is not the desired end state for us – ideally the packager would know nothing of react or fbjs, and we'll get there eventually by not relying on `providesModule` in order to load react and fbjs modules. (fbjs change posted here but not merged yet: https://github.com/facebook/fbjs/pull/84.)
This should also allow relay to work seamlessly with RN, but I haven't verified this.
public
Reviewed By: sebmarkbage
Differential Revision: D2786197
fb-gh-sync-id: ff50f28445e949edc9501f4b599df7970813870d
Summary:
These are the sources, not the target. Copy pasta from above.
Closes https://github.com/facebook/react-native/pull/4989
Reviewed By: svcscm
Differential Revision: D2795198
Pulled By: spicyj
fb-gh-sync-id: 61c52add02cb877284fbf62a4344361b5bf44515
Summary:
public
Before this this when a file was changed besides sending the HMR update we rebuild every single bundle that the packager had build (to serve it faster when the user hit cmd+r). Since when hot loading is enabled we don't do cmd+r all this work was pointless (except for when you're developing multiple apps using the same packager instance at the same time, which we can assume is very uncommon). As a consequence, the HMR update was competing with the rebundling job making HMR quite slow (i.e.: on one huge internal app it took up to 6s for the HMR changes to get applied).
So, this diff tweaks the file change listener so that we don't rebundle nor invoke the fileWatchers (use for live reload which is also useless when hot load is enabled) when hot loading is enabled. Also, it makes the HMR listener more high pri than the other listeners so that the HMR dev experience is as good as it can get.
Reviewed By: vjeux
Differential Revision: D2793827
fb-gh-sync-id: 724930db9f44974c15ad3f562910b0885e44efde
Summary:
public
Compute the dependencies of the bundle entry file just before sending HMR updates. In case the file that was changed doesn't belong to the bundle bail.
Reviewed By: vjeux
Differential Revision: D2793736
fb-gh-sync-id: f858e71b0dd5fe4f5b2307a22c6cef627eb66a22
Summary:
public
Until we support this fature on OSS, don't show the menu option.
Reviewed By: vjeux
Differential Revision: D2791198
fb-gh-sync-id: 11b66d467c1ab784bbf549b893d0a3abd69e2741
Summary:
public
Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end:
- Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle.
- On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :).
- Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu.
- Add packager `hot` option.
- Include gaeron's `react-transform` on Facebook's JS transformer.
The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142)
I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889).
Reviewed By: vjeux
Differential Revision: D2790806
fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
Summary:
public
Add a very simple runtime for self-accepting modules. The API is the same one as Webpacks's one for now.
The new infra will be end-to-end tested on a follow up diff.
Reviewed By: vjeux
Differential Revision: D2789428
fb-gh-sync-id: c39524814d53c6e4ec9d9d011081ea81089b00b6
Summary:
public
This diff adds infra to both the Packager and the running app to have a WebSocket based connection between them. This connection is toggled by a new dev menu item, namely `Enable/Disable Hot Loading`.
Reviewed By: vjeux
Differential Revision: D2787621
fb-gh-sync-id: d1dee769348e4830c28782e7b650d025f2b3a786
Summary:
public
The Whole Program Optimisation (WPO) pass is quite slow, and can make it painful
to iterate when having `dev=false`. Move it to happen only when both `dev=false` and `minify=true`.
Reviewed By: davidaurelio
Differential Revision: D2773941
fb-gh-sync-id: ac5ca4e1286e233c2d175eecdbf7494d5d3497b2
Summary:
There's quite a bit of code scattered around the packager regarding ignoring the `providesModule` Haste pragma in any file that isn't in `react-native`, `react-tools` or `parse`. There is even a (passing) test case.
However, there's an edge case.
Take, for example, `fbjs`. It has a module inside of it called `ErrorUtils`. `react-relay` requires this file normally, in Common.JS style, by doing `require('fbjs/libs/ErrorUtils')`. But when `react-native` attempts to require `ErrorUtils` using the HasteModule format (in it's JavaScript initialization), it resolves the `fbjs` `ErrorUtils` module, instead of RN's `ErrorUtils`.
This happens, it turns out, because when a module is read (in `Module._read`), it's not caring about whether or not it should pay attention to `providesModule`, and is just assigning the `providesModule` value as the id of the module no matter what. Then when `Module.getName` is called, it will always use that `data.id` that was set, thus creating the wrong dependency tree.
This
Closes https://github.com/facebook/react-native/pull/3625
Reviewed By: svcscm
Differential Revision: D2632317
Pulled By: vjeux
fb-gh-sync-id: efd8066eaf6f18fcf79698beab36cab90bf5cd6d
Ovidiu Viorel Iepure
David Aurelio
Jing Chen
ColCh
Nikhilesh Sigatapu
Spencer Ahrens
androidtrunkagent
Christoph Pojer
Mark Oswald
Konstantin Raev
Johannes Stein
Alex Kotliarskyi
Benoit Lemaire
Marc Horowitz
Tim Yung
Yann Pringault
Eric Rozell
Martín Bigio
Pieter De Baets
Steven Luscher
Alexander Micklewright
Mike Grabowski
Tadeu Zagallo
Leland Richardson
Sam Swarr
Thomas Aylott
Adam Miskiewicz
Nick
Janic Duplessis
Mart?n Bigio
Satyajit Sahoo
Steven Chaitoff
Shayne Sweeney
Kureev Alexey
Steve Kellock
Qiao Liang
Christopher Chedeau
Corentin Smith
Nick Lockwood
Austin Kuo
Dmitry Soshnikov
Dave Miller
Mark Vayngrib
James Ide
tfallon@mail.depaul.edu
Martin Konicek
Jan Kassens
Kyle Corbitt
Kelvin De Moya
Ben Alpert
wvengen
Ben Alpert
Adam Miskiewicz
