Debugging Obscure Build Errors Using Reverse Patches in IntelliJ

Today involved mostly code reviewing some changes to our front-end Angular codebase. As part of the review I picked up a few string constants that had been replaced by enums in part of the codebase but not all of it. So I modified the remaining constants in our codebase to rather use this new enum. I also addressed some suggestions/warnings IntelliJ raised about rather using the base package to import classes from TypeScript packages as apposed to the full path to the class being imported.

A weird error cropped up when trying to run tests which turned out to be caused by some tests trying to hit real Angular services instead of stubbed versions. After sitting with a colleague -who is very strong with front-end dev- I finally had a green npm install && npm test so I committed, pushed and merrily went on my way.

After heading to lunch I came back to find the build broken on TeamCity and discovered that the build process it uses is not simply a npm install && npm test but a bunch of other steps where it was breaking. So I ran these steps locally and luckily replicated the error - that was the easy part. Now I had to work out what in the list of files, each with minor changes, had caused the build to break.

To debug this I went to the VCS panel in IntelliJ right clicked my commit and then chose the option to create a patch. I checked the reverse patch option and made it save the patch to memory. Finally I applied the patch from memory using the VCS menu. I then had a bunch of uncommitted files which were the state of the files prior to me reviewing them.

I confirmed the build worked fine now and then reverted parts of the reversal that were clearly not causing the issue i.e. comments I added as part of the review. I then tried reapplying my changes to a portion of the file I was working on so that string constants were replaced with their enum equivalent again. This did not break the build so I reapplied all changes like this. I kept up this process, introducing small portions that had changed until finally I re-added a shortened import and broke the build again.

This issue stemmed from the fact that we have an older version of the Angular CLI in order for it to play nicely with some of the libraries we use.