When we use third-party dependency packages on npm, what should we do if we find a bug?
Think about it, if we encounter a bug when using a third-party dependency package, the usual solution is to bypass the problem and use other methods to solve it, which is more troublesome. Or file an issue with the author and wait for the author to fix it. The waiting time is uncontrollable. So at this time, can you use patch-package to fix the bug yourself? It feels great, and you can also expand capabilities according to business needs on third-party dependency packages.
Of course, it is best to expand some more versatile capabilities. If it is more common and most developers of this capability have such demands, you can submit a PR to the third-party dependency package. Isn’t it easier to participate in open source projects~ (Don’t go further and further on the road of magic modification)
There are many articles introducing it, you can refer to:
1. vue-pdf problem solving and patch-package introduction: https://www.jianshu.com/p/d1887e02f8d6
2. Use "black magic" to elegantly modify third-party dependency packages: https://zhuanlan.zhihu.com/p/412753695
3. Use patch-package to customize the dependency package in node_modules: https://blog.csdn.net/qq_32429257/article/details/111051217
I won’t go into details about the specific application scenarios. You can read the article yourself. In fact, there are still many requirements. Here we mainly record the specific usage steps.
Use of patch-package
Step1: Installation
Install using npm
npm i patch-package
It is recommended to use yarn installation
yarn add patch-package postinstall-postinstallStep2: Modify the package.json file
A series of npm script commands are declared in the scripts of package.json, as follows: (Reference: http://caibaojian.com/npm/misc/scripts.html )
- prepublish: runs before the package is published, and also runs when npm install installs it locally.
- publish,postpublish: run after the package is published
- preinstall: run before the package is installed
- install, postinstall: run after the package is installed
- preuninstall,uninstall: run before the package is uninstalled
- postuninstall: Run after the package is uninstalled
- preversion: run before bump package version
- postversion: run after bump package version
- pretest, test, posttest: run through npm test command
- prestop,stop,poststop: run through npm stop command
- prestart,start,poststart: run through npm start command
- prerestart,restart,postrestart: run through npm restart
You can see that the postinstall command will be executed after the dependent package is installed.
So we add in the scripts of package.json:"postinstall": "patch-package"
"scripts": {
***,
+ "postinstall": "patch-package"
}Modify package.json and add the command "postinstall": "patch-package", as shown in the figure:
Step3. Execute the command
npx patch-package to modify the folder name. The folder name here refers to the folder name under node_modules.
For example: npx patch-package pdfjs-dist where pdfjs-dist is the main folder name of the file we modified.
Step4. Generate patches
. After executing the command, check whether the patches folder is generated in the root directory. The patches folder is automatically generated, as shown in the figure:
Step5.npm install verification.
Verify npm install in the project to see if there is a patch package prompt. If so, it means the patching was successful!
Note 1:
1. It does not take effect in automatic deployment.
The error message
npm WARN lifecycle [email protected]~postinstall: cannot run in wd [email protected] patch-package (wd=/data/servers/jenkins/ workspace/nginx)
Solution:
Add the .npmrc file in the project root directory and write:
unsafe-perm = true
Note 2:
- The patch locks the version number. If the version is upgraded, the patch content will become invalid. It is best to lock the version number in package.json.
- While making magic changes, it also limits the ability to upgrade. Try to submit issues and PRs as much as possible.