Skip to content
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

any known issue with upgrading to RN 0.60? #1123

Closed
lior-frezi opened this issue Jul 24, 2019 · 7 comments
Closed

any known issue with upgrading to RN 0.60? #1123

lior-frezi opened this issue Jul 24, 2019 · 7 comments

Comments

@lior-frezi
Copy link

is it safe to upgrade or things would break?
as a general note, how much RN upgrades should be took with caution using reactXP ?

@mikehardy
Copy link
Contributor

I am doing a RN59 to RN60 upgrade right now, and yes, it will break you.

1- webview is no longer there - you will need to add reactxp-webview and react-native-webview packages to maintain webview functionality, along with related code changes
2- netinfo is no longer there, add @react-native-community/netinfo package and use reactxp@1.7.0-rc.2 (currently unreleased! so you have to depend on master after this PR landed #1119) or later (which handles the netinfo lean-core changes)
3- I still have some sort of javascript issue in Accessibility which is blowing up my mocha unit tests so I had to take npm test off my precommit hook for now

There may be other issues but other than those I do have it running on android and ios

This sounds rough but from my perspective, as disruptive as the lean-core / androidx / cocoapods changes have been in android and ios native land, this is a fairly good result. I believe I will have a working app when I'm done with my iOS project conversion - it's likely (for my project) that if current reactxp.git#master and the related reactxp-webview extension master were released as 1.7.0 and 1.0.0 respectively it's correct for my app

As a related note @erictraut - I'm not sure on intended semver fidelity in this repo, but the webview changes require code changes, shouldn't it be reactxp@2.0.0 when it releases? I'm not semver-militant myself but if the intention is semver-compliance it's definitely breaking change, and if the intention is not semver-compliance the recommendation should be ~-style semver range specifiers vs ^, and finally, the extensions seem to be 0.0.1 whereas a 1.0.0 would be nice. Cheers

@erictraut
Copy link
Contributor

@mikehardy, Yes that's a good point about versioning. We've historically been bumping the second number in the version string when there's a breaking change in the API, but I now realize that we should have been incrementing the first number. That means we should probably call the new version 2.0.0 rather than 1.7.0. @berickson1, and problem with switching to this new approach? I should probably document it as well so we're clear and consistent going forward.

And yes, the netinfo extension will get a real version number when we finally publish it. @berickson1, is this extension ready to be published as an "rc"?

@mikehardy
Copy link
Contributor

mikehardy commented Jul 24, 2019

I want to add for @liorJuice that if you depend on unreleased versions of reactxp (as you must in order to handle the lean-core netinfo extraction) you have to transpile the typescript before you can use it

Specifically you need to add this into your package.json somewhere in your "transpile typescript to javascript" steps (for me I have 'ts-dev' and 'ts-prod' package.json run scripts and I put them in there, for instance): cd ./node_modules/reactxp && npm run build - because naturally reactxp doesn't sit there in on github with the typescript transpiled already.

@berickson1
Copy link
Collaborator

@erictraut - all good on both 2.0.0-rc release and both reactxp-netinfo and reactxp-webview are good to go as rc. I had previously published them as alpha releases to validate.

@mikehardy
Copy link
Contributor

I've been traveling on vacation so just chewing through the RN60 upgrade in the background. After the items I noted above for Android I've got my iOS build working as well now and I don't appear to have any regressions - now using reactxp-2.0.0-rc.1 and reactxp-webview-2.0.0-rc.1

My remaining doubt about the upcoming release + RN60 is that reactxp is saying it requires a react-native peer < 0.60 but it seems that it should be okay with RN60 now? Same with the reactxp-webview extension (and possibly all the others?)

@mikehardy
Copy link
Contributor

mikehardy commented Aug 9, 2019

I realize after submitting my Accessibility PR that it is not a blocker for react-native@0.60, and since my initial steps above there have been releases here and I've learned more working here and on related issues

So my final steps to (apparently successfully?) convert to react-native@0.60 were:

  1. webview lean-core: install reactxp-webview and react-native-webview
  2. netinfo lean-core: install reactxp-netinfo and @react-native-community/netinfo
  3. mock out react-native Accessibility as it started failing in jest on RN60 where it used to work on RN59 (but it should have failed there too, really)

So as far as I can tell the list of actual blockers are solved in 2.0.0-rc.1 release candidates already, and the rest of the issues (react lifecycle methods, react context methods, accessibility methods) are all important but non-blocking

The mock I used, in case it's useful for you, is contained in a file in __mocks__ directory, the file is referenced in the setupFilesAfterEnv array in jest-config.js and the contents are:

import { AccessibilityInfo } from 'react-native';
const fetch = jest.fn(() => Promise.resolve(false));
AccessibilityInfo.fetch = fetch;

Hope this info helps

@mikehardy
Copy link
Contributor

Rightfully closed - I will note for posterity I'm still using the setup I described above, tracking with current react-native 0.61.3 at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants