mirror of
https://github.com/zhigang1992/react-native.git
synced 2026-03-06 17:34:07 +08:00
6cec263ca3
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
39 lines
583 B
JavaScript
39 lines
583 B
JavaScript
'use strict';
|
|
|
|
const Promise = require('promise');
|
|
const Module = require('./Module');
|
|
|
|
class Polyfill extends Module {
|
|
constructor({ path, id, dependencies }) {
|
|
super({ file: path });
|
|
this._id = id;
|
|
this._dependencies = dependencies;
|
|
}
|
|
|
|
isHaste() {
|
|
return Promise.resolve(false);
|
|
}
|
|
|
|
getName() {
|
|
return Promise.resolve(this._id);
|
|
}
|
|
|
|
getPackage() {
|
|
return null;
|
|
}
|
|
|
|
getDependencies() {
|
|
return Promise.resolve(this._dependencies);
|
|
}
|
|
|
|
isJSON() {
|
|
return false;
|
|
}
|
|
|
|
isPolyfill() {
|
|
return true;
|
|
}
|
|
}
|
|
|
|
module.exports = Polyfill;
|