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: There are a few small bugs with the code that launches the editor from the packager:
* First of all, the filepath is not escaped which means tokens like `(` or spaces will mess up the process execution. Dropbox unfortunately decided to use spaces in its enterprise product, so I was getting this error:
![screen shot 2015-07-11 at 3 20 54 pm](https://cloud.githubusercontent.com/assets/1135007/8635748/186e7f2e-27ea-11e5-8058-1f4dabb79634.png)
* Next, the line number argument formatting was assumed to be in a specific format (`:%d`) which actually errors out vim and other editors.
* Lastly, the process was started synchronously but not attached to the stdin / stdout of the parent process. This means that only editors like mvim, sublime, and others would work since they spawn a new window. Editors like emacs, vi, nano, etc wouldn't work and instead just hang at the command line.
So I whipped up this diff to fix a number of these issues, demo here:
http://recordit.co/M6zwiUj7hp
The demo shows both
Closes https://github.com/facebook/react-native/pull/1957
Reviewed By: @vjeux, @pcottle
Differential Revision: D2420941
Pulled By: @frantic
Summary: @public
Invoking an extra promise caused failures in the promise-based tests. This fixes them.
Reviewed By: @vjeux
Differential Revision: D2432431
Summary: @public
Migrate scripts to open source and add new route on the packager
to directly convert profiler outputs to a devtools compatible format.
Reviewed By: @jspahrsummers
Differential Revision: D2425740
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:
Some messages are special and are intended for the devtools, like `{$open: id}` and `{$error: id}`. The main debugger-ui page can't handle these and thinks something is wrong when `object.method` is undefined. This diff handles messages only if they specify a method.
Fixes#2377
Closes https://github.com/facebook/react-native/pull/2405
Github Author: James Ide <ide@jameside.com>
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:
This sets NODE_ENV based on the value of the `dev` option when bundling the apps. This would then be inlined by the node-env-inline babel plugin. And finally -- if unreachable -- will be dead-code-eliminated by uglify.
This is not used in development because we set NODE_ENV to the value of __DEV__, which can be switched via a query param. However, the plugin has minimal overhead and to avoid complexity in the transformers I just enabled it by default.
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.