Detects when someone's upgrade goes awry due to sdkVersion in Expo config overriding the actual installed SDK version. (e.g., https://github.com/expo/expo/issues/23351)
How
We can't use exp from getExpoConfig() because this always populates sdkVersion (either based on installed version or expo.sdkVersion). So, we have to read the actual Expo config to see if sdkVersion was set. This is really only practical in Doctor for a static config file. We could possibly attempt some comparison between exp's sdkVersion and package.json, but there'd be limitations to have to tiptoe around there.
One other option would be to actually change @expo/config to expose where sdkVersion came from. Not sure if it's worth the effort, though.
@brentvatne I can add some unit tests to this, but wanted to first run the concept by you first to see if we should take this approach or go further in one of the directions described above before I spent more time on it.
On Brent's advice, we now compare the final output from getConfig in @expo/config with how @expo/config resolves the installed SDK version. If they don't match, sdkVersion is being overridden in the Expo config, whether it's static or dynamic.
Test Plan
The message itself:
When you put in the wrong sdkVersion, you also get a ton of wrong package versions from the step where it checks against bundledNativeModules (not pictured)
Why
Detects when someone's upgrade goes awry due to
sdkVersionin Expo config overriding the actual installed SDK version. (e.g., https://github.com/expo/expo/issues/23351)How
We can't useexpfromgetExpoConfig()because this always populatessdkVersion(either based on installed version orexpo.sdkVersion). So, we have to read the actual Expo config to see ifsdkVersionwas set. This is really only practical in Doctor for a static config file. We could possibly attempt some comparison between exp'ssdkVersionand package.json, but there'd be limitations to have to tiptoe around there.One other option would be to actually change@expo/configto expose wheresdkVersioncame from. Not sure if it's worth the effort, though.@brentvatne I can add some unit tests to this, but wanted to first run the concept by you first to see if we should take this approach or go further in one of the directions described above before I spent more time on it.On Brent's advice, we now compare the final output from
getConfigin@expo/configwith how@expo/configresolves the installed SDK version. If they don't match,sdkVersionis being overridden in the Expo config, whether it's static or dynamic.Test Plan
The message itself:
When you put in the wrong
sdkVersion, you also get a ton of wrong package versions from the step where it checks against bundledNativeModules (not pictured)