Closed ghost closed 9 years ago
So start two dev servers you're saying? Also looks like externals accepts a function with a callback, which I believe could used to allow a single Webpack config, no?
Hmm, I'm looking at the externals function(context, request, callback) {}
now: context
provides us the absolute path of the directory of the module calling require()
, and request
is the module name being require
'd. I don't think we can determine which entry point originated the request based on this information.
We may be able to just combine both the iOS and Android deps into a single big 'externals' config. This may cause issues if a developer mistakenly require
s a module for the wrong platform, e.g. if you mistakely do require('SwitchIOS')
in your index.android.js, but it should be fine as long as there are runtime warnings when this happens, like https://github.com/facebook/react-native/blob/cd3865a14d62ae7555492d45375a2dd8f7407b83/Libraries/Components/SwitchIOS/SwitchIOS.android.js
Looks like @elliottsj put together some changes in https://github.com/mjohnston/react-native-webpack-server/issues/65 which should help ease the path forward for v0.13.0
support. Cross-linking for reference.
In
0.13
theReactPackager.getDependencies
method expects a configuration object with requiredplatform
andentryFile
keys. Without them RWNS quietly fails to fully start the React Packager and, as a result, never attempts to start the Webpack Dev Server.Here's where the current
react-native
entry point string being resolved from the package and passed off to the packager chokes out in the new version: react-packager/src/Server/index.js. For a quick verification add aconsole.log(options)
before and after L194 and you'll see the second log statement never makes an appearance in the console.If this fix looks hacky I'm happy to try and improve it with some direction.