A watermark plug-in was introduced into the project before, after the introduction, IT was found that the watermark layer would make the page height problem disappear. Although the issue was raised, I really couldn’t wait for the official update, so I directly changed the source code and went to the emergency repair online. These two days, I found that my colleagues also encountered the dependency library problem. So from the present I or my colleagues encountered several situations want to modify the dependency library, do some solution summary.
It is recommended that the following checklist be completed before deciding to change the source code:
- Read through the relevant API of the corresponding version of the dependent library document and manual, and eliminate the error event that you reference wrong
- Locate the version of the dependency library and API parameter transfer requirements in node_modules to avoid incorrect parameter transfer caused by inconsistency between the official document and the library version referenced in the actual download
- Whether the official repair has been made, whether there is a relevant issue on Github, and whether the project can be upgraded to the latest version
- In a pure version of the project application, apply the dependency library of the corresponding version, excluding the failure of the dependency library caused by the overwriting of other content in the project
Case 1. There is a bug in the dependent library, so I need to fix the source file, but the official maintenance cannot meet my time requirement
Sure to modify the source code, but the time is really pressing, dependent library community is not active, there is no official issue, sorting out the description of reproduction steps and problem feedback communication will take time (but accurately describe the stable reproduction steps is also the first step to help myself locate the problem, it is necessary to spend), Basically, you really have to roll up your sleeves to locate source code fixes.
Here are two ways to fix it:
1. Evaluate the dependency library package size is not large, directly like the author before down to fix, replace the reference node_modules library address (can be through webpack alias, can also be imported path)
2. Dependent libraries cannot be easily replaced. Here is a recommended small tool, patch-package. It does not affect the normal upgrade of the dependency library, but the content you modify will be replaced with your patch.
Implementation principle: directly edit and repair in the dependency library, and then the tool will generate a temporary folder to store the dependency library of the corresponding version, and then compare with the directory of the dependency library you modified, and generate a patch file, the next time when NPM install is executed, the tool will merge the patch into the dependency library.
Specific operation steps:
- Add NPM postinstall to the package.json root directory of the project so that all patch files can be merged each time NPM install is executed:
"scripts": {+"postinstall": "patch-package" }Copy the code - Install patch – package:
npm i patch-package --saveCopy the code - Edit the dependency library <package-name> and run the following command to generate the patch file:
npx patch-package <package-name>Copy the code - If you run the following command, you will find that the newly installed package has been incorporated into the patch file you just modified:
npm installCopy the code
There e is a problem here if you are modifying package.json from a dependent library. B: well.. I already mentioned the issue.
Case 2. A library introduced by the dependency library was secretly upgraded. The online environment version is too low to be compatible
B: well.. Objective factors, online environment version is limited, can not be adjusted easily (I believe that even if you feedback, operation and maintenance students will tell you to find other solutions first, they only want one word, stability! Don’t be a jerk.
Four reference schemes:
- Json ———— Well, this approach works for dependencies that don’t require frequent updates or use a single scene, such as the watermark I started with
- Package. json fixed dependency library version ———- This method is applicable to NPM3 and below.
Npm3 flattens the path of all dependent modules so that dependent modules can be shared. Node_modules searches start at the root of the current dependent library, and if not, loop until the module or node_modules’ top directory is found. If the module does not exist, it will go to the mirror repository to pull the latest package.
NPM 5.0.x and later: Package. json and package-lock.json can be updated to lock the source address of the dependent library pulled. (Please refer to here for details)
3. Upgrade node.js———- if it is in NPM run build, because of ES high version syntax such as async await, resulting in webpack error. (Well, if you’re upgrading, ops should be watching you with a knife.)
4. Compile and parse the dependent libraries using Webpack Loader
ES8, ES10,ES11 are not recognized by WebPack, and because node.js versions are not compatible, you can use babel-loader to convert.
Case 3. The dependency library does not support the current business scenario and needs to be customized
B: well.. You can check whether the current dependent library supports extension. If the support is not high enough, you can remove it, customize it according to business expansion, and publish it to the company’s private library for sharing in a small range.
Of course, there are some cases where I feel it is not necessary to modify the source code:
Case 1. There is a problem with the latest version of the dependency library
You can now contribute to the open source community by raising the issue and backing back the stable version before making sure it doesn’t affect online content.
Case 2. Dependency library problems but active maintenance team
For example, antD Design Christmas snow shoveling Easter eggs, HMM, official rush repair is pretty quick, ah-ha ha ha
To be continued…