Summary: @public
The legacy 'isStatic' property for image sources is no longer used anywhere in our codebase, but was still being generated by the packager and referenced in the JS in various places.
This diff removes all the remaining references.
Reviewed By: @frantic
Differential Revision: D2531263
fb-gh-sync-id: 0bba0bb8473b1baa908ef7507cbf6d83efb0d9ee
Summary: @public
This was a hard one, bare with me on the full story of what happened.
We recently started writting additional JS scripts in ES6 for the cli. These code needs to be transformed by babel before we execute it as we don't run node with `--harmony`. To do so we removed the `only` attribute on the `babel-register`. Turns out this broke the packager on oss as if no `only` not `ignore` parameter is specified babel will ignore `node_modules`. Since on oss when a project is created `react-native-github` is located inside of `node_modules` we started getting syntax errors.
The fix is to include separately all the different paths we need to make sure babel transforms each of them. We cannot simply have a single `babel-core/register` as we need to include paths that belong both to oss and internal only. So, we need to have multiple `register` invocations. Since babel does not accumulate the `only` you send on every invocation we need to build a small wrapper to do so.
Reviewed By: @frantic
Differential Revision: D2522426
fb-gh-sync-id: 379a7bb169c7d5cb3002268742de269238bba766
Summary: @public
The source maps generated by uglify are already stringified, and therefore were
being stringified twice.
Reviewed By: @martinbigio
Differential Revision: D2498242
Summary: @public
Dead-lock trying to read package.json because it's both a "module" and a "package". in `Module.getName` it uses the cache key "name" and tries to call `Package.getName` which uses the same cache key and we end up returning the same promise that we're trying to resolve resulting in a dead-lock.
This changes the cache keys for the packages that adds a prefix "package-".
Reviewed By: @vjeux
Differential Revision: D2506979
Summary: *This is a PR to fix#1939 (DependencyResolver fails to handle ES6 modules import statements with new lines)*
**This PR includes:**
- A fix to the problematic regular expression
- Updated tests that support the new line style.
**Summary:**
We found out that while the packager does its module wrapping thing for lines like this:
```js
import theDefault, { named1, named2 } from 'src/mylib';
```
It fails to do the same for multi line imports:
```js
import theDefault, {
named1,
named2
} from 'src/mylib';
```
We've tracked done the issue to a [faulty regular expression in replacePatterns.js](https://github.com/facebook/react-native/blob/master/packager/react-packager/src/DependencyResolver/replacePatterns.js#L12)
You can see various import statements with the problematic regular expression [here](http://regexr.com/3bc8m)
We've figure out a better regular expression (you can play around with it [here](http://regexr.com/3bd3s))Closes https://github.com/facebook/react-native/pull/1940
Reviewed By: @svcscm
Differential Revision: D2498519
Pulled By: @vjeux
Summary: This is an updated copy of #1993, which was approved by @vjeux but hasn't been rebased. It whitelists the es6 module syntax and updates the JS Environment docs to match. cc @ide @hkjorgensenCloses https://github.com/facebook/react-native/pull/3175
Reviewed By: @svcscm
Differential Revision: D2498360
Pulled By: @vjeux
Summary: @public
This moves us from warnings on name collisions to errors. If the error happens in initialization it will fatal out.
However, if the error happens while working (after initialization) then I did my best to make it recoverable. The rational behind this is that if you're working and you're changing names, you may introduce a duplication while moving things around. It will suck if you have to restart the server every time you do that.
Reviewed By: @frantic
Differential Revision: D2493098
Summary: @public
Since we added packager-managed assets -- internally we still think of asset dependency as a single "module". In reality there are multiple files that represent this module. This becomes important with the `getDependencies` API which is used by Buck to inform it on what to rebuild. Since `getDependencies` deals with modules, and is more of an internal API, I've introduced a new one and would go on to deprecate this.
Reviewed By: @frantic
Differential Revision: D2487207
Summary: @public
Have a top-level debug namespace: `ReactNativePackager`
And add a couple of debugs in the transformer. This is ground work for adding a verbose option.
Reviewed By: @DmitrySoshnikov
Differential Revision: D2489960
Summary: In javascriptcore(ios9), this code will run as expected(output 0 1):
```js
for(let i=0; i<2; i++) {
const data = i;
console.log(data);
}
```
But when debug in chrome, the above code will fail without `use strict` prologue (if you add prologue, rn will fail with red screen `Const declarations are not supported in strict mode`): https://code.google.com/p/v8/issues/detail?id=4432.
So it's better to transpile contant by default.
Closes https://github.com/facebook/react-native/pull/2955
Reviewed By: @svcscm
Differential Revision: D2483398
Pulled By: @vjeux
Summary: @public
Fix the haste resolution algorithm. Changed the map data structure from a list of modules, to a list of modules grouped by platform.
This considerably simplifies the "getModule" method and makes it easy to properly warn about colliding module names.
This also fixes a bug where we used to include `.web` files when we shouldn't (see task).
Reviewed By: @vjeux
Differential Revision: D2482969
Summary: @public
The issue of colliding haste modules have came up many times and have wasted countless engineering hours. This will start warning about it and will also start selecting modules at random so that people don't depend on undefined behavior.
Additionally, this surfaced an issue where with assets we may fatally throw if the directory doesn't exist. This is fixed by checking the existence of the directory before trying to match files in it.
Reviewed By: @jingc
Differential Revision: D2478480
Summary: The `react.displayName` transform was added in 93b9329b75.
That diff missed to update the `.babelrc` where the comment says it should stay
in sync (I'm not sure where it's used though). I added a comment in the other
direction so this can be prevented in the future.
I also updated the `cacheVersion` so we actually transform the code again to add
the missing displayName properties to unchanged components.
Closes https://github.com/facebook/react-native/pull/2905
Reviewed By: @vjeux
Differential Revision: D2473447
Pulled By: @kassens
Summary: Ex. When `console.log` or similar is called, this will call
the original method, which can be quite useful.
For example, under iOS, this will log to the Safari console debugger,
which has an expandable UI for inspecting objects, etc., and is also
just useful if you are using that as a REPL.
I don't believe this incurs a meaningful performance penalty unless
the console is open, but it would be easy to stick behind a flag
if that is a problem.
Closes https://github.com/facebook/react-native/pull/2486
Reviewed By: @svcscm
Differential Revision: D2472470
Pulled By: @vjeux
Summary: @public
We swallow errors like it's nobody's business :(
Having an error handler that `reject`s after the promise has been resolved is a no-op. In node, if there is no `error` event handler then the error would throw.
So after we start listening and we want to resolve the promise, we remove the error listener so that we make sure errors actually throw.
Finally, I made the `uncaughtError` handler log `error.stack` so we can get an idea of what's going on.
Reviewed By: @martinbigio
Differential Revision: D2468472
Summary: @public
I've noticed that the logs can be sometimes misleading, as when an Activity ends it doesn't log immediatly. A sync `console.log` would log before it although the Acitivity should've finished before.
Turns out we wait before writing out the logs to the console. I don't see any reason for this. Looking at the `Activity` module it's over-engineered. This diff makes logging sync and simplfies the module.
Reviewed By: @martinbigio
Differential Revision: D2467922
Summary: I think packager on different platform should generate same output if possible. So packager should replace '\\' in module name with '/' on Windows.
Closes https://github.com/facebook/react-native/pull/2813
Reviewed By: @svcscm
Differential Revision: D2458634
Pulled By: @martinbigio
Summary: @public
The server dies after 30 seconds if it has no jobs on it's queue. The problem is that the jobs counter gets decreased before returning the bytes to the client. As a consequence, it's possible that the server dies while it's returning the bytes to the client, or just after it finished returning the bytes to the client.
To avoid both issues lets move the counter decrease a few lines below and bump the timer to make sure we have time to fully write the bytes on the socket and let the client close the connection before the server dies.
Reviewed By: @vjeux
Differential Revision: D2445264
Summary: @public
Invoking an extra promise caused failures in the promise-based tests. This fixes them.
Reviewed By: @vjeux
Differential Revision: D2432431
Summary: how did this ever work?
All build jobs must pass in the platform argument.
This also turns the "platform" argument into a required one.
I added a task to infer the platform argument from the filename here: t8306875
Reviewed By: @martinbigio
Differential Revision: D2425114
Summary: When we updated joi, the error message was changed. I removed the content to prevent similar errors in the future.
Reviewed By: @amasad
Differential Revision: D2424048
Summary: @public
The profiler helper shouldn't live inside the packager itself, move
it to the packager.js file with other middlewares.
Reviewed By: @martinbigio
Differential Revision: D2424878
Summary:
1. When the server starts up, it only gives itself 30 second to live before receiving any connections/jobs
2. There is a startup cost with starting the server and handshaking
3. The server dies before the client has a chance to connect to it
Solution:
1. While the server should die pretty fast after it's done it's work, we should have a longer timeout for starting it
2. I also added accompanying server logs with client connection errors
Summary:
We don't currently support platform extensions in asset modules.
This adds supports for it:
```
require('./a.png');
```
Will require 'a.ios.png' if it exists and 'a.png' if it doesn't.
Summary:
Saw an issue with a build because of an ENONT error: https://fb.facebook.com/groups/716936458354972/permalink/923628747685741/
My hypothesis:
1. We issue a ping to the socket (in SocketInterface/index.js) a decides if the available socket is alive
2. We see that it's alive but by the time we actually connect to it the server would've died
Solution:
1. The server shouldn't die as long as there are clients connected to it (currently it only stay alive as long as there are jobs)
2. The "ping" should only disconnect once the client is connected
3. Finally, have a better error message than ENOENT
Summary:
Sourcemap urls were generated as just the pathname (no options) which meant that they generated source for the wrong bundle.
Even worse, there exists a race condition when multiple request to the same bundle has different types of paltform arguments (in this case one could be 'ios' and the other is undefined). The fix will this will come later as it's more involved -- will need to refactor the dependency resolver to have a per-request state.
Summary:
Fix failing test that matches the exact error string to match using `contains`.
I was under the impression that jest tests were running in CI -- turns out not yet.
Summary:
A few potential races to fix:
1. Multiple clients maybe racing to delete a zombie socket
2. Servers who should die because other servers are already listening are taking the socket with them (move `process.on('exit'` code to after the server is listening
3. Servers which are redundant should immediatly die
Summary:
Buck (our build system) currently starts multiple packager instances for each target and may build multiple targets in parallel. This means we're paying startup costs and are duplicating the work. This enables us to start one instance of the packager and connect to it via socket to do all the work that needs to be done.
The way this is structured:
1. SocketServer: A server that listens on a socket path that is generated based on the server options
2. SocketClient: Interfaces with the server and exposes the operations that we support as methods
3. SocketInterface: Integration point and responsible for forking off the server
Summary:
The transform step in currently the longest one in the bundling process. This adds a progress bar to track the transform progress.
{F23096660}
Summary:
There are two fs steps and it wasn't clear why. This now puts the right label:
```
[9:38:25 PM] <START> Building in-memory fs for JavaScript
[9:38:27 PM] <END> Building in-memory fs for JavaScript (2030ms)
[9:38:27 PM] <START> Building in-memory fs for Assets
[9:38:27 PM] <END> Building in-memory fs for Assets (615ms)
```
Summary:
The `BundlesLayout` will be used as a persistent index. As such, it would be easier to avoid having dependencies to `Module`, `Package`, `Asset`, etc. We're not using that information for now and if we happen to need to use it we could always fetch it using the `ModuleCache`.
Summary:
We've decided to move the syntax for asynchronously requiring async dependencies. The new syntax works better with promises and therefore withe async/await as well. The new syntax looks like this: `System.import('moduleA').then(moduleA => {...});` or if you're using async/await you could simply do:
let moduleA = await System.import('moduleA');
new moduleA().someFunction();
If you need to require multiple dependencies just do:
Promise
.all([System.import('moduleA'), System.import('moduleB')])
.then((moduleA, moduleB) => {...})
or the equivalent using async/await
Summary:
Fix error in the template string (no plus, thinks it's a function).
And bump the timeout to 30 seconds because a file is taking more than 10 seconds `js/RKJSModules/Libraries/FBComponents/FBFed/FeedStoryFragments.js`
Summary:
Since JS doesn't have the guarantee that once a bundle is loaded it will stay in memory (and this is something we actually don't want to enforce to keep memmory usage low), we need to keep track of parent/child relationships on the packager to pass it down to native. As part of this diff, we also introduced an ID for each bundle. The ID for a child bundle is shynthetized as the bundleID of the parent module + an index which gets incremented every time a new bundle is created. For instance given this tree:
a,b
c f
d e g
the ID for `d` will be `bundle.0.1.2`, the one for e will be `bundle.0.1.3` and the one for `g` will be `bundle.0.5.6`. This information will be useful to figure out which bundles need to be loaded when a `require.ensure` is re-written.
Summary:
There's been a case where Babel can hang indefinitely on a file parse/transform. Possibly related to https://github.com/babel/babel/issues/2211
This adds a timeout to transform jobs and throws an error informing the user of the offending file. The timeout interval defaults to 10 seconds, but can be changed via an option.
Summary:
D2319999 introduced a regression where we stopped waiting for the "build haste map" step to finish before we accept any requests. This makes sure that we block on that.
Need to unbreak with this, but will follow up with a test to catch this in the future.
Summary:
Currently the platform selection is controlled by the blacklist. However, since we want to use the same server instance for cross-platform development, we need this to be controlled per request.
One outstanding issue, is that the DependencyGraph class wasn't designed that way and it doesn't have a per-request state. This means that with the current design race conditions is possible. If we got a request for a different platfrom while processing the previous request, we may change the outcome of the previous request.
To fix this a larger refactor is needed. I'll follow up a diff to do that.
Finally, so I don't break the universe like last time, I'll leave it up to the RN guys to update the call sites.
Summary:
Not that at the moment a module can be present in multiple bundles, so the new API will return only one of them. In the near future we'll impose the invariant that a module can only be present in a single bundle so this API will return the exact bundle in which it is.
Summary:
Instead of using plain objects and having to convert to and from them we just use the `Module` class across the codebase.
This seems cleaner and can enforce the type as opposed to fuzzy objects.
Summary:
Introduce a Bundler capable of generating the layout of modules for a given entry point. The current algorithm is the most trivial we could come up with: (1)it puts all the sync dependencies into the same bundle and (2) each group of async dependencies with all their dependencies into a separate bundle. For async dependencies we do this recursivelly, meaning that async dependencies could have async dependencies which will end up on separate bundles as well.
The output of of the layout is an array of bundles. Each bundle is just an array for now with the dependencies in the order the requires where processed. Using this information we should be able to generate the actual bundles by using the `/path/to/entry/point.bundle` endpoint. We might change the structure of this json in the future, for instance to account for parent/child bundles relationships.
The next step will be to improve this algorithm to avoid repeating quite a bit dependencies across bundles.
Summary:
This is the first step to add support for splitting the JS bundle into multiple ones. This diff adds support for keeping track of the async dependencies each module has. To do so we introduce the following syntax:
require.ensure(['dep1', 'dep2, ..., 'depN'], callback);
Where the callback function is asynchronously invoked once all the indicated modules are loaded.
Internally, the packager keeps track of every set of async dependencies a module has. So for instance if a module looks like this:
require.ensure(['dep1'], () => {...});
require.ensure(['dep2'], () => {...});
the `Module` object will keep track of each set of dependencies separately (because we might want to put them on separate bundles).
Summary:
The word Package is overloaded, it may mean npm package, or may mean a collection of bundles. Neither is what we mean. We mean `bundle`.
This renames it and modernize some of the Bundler code.
Summary:
The cache is only used for JSTransformer at the moment. We're doing IO and some computation to get each module's name, whether is a haste or node module and it's dependencies. This work happens on startup so by caching this value we shouldbe able to reduce the start up time. Lets promote the Cache to the Packager level to be able to use it by any of the components of the packager. For now, on this diff we'll start using it to cache the mentioned fields.
Also we had to introduce the concept of fields in the cache as manually merging the date we had for each path is not possible as we're using promisses all around. With the new API, each field is a promise.
@amasad and I did some manual testing to measure the impact of this change and looks like it's saves 1 second when building the haste map (which represents 50% of the time). Overall this reduces 1 second of start up time which was currently about 8s on my mac book pro.
Summary:
- Enables async/await in .babelrc and transformer.js
- Adds regenerator to package.json. Users still need to explicitly require the regenerator runtime -- this is so that you only pay for what you use.
- Update AsyncStorage examples in UIExplorer to use async/await
- Update promise tests in UIExplorer to use async/await in addition to the promise API
Closes https://github.com/facebook/react-native/pull/1765
Github Author: James Ide <ide@jameside.com>
Summary:
Teach the resolver about platform-based resolution. The platform extension is inferred from the entry point.
It works for haste modules, as well as node-based resolution.
Summary:
[This is a preview diff for getting RN's tests to pass with a future version of jest that supports io.js and other future versions of Node. This can be merged once the diff to update jest is merged upstream and published.]
Updates the tests in small ways so they run on io.js with two updates:
- The Cache test which relies on Promises uses `runAllImmediates` for modern versions of Node because bluebird uses `setImmediate` instead of `process.nextTick` for Node >0.10.
Closes https://github.com/facebook/react-native/pull/1382
Github Author: James Ide <ide@jameside.com>
Test Plan: Run `npm test` with the latest version of jest.
Summary:
@public
Now that watchman perf issue was fixed we can enable watchman-based fs crawling which is faster than node.
This showed an existing issue with some files missing from the blacklist which I addressed.
Test Plan:
./fbrnios.sh run
click around and scroll all the apps
Summary:
@public
We have a function that detects whether a give file is to be treated as a node_modules. If so it doesn't have access to the haste module map. There is an exception to this rule which is a few modules that are allowed to do that. Currently thats react-native, react-tools, and parse.
The current implementation had a bug where if you had `react-native` (or react-tools etc) in the name before the actual package root then the detection will be off. This fixes the problem by starting from the `lastIndexOf('node_modules')` directory, that way nothing confuses us.
Test Plan:
./runJestTests.sh
export OSS, patch, run e2e test
Summary:
@public
The current output of console.log is extremely bad. If you pass NaN, it shows up as null (super confusing I know -_-), if you pass a cyclical object, it just says that it is cyclic and that's it. It doesn't print up the first few levels which are NOT cyclical and would be really helpful.
It turns out that nodejs console.log pretty printer is really awesome and can be easily extracted as a few hundred lines. This is going to be such a productivity boost that I think it's the right tradeoff to embed it like this
Test Plan:
```
var a = {kikoo: {lol: 1}}
a.kikoo.nice = a;
console.log(a);
> { kikoo: { lol: 1, nice: [Circular] } }
console.log(NaN)
> NaN
```
Summary:
@public
corrected small typo in the 500 response from the packager server
Test Plan: add throw to promise function prior to error handler, run packager, cache a bundle with bundle extension URI, open /debug/packages, see clean 500 error
Summary:
@public
Fixes#773, #1055
The resolver was getting a bit unwieldy because a lot has changed since the initial writing (porting node-haste).
This also splits up a large complex file into the following:
* Makes use of classes: Module, AssetModule, Package, and AssetModule_DEPRECATED (`image!` modules)
* DependencyGraph is lazy for everything that isn't haste modules and packages (need to read ahead of time)
* Lazy makes it fast, easier to reason about, and easier to add new loaders
* Has a centralized filesystem wrapper: fast-fs (ffs)
* ffs is async and lazy for any read operation and sync for directory/file lookup which makes it fast
* we can easily drop in different adapters for ffs to be able to build up the tree: watchman, git ls-files, etc
* use es6 for classes and easier to read promise-based code
Follow up diffs will include:
* Using new types (Module, AssetModule etc) in the rest of the codebase (currently we convert to plain object which is a bit of a hack)
* using watchman to build up the fs
* some caching at the object creation level (we are recreating Modules and Packages many times, we can cache them)
* A plugin system for loaders (e.g. @tadeuzagallo wants to add a native module loader)
Test Plan:
* ./runJestTests.sh react-packager
* ./runJestTests.sh PackagerIntegration
* Export open source and run the e2e test
* reset cache
* ./fbrnios.sh run and click around
Summary:
@public
We cached based on url, which wasn't unique becuase some options would be defaulted. This was obvious when starting the server via fbrnios which tries to warmup the bundle.
And then when the device woke up it will send a request (that is identical in reality) but would miss the cache.
This changes the cache key into a JSON stringification of the options.
Test Plan:
* ./runJestTests.sh
* ./fbrnios.sh run
Summary:
@public
Fixes#1431Fixes#1005
Files with no newlines and a comment at the end of the file would've caused a syntax error in the bundle:
```js
__d('module', function() {
hi();
// wow })
```
This fixes the issue by inserting a new lines before `})`.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PackagerIntegration
* open app to the playground app
* add an error
* observe that the redbox has the correct lines
Summary:
@public
Fixes#773
This fixes `.json` name resolution. And also reads `package.json` when doing a directory module resolution.
The algorithm can be found here: https://nodejs.org/api/modules.html
I'll probably start including the node (or browserify) modules test in later diffs to make sure we're fully compliant.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PackagerIntegration
* open playground and require a json file
* test redbox
Summary:
@public
Fixes issue #1055
For some historical reason we used to strip the extension of the module name before passing it to `resolveDependency` which is completly capable of handling all kinds of names. The fix is one line, but added a few tests for this.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PacakgerIntegration
* Open app and click around
Summary:
@public
The packager's resolver started out imitating node-haste, which meant that we didn't support nested modules. Now this is a problem. Bigger projects are bound to have versions of different versions of the same package at different levels of the dependency tree. This
makes loading dependencies lazy for node_modules and implements the node resolution algorithm. However, it also mantains that some
modules are still "haste" format, which currently defaults to "react-native" and "react-tools".
Finally, this means ~5 seconds speed up on every server start. This should also have a big impact on open source users with projects with big node_modules.
Test Plan:
1- test the app with --reset-cache
2- click around test and production apps
3- update the OSS library
4- create a new project
5- npm install multiple modules
6- create some version conflict in your project
7- make sure we do the "right" thing
8- test file changes to make sure it works
Summary:
@public
Previously, we had to use errors as a property on the result object because there was no way to pass custom props between
the child worker and the parent. This has been fixed in node-worker-farm (D2092153) and now we can use regular errors.
This also adapts the transformer to babel-specific errors. Generic errors, however, should still work and render readable
info.
Additionally, I deprecated, but maintained backwards compatiblity for people in OSS that are using custom transformers.
Test Plan:
1. `./runJestTests.sh`
2. `./runJestTests.sh PackagerIntegration`
3. open the playground app
4. Add a syntax error. Say `1=x` somewhere in the file
5. Reload and see error message 'SyntaxError <filename> description (line:col)'
6. Make sure that the stack trace is clickable and it attempts to open the editor to the location
Summary:
@public
1. Default to first class support of popular image formats
2. Add tests to make sure we support other than png
Test Plan:
1. ./runJestTests.sh
2. Add test.png and test.jpg images in the Playground app dir
3. require both images and render then in the playground app
4. they render
Nick Lockwood
Martín Bigio
Tadeu Zagallo
Amjad Masad
shlomiatar
Kyle Corbitt
Pieter De Baets
yiminghe
Justin Spahr-Summers
Jan Kassens
Charlie Cheever
Christoph Pojer
DengYun
mqli
facebook-github-bot-6
Christopher Chedeau
Alex Kotliarskyi
Spencer Ahrens
Martin Konicek
Natansh Verma
Krzysztof Magiera
Ben Alpert
Felix Oghină
Felix Oghină
Evan Solomon
Thomas Aylott
James Ide
Dave Sibiski
Jing Chen
Forbes Lindesay
Bill Fisher
Eric Vicenti