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 888749220d.
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
David Aurelio
Martín Bigio
Adam Miskiewicz
Christoph Pojer
Steve Kellock
Qiao Liang
Christopher Chedeau
Corentin Smith
Nick Lockwood
Austin Kuo
Dmitry Soshnikov
Dave Miller
Mark Vayngrib
James Ide
