In projects with package-lock, we can use NPM CI instead of NPM install.
preface
Here’s what you should know before reading this article (click the link for a quick read) :
- NPM relies on version management
- You should at least know what an Taro is.
Why use NPM CI
Recently, Jenkins was successfully built, but the project failed to run. When investigating the problem, it was found that the installation of the dependent version was not correct when Jenkins was built, which led to the construction failure.
The probability of this happening is relatively small, because by default, we install dependencies with ^ in front of the version number to limit the installation of large versions of dependencies.
The problem this time was caused by the misalignment of versions when installing Taro. If we need to use Taro, in addition to installing @tarojs/cli, we also need to install some dependencies (which will be installed automatically when we create projects using the Taro CLI), such as: @tarojs/ Components, @tarojs/ Runtime, @tarojs/taro, etc.
Taro requires that when installing these dependencies, the VERSION of the Taro CLI should be consistent with the version of the Taro related dependencies in the project. Details about this rule can be found in the official documentation (Taro).
In our package.json, we only use ^ to limit these dependencies to major version updates, and such restrictions are not sufficient for Taro.
Originally, our plan was to remove the first ^ of the Taro dependencies, so that the versions of these dependencies are completely fixed, unless we manually modify them, such a plan is of course not a problem.
But beyond that, we should have another plan. Remember, we run and debug the project locally perfectly fine, which means our locally installed dependencies are fine.
So another option would be to have Jenkins build with the same dependencies installed and used as we do locally, if you say push node_modules directly into the repository, that would also solve the problem. But I’m not sure your colleagues will swear at you and kick your ass.
At this point, we should think of another sly thing we might have forgotten: package-lock.json. This is the source of all dependencies in the node_modules folder.
Yes, we could have solved the problem by locking the source of the problem, i.e. locking package-lock.json, and allowing Jenkins to build and install dependencies using packages that are consistent with our local dependencies.
An elegant tool for doing this is NPM ci. We can use NPM CI instead of NPM install, as shown in the figure, and replace NPM install with NPM CI in the build script to achieve the desired effect:
For a scenario using NPM CI, it would look like this:
In projects with package-lock, we can use NPM CI instead of NPM install.
npm ci vs npm install
As for the differences and advantages of NPM CI over NPM install, please refer to this article: NPM ci command. This article has clearly stated the connection between them.
I am a tail
When I finished writing this article, my heart suddenly felt very comfortable. It was like the 1950s, back in the days of black and white movies, and a tall, lanky English gentleman was talking on a podium in the middle of the stage.
Refer to the link
- NPM ci command.