[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
'use strict';
|
|
|
|
|
|
|
|
const AssetModule = require('./AssetModule');
|
|
|
|
const Package = require('./Package');
|
|
|
|
const Module = require('./Module');
|
|
|
|
const path = require('path');
|
|
|
|
|
|
|
|
class ModuleCache {
|
|
|
|
|
Fix @providesModule not being ignored properly
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
2015-12-24 08:31:17 -08:00
|
|
|
constructor(fastfs, cache, extractRequires, depGraphHelpers) {
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
this._moduleCache = Object.create(null);
|
|
|
|
this._packageCache = Object.create(null);
|
|
|
|
this._fastfs = fastfs;
|
2015-08-10 16:00:16 -07:00
|
|
|
this._cache = cache;
|
2015-11-16 22:48:28 -08:00
|
|
|
this._extractRequires = extractRequires;
|
Fix @providesModule not being ignored properly
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
2015-12-24 08:31:17 -08:00
|
|
|
this._depGraphHelpers = depGraphHelpers;
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
fastfs.on('change', this._processFileChange.bind(this));
|
|
|
|
}
|
|
|
|
|
|
|
|
getModule(filePath) {
|
|
|
|
filePath = path.resolve(filePath);
|
|
|
|
if (!this._moduleCache[filePath]) {
|
Fix @providesModule not being ignored properly
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
2015-12-24 08:31:17 -08:00
|
|
|
this._moduleCache[filePath] = new Module({
|
|
|
|
file: filePath,
|
|
|
|
fastfs: this._fastfs,
|
|
|
|
moduleCache: this,
|
|
|
|
cache: this._cache,
|
|
|
|
extractor: this._extractRequires,
|
|
|
|
depGraphHelpers: this._depGraphHelpers
|
|
|
|
});
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
}
|
|
|
|
return this._moduleCache[filePath];
|
|
|
|
}
|
|
|
|
|
|
|
|
getAssetModule(filePath) {
|
|
|
|
filePath = path.resolve(filePath);
|
|
|
|
if (!this._moduleCache[filePath]) {
|
Fix @providesModule not being ignored properly
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
2015-12-24 08:31:17 -08:00
|
|
|
this._moduleCache[filePath] = new AssetModule({
|
|
|
|
file: filePath,
|
|
|
|
fastfs: this._fastfs,
|
|
|
|
moduleCache: this,
|
|
|
|
cache: this._cache,
|
|
|
|
});
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
}
|
|
|
|
return this._moduleCache[filePath];
|
|
|
|
}
|
|
|
|
|
|
|
|
getPackage(filePath) {
|
|
|
|
filePath = path.resolve(filePath);
|
2015-11-09 13:32:47 -08:00
|
|
|
if (!this._packageCache[filePath]) {
|
Fix @providesModule not being ignored properly
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
2015-12-24 08:31:17 -08:00
|
|
|
this._packageCache[filePath] = new Package({
|
|
|
|
file: filePath,
|
|
|
|
fastfs: this._fastfs,
|
|
|
|
cache: this._cache,
|
|
|
|
});
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
}
|
|
|
|
return this._packageCache[filePath];
|
|
|
|
}
|
|
|
|
|
|
|
|
getPackageForModule(module) {
|
|
|
|
// TODO(amasad): use ES6 Map.
|
|
|
|
if (module.__package) {
|
|
|
|
if (this._packageCache[module.__package]) {
|
|
|
|
return this._packageCache[module.__package];
|
|
|
|
} else {
|
|
|
|
delete module.__package;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
const packagePath = this._fastfs.closest(module.path, 'package.json');
|
|
|
|
|
|
|
|
if (!packagePath) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
module.__package = packagePath;
|
|
|
|
return this.getPackage(packagePath);
|
|
|
|
}
|
|
|
|
|
|
|
|
_processFileChange(type, filePath, root) {
|
|
|
|
const absPath = path.join(root, filePath);
|
2015-08-10 16:00:16 -07:00
|
|
|
|
|
|
|
if (this._moduleCache[absPath]) {
|
|
|
|
this._moduleCache[absPath].invalidate();
|
|
|
|
delete this._moduleCache[absPath];
|
|
|
|
}
|
|
|
|
if (this._packageCache[absPath]) {
|
|
|
|
this._packageCache[absPath].invalidate();
|
|
|
|
delete this._packageCache[absPath];
|
|
|
|
}
|
[react-packager] Rewrite dependency graph (support node_modules, speed, fix bugs etc)
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
2015-06-19 18:01:21 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
module.exports = ModuleCache;
|