This is also a quick blog post.

Let me tell you the tale of patch-package. Not many people have heard the tale of patch-package. Many prefer to walk the path forked.

Well, the path of patch-package works like this.

About patch-package

Your favourite NPM library has a problem. You need to hot fix it. You send in a PR and it’s stuck in review hell. The poor maintainer is on stress leave and you really don’t want to trouble her/him - they are in Finland, don’t wear shoes, and can’t possibly scale any further.

This is the patch-package path https://www.npmjs.com/package/patch-package

1. yarn / npm lock the dependency on that specific version so our entire team and the build pipeline gets the same version

2. npm install patch-package --save-dev

3. make changes in node_modules against that library, e.g. “package-banana”

4. npx patch-package “package-banana” - this creates a folder
   /patches/package-banana-version.patch

5. add “postinstall": "patch-package" to scripts section in package.json

6. check in / commit everything. Package.json and /patches/package-banana-*.patch

Now when anyone get latest and run npm install, the build chain will automatically grab that version of the library package-banana and apply your patch.

Then it will build as normal. This works great on Azure DevOps (VSTS) too.

When the library package-banana is finally fixed - update the library version and the patch file won’t work against newer versions.