-
Notifications
You must be signed in to change notification settings - Fork 47.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require modules from React Native as node modules. #6715
Require modules from React Native as node modules. #6715
Conversation
RCTEventEmitter: 'react-native/Libraries/BatchedBridge/BatchedBridgedModules/RCTEventEmitter', | ||
TextInputState: 'react-native/Libraries/Components/TextInput/TextInputState', | ||
UIManager: 'react-native/Libraries/Utilities/UIManager', | ||
UIManagerStatTracker: 'react-native/Libraries/ReactNative/UIManagerStatTracker', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one is commented out in ReactNativeBaseComponent.js
This makes it very tough to change internal structures of React Native. Have you considered a build script that puts them into the same repo like we do for React? Or maybe putting forwarding modules into a common directory? That seems to be a pretty common pattern for solving this problem with C headers. |
Hm. This only works if I can imagine scenarios where this is not the case. E.g. when you use an application framework as a dependency which uses I think the problem is that we can't make Even with npm3 there are scenarios where you end up with nested dependencies, right? |
I kind of think that some of these should go on an indirection on the global object directly instead of in the module system since there is no way in the node/npm world to define a global host environment module other than through the global object. E.g. |
Can't we use |
@sebmarkbage thank you for the feedback
You are correct here. I chose this variant to maintain backwards compatibility. If react@15.0.3 is not compatible with older versions of react native anyway, I will introduce the necessary forwarding modules and change this PR.
Yes, the build script will come soon. We will need a separate solution for our internal setup, but as long as the forwarding modules are in the same place there won’t be a problem.
This will work if
That’s correct. Does such a framework exist yet? If not, we’re good and can encourage to use
Both assumptions are correct, but
That would certainly be a possibility, given that we have many stateful global modules anyway. There are a lot of opinions on this topic, and if we’d go that route I’d like to keep that a separate step from this PR. I will add forwarding modules to RN tomorrow and update this PR accordingly. |
FWIW, I'm pretty sure that regardless of how this gets done it's not going into 15.0.3 and we'd do it as a 15.y.0. |
@zpao the version does not matter to me. I am more interested if the recent reorganization is backwards-compatible or not. I guess it isn’t, because we would end up with having the same |
211c010
to
05319ff
Compare
@davidaurelio updated the pull request. |
counterpart is D3281736 |
friendly ping |
whiteListNames.forEach(function(name) { | ||
moduleMap[name] = name; | ||
Object.keys(whiteList).forEach(function(name) { | ||
moduleMap[name] = whiteList[name]; | ||
}); | ||
|
||
moduleMap['object-assign'] = 'object-assign'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just simplify this whole thing since you're changing to an object anyway?
var moduleMap = Object.assign(
{},
require('fbjs/module-map'),
{
deepDiffer: 'react-native/lib/deepDiffer',
...
'object-assign': 'object-assign',
}
)
Otherwise, this seems fine. If you say the module resolution works then I believe you :) I'm a little concerned about the framework & peerDep and that screwing up the resolution, but we can tackle that later. I think the only clear solution to that is shipping the renderer in its own package, which we'll get to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I can change that. Having the renderer in its own package makes a lot of sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. We'll land after you update and ship 15.1.0-alpha.2 so RN can pull this in officially
05319ff
to
115c137
Compare
115c137
to
d1fc37b
Compare
@davidaurelio updated the pull request. |
(cherry picked from commit 151e1d7)
(cherry picked from commit 151e1d7)
This is one puzzle piece to remove the special handling of
node_modules/react
in React Native’s packager.It changes all requires into React Native from
@providesModule
to the node.js resolution algorithm.I tested our internal use case by building the v15.0.3-dev branch with this patch applied and running an app.