Upgrades to React Native 64 #397
Conversation
|
pending facebook/react-native#31740 |
|
@vinnyjth I got carried away last night 😬 it's actually A LOT closer to working than I thought on the first pass |
| @@ -20,31 +24,21 @@ target 'apolloschurchapp' do | |||
| # Enables Flipper. | |||
| # | |||
| # Note that if you have use_frameworks! enabled, Flipper will not work and | |||
| # you should disable these next few lines. | |||
| # you should disable the next line. | |||
| use_flipper!('Flipper' => '0.75.1', 'Flipper-Folly' => '2.5.3', 'Flipper-RSocket' => '1.3.1') | |||
There was a problem hiding this comment.
I think we can omit the "custom" flipper versions now, also. that was a patch for our previous version of RN
There was a problem hiding this comment.
it's still listed in a thread I found somewhere as a problem with 64 too
|
@vinnyjth this one is ready to look at. the bulk of the changes are linter changes. I took out our custom config and just went with react native community config now that they have one, removes a lot of infrastructure |
|
@redreceipt I LOVE that we are able to eliminate our custom config, but.... this will wreak havoc with the update tool 😬 . It will likely force manual merges for any files that have been modified by clients. Obviously, that's okay! It's what the update tool is for, but does the costbenefitt work out in our favor given that the custom linter config rarely causes issues? As integration lead, you get to make that call :) I like the idea of waiting until we've got 98% of the code in |
|
Oh, shoot I didn't think about that. Honestly, I did it because it puts us way closer to a true RN project which makes future |
Ooohh that's a good point. That's assuming they are just moving one version up. If they are updating a bunch of different versions, with multiple template changes, they'll have to keep track of what files need to go to HEAD and what files need to be actually merged. So maybe we tell people to update to 2.29.1 and then from there to 2.30? What if this is the start of version 3? |
|
I don’t think it should be v3, that seems like it should be for NPM breaking changes. I like upgrading to 2.29 and then 2.30. almost all of our apps are caught up anyway and the ones that aren’t we’ll know to do that.
… On Aug 6, 2021, at 4:17 PM, Vincent Wilson ***@***.***> wrote:
I think it'll be obvious to folks that REMOTE is just linter changes. We should just be able to always choose HEAD and then run eslint --fix, right?
Ooohh that's a good point. That's assuming they are just moving one version up. If they are updating a bunch of different versions, with multiple template changes, they'll have to keep track of what files need to go to HEAD and what files need to be actually merged. So maybe we tell people to update to 2.29.1 and then from there to 2.30?
What if this is the start of version 3?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUJJFS4FIIKW4UEVJANODDT3Q7NDANCNFSM463YZQRQ>.
|
|
ok @vinnyjth I got rid of most of the linter differences. Maybe we keep curly braces around if statements though?
|
|
blocked by https://github.com/ApollosProject/apollos-apps/pull/2063 and #430 so the events tests and mocking the timezone will be a non-issue |
Codecov Report
@@ Coverage Diff @@
## master #397 +/- ##
==========================================
+ Coverage 45.16% 45.26% +0.10%
==========================================
Files 3 3
Lines 93 95 +2
Branches 17 17
==========================================
+ Hits 42 43 +1
- Misses 49 50 +1
Partials 2 2
Continue to review full report at Codecov.
|
|
@vinnyjth if I get you screenshots, could you look at this? |
|
yah sure @redreceipt |
|
|
The upgrade is minor, this puts us way closer to the core react native project without a lot of unnecessary technical debt we've accrued.