I'm converting quite a lot of code from JavaScript to TypeScript, which means:
- rename files from .js to .ts
- add type annotations etc
Of course in many cases, such a refactoring can be substantial, and you might rewrite code completely to take benefit of TS (or because it's just old). But quite often I find myself starting with the simple steps above. Since I'm a bit obsessed with code reviews to avoid typos and silly mistake when migrating code, I prefer to thoroughly review my code in GitHub PRs. However, when a file has been renamed AND slightly changed, GitHub frequently just gives up and displays it as one deleted file and one added file. This means that a 500 line file will have to be reviewed without any context, which is completely useless!
I've found a workaround which is to
- make a single commit with all files I intend to migrate, where I only rename the files and nothing else (code is broken at this point of course)
- make a second commit with all the TS adaptations
The I review the PR and exclude the first commit, which means I will be reviewing quite small changes (require -> import, type annotations on functions and variables, etc). The bulk of the file content is unchanged.
However this is painful because quite often you start a migration task and you migrate some files at a time, and you don't know at first which exact files you will migrate when this PR is done. So sometimes when I'm done, I've created a new branch, manually renamed the migrated files to .ts, commited that change, then copied the code changes from the work branch using git checkout migration-branch -- src and make a second commit.
This is just a frustrating workflow. Is there a way to hint to git or GitHub that a file was renamed and modified so that it doesn't think that the JS file was deleted and an entirely unrelated TS file was added? Or is there some other trick?