With this issue I want to line up all the things that we are planning to do in a bullet point manners, so that we can sort of prioritise them and discuss/add/remove new ones.

Version 1

This version should be literally the barebone version, so that we can put it in front of the developers and have them start using it & provide feedback.

• Improve README with useful information
• Add a way to conclude diffs as when they are done (PR at #21) - @lucasbento
• Add useful links section (pointing to a blog post or something like that) (PR at #24)
• Handle binaries (add a way for the user to download them) #22 (PR at #24)

Version 2

This one should be the "super powered" version of 1, with more advanced features & cool extras.

• Add comments on the diff (will be manually created by us, PR at #18) - @lucasbento
• review the ant design / maybe change it?
• add the versions in the url (shareability <3) #9

When using the tool with 0.55.0 -> 0.59.1
The steps about react_native_config.xml is shown.

But,

When using the tool with 0.55.0 -> 0.59.2
The steps about react_native_config.xml is not shown.

Feature Request

We should test the website automatically on multiple browsers.

Why it is needed

With #51 being opened (thank you for this @KevinHu2014), it came to my attention that we should properly test the website on multiple browsers, the best way to do it would be to run a few tests automatically on CircleCI.

Possible implementation

We can use Cypress.io with CircleCI, we can also think about a few image snapshots to do image comparison, which is an easier way to get things going for now.

Apparently Cypress supports only Chrome, we may consider using Sauce Labs (where we can run on multiple browsers) and WebdriverIO together with wdio-image-comparison-service.

I recall seeing a tweet that now also had a plugin/extension for doing image comparison on PRs, let's see if I find more info about that.

Feature Request

We should have automatic deployment of master, plus maybe PR deployments?

Bug

CircleCI is not running jobs on forks that are not trusted, we need to follow https://circleci.com/blog/triggering-trusted-ci-jobs-on-untrusted-forks/ to only enable test and lint scripts to run on untrusted forks, deploy should remain the same.

Description

After #112, @lucasbento suggested some good changes:

• Have it appear only after the diff has been rendered
• Move it to be shown below the "Useful content" section
• Have the same width as the useful content section to maintain consistency
• Use "info" alert instead of "warning"
• Add a comment on it that the app name can be changed in the settings (this would happen in #111 probably)

@Naturalclar, since you have worked on both of these, we would be very happy if you wanted to pick these ones up too 🙌

Feature Request

Some people may prefer to see the diff unified like GitHub provides, we should offer an option to do so.

Feature Request

We need to have our own ISSUE_TEMPLATE.md and PULL_REQUEST_TEMPLATE.md.

Why it is needed

The repository is currently inheriting what is on rn-community's .github, those currently have react-native-only content.

Possible implementation

Work on top of rn-community's .github.

Bug

Just find out that the Counter style look different on the Safari browser.

Safari

5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15

Chrome

Steps to reproduce

Describe what you expected to happen:

1. Open https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.0
   on Safari

2. Click some files

3. The Counter pops up, but not in a good shape

Feature Request

Right now we only have these sad little tests and we definitely need to add more.

Question

I followed the instructions from #47, but I have this ART library which wasn't shown but is part of react-native.

Should I remove this ?

We should remove the snapshot tests, at least for the general places. we should keep snapshots for specific UI things in the diff, but it makes little sense to test the main part, since it changes relatively often with new notes etc.

It would be great if there would be an option to show / hide whitespace changes, so there would be less changes, see:

I think these kind of changes could be ignored and the upgrade process would be more clean.

Not sure if I described the idea well so feel free to ask more questions. Thanks

EDIT: link for the screenshot https://react-native-community.github.io/upgrade-helper/?from=0.60.5&to=0.61.1

We should have a direct reference to this tool in other places like:

• documentation (https://facebook.github.io/react-native/docs/0.59/upgrading) - @lucasbento
• maybe the main readme? or the wikis?
• react-native-releases?
• rn-diff-purge?

Description

• We need to refactor the code here, it has become too complex for such a simple project 😬, but I haven't had the time to do it myself yet. Basically I want to have a simple utility thing that fetches the releases, and then generates a list of the versions to be displayed. Then we will have the ui thing that will actually display all that. Then we can actually test the utility part, and the ui I don't care if we test.

• Also, we need to make the notes/comments/links better. Currently, we can only comment inline on minor versions (as it 0.59.x), but if a file has been touched on 0.59.1 and reverted on 0.59.2, this comment is now broken. We need to make a better plan for this.

• We got a great idea on twitter https://twitter.com/safaiyeh/status/1205969341969133568?s=20 about adding a text input field that the user can put their app name, and all instances of RnDiffApp will be replaced with that name. Sounds cool, helpful and easy, so let's do it.

• Write a document about xcodeproj. I explained it in my talk, but I should also write a text and have it here so its easy to find. For now, general explanations are needed. No specific questions to make an FAQ or something.

• Move to typescript 🙌

Feature Request

Configure proper ESLint and Prettier, they both have their configs but should also be run on CircleCI together with the unit tests.

We already have the lint script but for some reason it's not picking up warnings/errors from Prettier.

Moved here: react-native-community/upgrade-support#14

--

For an easy upgrade experience of this file, do the following.

After all the other files have been upgraded, run yarn install and

cd ios
pod install
cd ..

This will cause all the Pods to be connected. After that, open the workspace file in the ios directory, called something like MyApp.xcworkspace

This workspace contains your original project, as well as the Pods project. Expand your project and find the Libraries directory.

Inside that, there are a few libraries related to React Native, and possibly other native modules from other libraries you might have connected.

You can go ahead and remove the React Native related libraries from there, by selecting them and hitting the delete button. In the popup you get, you can select Remove references. If you select to Move it to Trash, you might need to run yarn install again.

These libraries are not needed there anymore, since now they are connected using CocoaPods. You can do the same for other libraries that might exist in that directory, if they support CocoaPods. If they don't, keep them there for now.

After all this, your diff of that file should look roughly the same as the one right here. Don't worry too much if it doesn't match exactly, as your project might have more or fewer targets.

Try to see if the rough outline is the same, and of course make sure your project can build and run.

Feature Request

We should have links like gh.com/purge?from=0.30&to=0.39 to allow for linking and history keeping.

Why it is needed

For sharability.

Possible implementation

Code sample

Feature Request

I think it would be helpful to have a precommit / post hooks to run eslint and/or prettier

Why it is needed

This way, code that doesn't conform to repo style standards won't push. Also helps with automating linting & prettifying tasks.

Possible implementation

Use husky package to create pre hooks

We should add a dark mode, so we don't get blind.

Feature Request

Allow users to collapse/expand all files at once.

Why it is needed

Makes it easier to find the right file on a large diff.

Possible implementation

Hold alt and click on the inverted caret icon. It works as a toggle.

https://github.blog/changelog/2018-08-17-collapse-all-diffs-in-a-pull-request-at-once/

Code sample

Feature Request

This project isn't just based on CRA, it basically would take much longer to build if the amazing react-diff-view didn't exist and some crazy amount of work would be needed if inline-mdx.macro wasn't out there (which we don't have implemented yet but @hamlim is doing a ton of work to support our structure).

We should add both projects to the README.md in appreciation to @otakustay and @hamlim's work.

Feature Request

The project needs documentation regarding creating release files, writing down comments and adding stuff to the useful content section.

Feature Request

This has been brought up by @RubenSandwich on #57, basically show a nice skeleton.

Why it is needed

Spinner is ugly, long live the nice skeletons.

Possible implementation

We can use something like react-content-loader.

We show rc versions on the to dropdown until the final release is out.
After the final is out, if a user is on an rc version, they should be able to upgrade from that to the final.

Therefore we should show the rc versions on the from dropdown.

(If we want to minimize noise, we should only show the rcs of the latest version.)

Bug

When I copy code from the upgrade helper and paste it into my editor, the line numbers are also copied.

Info

Safari: 12.1.1 (14607.2.6.1.1)
VS Code: 1.36.1 (1.36.1)

Feature request

Instead of viewing just the diff between different file version, why not just allow the user to view the full contents of the file? I.e. "view raw"

Why it is needed

Some diffs are just not that useful 🤷‍♀

For instance, the .flowconfig-file is (in my case) never manually edited. The diff is not very helpful in this case, because all I want is just the "new version of the file".

Possible implementation

Add a "view raw" or "view file" to the "header" of the diff.

Feature Request

Previous version as purge-web had analytics tracking with react-ga, we should add this again in order to know how much traffic the app is getting.

Feature Request

Add Link to File in Diff panel so file can be download which will be useful for binary file update

Why it is needed

For example when upgrade from 0.59.8 to 0.59.9. File android/gradle/wrapper/gradle-wrapper.jar was upgrade but no diff due to it's a binary file.

Possible implementation

Add link to file for example https://github.com/react-native-community/rn-diff-purge/raw/release/0.59.9/RnDiffApp/android/gradle/wrapper/gradle-wrapper.jar

Code sample

Feature Request

This issue was raised from #40, basically the current implementation to gather which release files should be shown is not good enough, it uses semver.gt & semver.lt as you can see here.

The most optimal way would be to treat each file name as a version range, so for instance, if you want to write comments for 0.60.x you create a 0.60.js file, if you need it specifically for 0.59.9 then you should create a 0.59.9.js and not 0.59.0.js as it is currently.

Why it is needed

Currently you can not have comments/useful links for specific patch releases or release candidates.

Possible implementation

Use semver.coerce and its comparison functions: https://github.com/npm/node-semver#comparison.

Feature Request

This is related and started at #10, basically the website needs to show the "completed" files below the uncompleted ones.

Why it is needed

It's easier this way to know which files are still left to be changed.

Possible implementation

Have two sections of file groups, one for completed and another for uncompleted.

The project already stores the IDs of the completed ones here.

Bug

As screen in this screenshot, the context for the !debug.keystone change shows under the "# IntelliJ" section which is quite misleading. By looking at the line numbers you may notice that they are not linear - there is a jump from line 25 to 39. However there is no notice of this, so the context lines appears together with the wrong section header.

Since some changes are context sensitive, it may cause problems for people while upgrading. In this particular example (.gitignore) the context isn't important beyond readability and future upgrade diffs.

React Native versions

0.60.6 => 0.61.2

Steps to reproduce

1. Open https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.2
2. Scroll down to the diff of .gitignore
3. See that "Android/IntelliJ" appears as the header for the Buck ignore changes.

Describe what you expected to happen:
There should be a visual divider or other visual clue when line numbers increment more than 1.

Feature Request

Add useful content section for 0.57 and 0.58, these need to include the official blog post on React Native website and the following links for upgrading:

• https://reactnative.thenativebits.com/courses/upgrading-react-native/upgrade-to-react-native-0.57/
• https://reactnative.thenativebits.com/courses/upgrading-react-native/upgrade-to-react-native-0.58/

Every time, When I m try to upgrade to the new react native version, I would speed too many times to fix compilation environment, If we can provide the correct Podfile configuration for react-native dependency. This toolkit will be more usefully.

Bug

React Native 0.61.3 has a dependency on React 16.9.0 but the upgrade suggestions for 0.61.3 indicate we should use React 16.8.1 (and some other older dependencies)...

React Native versions

0.61.3

Steps to reproduce

Review the suggested diffs for 0.61.3 here

Describe what you expected to happen:

1. expect the dependencies to be at least the same as 0.61.3 and same as react-native init produces

PS. sorry if I'm missing something obvious - this is my first attempt at using this tool. All assistance is greatly appreciated.

Feature Request

Currently the diff is made between an RN app named RnDiffApp and the RN template which has a different app_name/DisplayName of Hello App Display Name. When upgrading this shows as 2 additional diffs that are IMO not necessary, see the SS:

I propose we handle this name discrepancy so that it doesn’t show up in the diff.

Why it is needed

Every upgrade shows at least 2 diffs that will (always?) be ignored. This unnecessarily increases the cognitive load for each upgrade.

Possible implementation

I thought the change would be as simple as running react-native init „Hello App Display Name” but the projectName does not allow spaces. One solution that comes to mind is replacing RnDiffApp (which is a fairly specific string) with Hello App Display Name. However I’m not sure if we want to add this to the workflow.

Another option would be to submit a patch directly to https://github.com/facebook/react-native/tree/master/template and change the name to something like HelloWorld. This doesn’t feel right, though :)

Let me know if this makes sense and if you have better options on how to handle this.

Would be really nice to have a logo for the project :)

Feature Request

This will allow us to add better comments on the diffs, without ending up with with a wall of text with no formatting.

Feature Request

Working on facebook/react-native-website#1063 I noticed that we lack a "getting started"/"how to use" guide for the user to know what to do once they land on the page.

Why it is needed

So it's more clear to the user what they need to do with that beautiful diff that's showing in their browser.

Possible implementation

A button with a ? icon that opens a modal with some nice content about how to upgrade using Upgrade Helper, content can be based on facebook/react-native-website#1063.

I don't know if this can be done, but we should have a way to have the comments not mess with selection and copy-pasting.

Some people write the code manually, and some copy-paste from the diff. If there is a comment or more in there, then they also get selected and copied. Is there a way to make the text of the comment not selectable so copy-paste works easily?

If not, should we maybe add a way to quickly toggle them on and off?

Feature Request

Add download link to all files

Why it is needed

Sometime files can be replace directly (.flowconfig) or in case of new file (.eslintrc.js). Download and replace it would be faster.

Possible implementation

Add download link just like binary file

https://github.com/facebook/react-native/releases/tag/v0.62.0-rc.1 has been released.

Feature Request

We should add and configure Netlify to deploy on each PR so we have an URL to preview the PR without having to do it manually and locally.

Possible implementation

We can base the config on react-native-website's and will only use it for PRs, we will remain using GitHub pages for master as we want to keep the URL under react-native-community.

Can be the same as the one at https://github.com/react-native-community/cli/blob/master/LICENSE.

Feature Request

Add a button to star the project on GitHub, can be done using react-github-btn.

Question

First, thank you for the awesome app!

When using the app:

https://react-native-community.github.io/upgrade-helper/?from=0.58.6&to=0.59.10

it tells me to update this file:

babel.config.js

I do not have that file and there is no way to see what the entire file should look like in the update app.

I looked for it in the react native repo but I could not find it.

Not sure what to do.

Now that we are getting closer to having a v1 ready, I am starting to wonder if we shouldn't change the name of the repo to something that more clearly tells what it is about.

I was thinking to changing the name to upgrade-helper, what do you think?

(also, we need to improve a bit the README, I can take care of it)

Feature Request

Idea initiated in #21, basically add a counter like 2/10 in the bottom right of the page to show how many files have been completed and how many are still left, the counter should show only after you complete at least one file.

Feature Request

Basically append a link to the useful content section for the changelog of each major bump.

Based on this conversation on twitter, Nick & Ram (& others) want to help people upgrading to 0.60 avoiding the pitfalls they've fallen into.

The most helpful approach will likely be by adding inline comments - feature we added via #18 (but still needs to be properly documented, see #28) - so let's use this issue to coordinate about what to write where :)

(protip: we have also been using dedicated issues like #47 to give in-depth descriptions and linked that inline)