Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
feat: improve upgrade to use rn-diff-purge #176
Upgrading experience is a bit harsh for React Native. We either need to install global
What the command does now:
This PR is technically breaking change, so I'm cool with introducing a temporary new command or put old one behind a different name.
Added tests with various scenarios.
Successfully upgrading to specified version:
Failed to fetch a non-existent diff:
No upgrade needed:
Upgrading to older version:
This is super awesome, thank you so so much for doing this, it's exactly what I hoped we could do, and you already did it!
Can you just go ahead and make this the default? Let's dump the old way of doing things, it is clearly very problematic for people – what you are doing here cannot be any worse. All we need to make sure is that the right diff is available when we make a new release. As part of that, we may want to consider merging
Well technically 0.59 (our first consumer) is still in RC, so we could stretch that semver incompatibility, and put the old version behind a flag.
Looks like neither Expo nor Ignite use the
I am happy to move this to community, sure, I don't see why not.
For automatic generation, right now I was trying to make a rpi build the diff when an npm version is up, but the npm version is not the easiest. I found a couple of services that email me so I was thinking of hooking this up with a mail check, but I saw npm has hooks but only for a paid org. Any ideas are welcome.
I agree that we might as well make it the default since the previous one seems to be not much used, but it would make sense to keep both for a while, one default and one with a flag.
Also, here are the things I was concerned about:
It would be very useful to have a link to the diff we are doing when it fails.
A link to pvinis/rn-diff-purge@version/0.44.0...version/0.47.2 would be useful to see the diff and our conflicts and see what's up.
I tried using it in an actual project and in a test project with a few "bigger" changes like some babel configs, some different xcode setup, typescript etc.
I think even with this command, I will still use the manual way to upgrade. We should think about having a migration script instead, that does some work per version. This would need to be manually created.
Let's say there is a new version. We use purge to make the diff. We see the diff, and based on that we have a migration script do the change. If the change is just an edit of a file, like package.json update or babel update etc, we apply it. For android it's mostly simple. For Xcode we can use some library to edit the xcodeproj and do the change (for example linking JSC) but we see that in the tempate (and so in purge) we link the lib to the target. In the migration script we would loop over the targets and link the lib. Then most other changes are small edits in the AppDelegate or App.js etc, and for these again, if we can apply them, good, if not, the script can notify the user, so they do the change.
Maybe what I'm thinking is basically a manual upgrade helper, that applies what it can using a script instead of diff, then applies usin the diff, then guides the user to do the rest of the changes.
Another option is to bail out really early from applying things automatically and to just show the patches. Essentially just an interactive cli walkthrough of the changes in Rn-diff-purge. We can automate that more and more over time when we are confident.
@pvinis thanks for great feedback. This command isn't meant to be a perfect way to upgrade, but it should ease the process as much as possible.
We now show the
We fail miserably, but we're able to show the diff and point to the plain diff, so it's still way better than any current workflow.
We now show git status and add
I'm not sure what you mean, could you clarify?
Thanks for addressing the above. I'm looking forward to an Xcode solution in the future :D.
Let me rephrase the tag thing.
Currently, this new
On the other hand, if we bring all the commits and tags from purge to the user's project, if that user wants to create a tag with the same form, like if they make a new app release and the tag is
Do you know what I mean, or did I not explain it very well? My concern is basically that we will be messing with tags in a repo that's not ours. But since we remove the remote after, maybe it's not really needed to do anything more. It was just a thought.
@pvinis anything that's holding us back with merging this? I'll be unavailable for the next couple of days so I'd like to get this over the finishing line.
I also have some ideas for further improvements: