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.
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
yarn / npm lock the dependency on that specific version so our entire team and the build pipeline gets the same version
npm install patch-package --save-dev
make changes in node_modules against that library, e.g. “package-banana”
npx patch-package “package-banana” - this creates a folder
add “postinstall": "patch-package" to scripts section in package.json
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.