Better handling for cached 'node_modules' folder

Use case

We are using patch-package to fix some nasty dependency issues, it works great during development. But it sometimes causes CircleCI failures when a partially patched node_modules folder is cached by CI.

The issue

1. Install patch-package and add it as prepare script, as instructed by README.
2. Patch module foo-bar using patch-package foo-bar. Commit the resulted patches/foo-bar+X.X.X.patch to repo.
3. When CI is run, CircleCI installs and patches the node_modules folder and saves the result to cache.
4. Modify module foo-bar and regenerate patch file.
5. CircleCI restores the previous cached node_modules folder (which has incorporated previous version of the patch).
6. CircleCI fails when applying new patch to node_modules:

**ERROR** Failed to apply patch for package foo-bar

  This error was caused because Git cannot apply the following patch file:

    patches/foo-bar+X.X.X.patch

  This is usually caused by inconsistent whitespace in the patch file.

Proposed solutions

1. Add a checksum file for the patches folder so we can easily check if patches has been changed before restoring cache from CI.

2. Or, add a operation that can revert applied patches, such as patch-package revert. So we can revert the patches and save the clean node_modules folder to cache.

[ds300]

Hi peeps. I just published v5.1.0 of patch-package which has a --reverse option. Thanks for your patience. 🙇

[OliverJAsh]

I just ran into the exact same issue. Unfortunately I don’t think --reverse can help in our case—we don’t want to revert the patches because the version of node_modules at the end of the build will be cached but also it is what will be used to run the application, so the patches need to be applied.

I’m not sure there’s any solution to this problem, but at the very least I hope we can improve the error message, so it’s clear the patch failed because it’s being applied to something that has already been modified. The patch could carry a hash of the original file, and then when the patch is applied, if the hash of the target file doesn’t match the original, the patch would fail with an error along the lines of “target has unexpected hash”. /cc @ds300