Summary: I'm planning to split up `DependencyResolver` into the react-native specific implementation of it and a new, generic resolver that is going to replace `node-haste` for jest and other places where we might need JS dependency resolution.
The plan is to split the two folders up so that:
* `Resolver` is the folder for all the react-native specific resolver code
* `DependencyResolver` will become a standalone library, eventually moving into a package called `node-haste`.
There is still a lot to be figured out. This is just the first diff of likely many. The current goal is to make `DependencyResolver` standalone to be able to create an instance of a resolver and resolve all dependencies for a file. This is when I can start integrating it more seriously with jest.
This diff simply moves a bunch of things around and turns `HasteModuleResolver` into an ES2015 class ( :) ).
bypass-lint
public
Reviewed By: davidaurelio
Differential Revision: D2614151
fb-gh-sync-id: ff4e434c4747d2fb032d34dc19fb85e0b0c553ac
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:
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:
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:
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.
