noun | explain |
---|---|
先生 | merge request |
oci | Orange CI Is a ci service used internally by Tencent |
The story goes like this
One day after I happily raised MR, I started to do other work and waited for the OCI production line to finish. However, shortly after I received the company micro push that the production line reported an error, I immediately realized that it was caused by the NPM package version problem from the error log. Originally thought to rest easy of I immediately chrysanthemum one tight, how fat four?
background
Briefly introduce what I did this time. To meet service requirements, two devDenpendencies, Commander and @tencent/ Alloyperf, are added to a large warehouse.
There was an incident where alloyperf had recently been optimized and upgraded, and at some point near the end of development, after one of the trunk code merging operations, the program reported an error. Of course, it is not a devastating error, but a TS type error, basically, the package of the old version had export an interface, I used this interface, but it did not export in the new version, resulting in an error. To solve this problem, it can be solved, but I don’t want to spend time on such a small thing, maybe it only takes 5 minutes to solve the problem, but after solving the problem, such as testing, running the assembly line, the waiting time of the program during operation, etc., it may add up to 50 minutes. So one of the easiest ways to do this is to leave nothing at all and just lock on to the original package version.
To solve the problem
Alloyperf: “@tencent/alloyperf”: “^1.6.8”
The semantic specification for NPM package versions will not be expanded in this article, but read docs.npmjs.com/about-seman… @1.0.0 => must be 1.0.0 ^1.0.0 => Maybe 1.3.6 ~1.0.0 => Maybe 1.0.12
How do I view the current installed version number? In node_modules / @ tencent/alloyperf/package. The json version of the fields to view.
It was found that version 1.7.6 was installed. Easy, go back to version 1.6.8! NPM I @ tencent/[email protected] – D
Package. json displays the package version as “@tencent/alloyperf”: “^1.6.8” was different from the “1.6.8” I was expecting, so I checked the package version again and found that version 1.6.8 was installed correctly and the package-lock.json file was synchronized correctly. Therefore, it can be concluded that:
NPM i@ installs the specified version of the package correctly and updates package.lock.json, but the package version number displayed in the package.json file is “^”.
The package is indeed installed back, but the package.json file does not display the correct version number after executing the command. When the following students execute the installation command, or the assembly line installation package, won’t it be installed back to the latest version 1.7.6? Let’s run some tests!
Package. json Displays the package version as “^1.6.8” package-lock.json displays the package version as “1.6.8” the actual package version as “1.6.8”
- Execute NPM I again locally
Result: The package version does not change.
- Delete package-lock.json and execute NPM I
Result: Package-lock. json file is generated with the package version unchanged.
- To delete the package, execute NPM I
Result: The package version does not change.
- Delete package-lock.json, delete the package, and execute NPM I
Result: The package information of the package and lock file is upgraded to the latest version 1.7.6, and the package version displayed in package.json remains unchanged.
The following conclusions can be drawn:
If there is a package-lock.json file when NPM I is executed, the package version of the lock file is used to install the package
- If the installation package is locally available, only package-lock.json files are generated after execution
- If a package is not installed locally, the latest version of the package is installed
Description of the NPM document
Returning to the question, I now hope to achieve three effects by executing the separate install alloyperf command:
- Package. json Displays the package version, which is the installation version specified in the command
- The package version information displayed in package-lock.json is the same as that in ⬆️
- The actual installation package version is the same as ⬆️
Let’s execute the following two commands:
NPM i@tencent/Alloyperf -d package will be installed with the latest version, which obviously does not meet my expectations.
NPM i@tencent /[email protected] -d As mentioned above, everything is expected except package.json showing the package version number as “^1.6.8”.
Description of the NPM document
Does NPM offer a solution to these problems? The answer is definitely there!
Documentation in NPMDocs.npmjs.com/cli/v7/comm…It says:With this parameter, NPM’s default behavior is replaced by the exact version number provided in the command when saving dependencies.
So the installation command should be changed to NPM i@tencent /alloyperf -d -e
I notice that NPM’s default Semver range operator is mentioned at the end of the -e parameter description. Can this default behavior of NPM be changed in any way? You can!
Documentation in NPMDocs.npmjs.com/cli/v7/usin…It says:That is, every time a package is installed and given either -s or -d, NPM’s default behavior is to prefix the package version number with “^” when it is registered in package.json. This default prefix is changeable.
Problem solved!
conclusion
NPM install is usually only used when new dependencies need to be added. For NPM install, many people may not know what the process does. It is recommended that you find relevant information to understand. I think this is an essential knowledge for modern front-end development. Javascript gets a lot of jokes about this and that, but we still write it every day, and then ES6/7/8/9, and typescript, and so on. It is because of our profound understanding of JS that we have the subsequent vigorous development. Don’t say, I also have to make up for the lesson!
trivia
When I was debugging, I noticed that there was a command in the log returned by NPM called NPM fund, which is often seen in the log, so I went to look it up. It basically says something like this: list all the packages that you want people to donate money to. If passers-by are kind enough to give you some money for your efforts, you can make a few changes in package.json, and once a project uses your work, they’ll have a chance to see your needs and give you money if they’re in a good mood.