Welcome to pay attention to the rich way Web development team, PHP, front-end need you. Lack of people crowd
Day by day in the growth of fu Tu, friends are more and more. Iterations of front-end updates are going on all the time. Vue has been used as the main development framework for the front end. Just think about two years ago, I was writing JQ, followed by Angular.js. Front-end packaging also changed from the original package file submitted to Gitlab library, to Jenkins (package file not included in the library), and then to today’s Gitlab CI.
Dare to try, promote the implementation of the landing.
Today, I would like to share with you the pit encountered by front-end packaging access to Gitlab CI.
Also included is a component for downloading Gitlab CI packages: The View component
background
That’s right. I’ve been writing about the background lately. This is supposed to be a tutorial post, but it’s pretty boring. The reason why I want to write this article is because I really encountered some very troublesome things. Without further ado, let’s get down to business.
Recently we are integrating front-end code packaging into Gitlab CI and using Docker as Executor, that is, packaging front-end code in Docker and collecting the packaging results for release. When Docker images are packaged, they naturally choose the official Node image, the latest version (Node 10).
At first we tried to plug in a few projects, some using NPM scripts and some using Gulp, and everything was fine. Gulp: Gulp: Gulp: Gulp: Gulp: Gulp: Gulp
$ gulp gitlab-ci gulp[85]: .. /src/node_contextify.cc:631:static void node::contextify::ContextifyScript::New(const v8::FunctionCallbackInfo<v8::Value>&): Assertion `args[1]->IsString()' failed.
Aborted
ERROR: Job failed: exit code 134
Copy the codeOne look at the error message and immediately realize that this error is not coming from the JS layer, but from the Node native layer is beyond my comprehension.
Module version compatibility problem
After searching, I found a solution in Chinese: gulp error after upgrade node10. The paper gives the following solutions:
rm -fr node_modules
rm -fr package-lock.json
npm cache clean --force
npm install
Copy the codeSo how does this work? I did not see an explanation in the article, and the article itself is not very clear. I added NPM cache clean –force to the CI script with a grain of salt.
Then I did a search and soon found some issues related to this issue:
- Nodejs /node: core dump during node 10.0.0 module installation
- Nodejs /node: the new release is not compatible with Gulp ^3.9.0
- Gulpjs /gulp: Merges the upgrade of graceful-FS back to gulp 3
- Gulpjs /gulp: node 10 crashes
- The Isaacs/Node-graceful-fs v3.x branch is not compatible with node.js master
- Isaacs/Node-graceful-fs V3.0.11 relies on Natives 1.1.1, which is not compatible with Node 10
With NPM LS, I saw the natives module version 1.1.1 and found the real problem: Gulp relies on vinyl-fs, vinyl-fs relies on graceful-fs, and natives are not compatible with Node 10 until 1.1.3.
So the solution is simple, think of a way to upgrade the module is not good?
How do I upgrade indirect dependencies
NPM info Gulp checked to see if the latest version was 3.9.1. Then NPM info Gulp checked to see if the latest version was 3.9.1. So how do you upgrade this indirect dependency?
I’ve gone around the bend here, and modules directly dependent on package.json can’t be upgraded, nor can NPM Update. I wondered if I could solve the problem by explicitly installing this module.
NPM install [email protected]Copy the codeAfter installation, I should also delete the direct dependency in package.json (since I do not rely on it directly, I will not use it). Then look at dependencies again:
▶ NPM ls natives [email protected] / Users/TooBug/work/oa/learn/frontend └ ─ ┬ [email protected] └ ─ ┬ [email protected] └ ─ ┬ [email protected] └ ─ ─ [email protected]Copy the codeThis time it’s right.
However, I am performing this operation on the machine. What exactly does this operation change? If I run NPM install on CI again, will I still install the old version? After all, nothing has changed in package.json.
I checked git diff and found that package-lock.json was modified, in which the natives was changed from 1.1.1 to 1.1.3.
"Natives ": {"version": "1.1.3"," Resolved ": "Http://registry.npm.oa.com/natives/download/natives-1.1.3.tgz", "integrity" : "sha1 - RKV5vmRQfqLW7RygSpQVkVz3VVg ="},Copy the codeThen she realized: NPM installed the latest semantic version of the installation module, but NATIVES 1.1.1 was installed instead of 1.1.3 on CI, because package-lock.json was locked. This leads to incompatibility issues with Node 10.
This also explains why other projects did not have this problem, as other projects did not include package-lock.json in the repository and the Natives 1.1.3 version was installed naturally at installation time.
So I went back to the original article and suggested a solution:
rm -fr node_modules
rm -fr package-lock.json
npm cache clean --force
npm install
Copy the codeThis is actually quite effective because it removes package-lock.json directly and then reinstalls the latest version to generate a new package-lock.json to fix the problem.
Extension: How to use it correctly in a projectpackage-lock.json
Finally, the correct usage of package-lock.json is also added. I know, but I stepped in the hole by mistake. If you don’t know how to use it, you may stay in the pit longer.)
First, you need to make sure that the NPM version is above 5.6, because the package-lock.json processing logic was updated several times between 5.0 and 5.6. Those above 5.6 are cognitively logical.
Then, instead of using package-lock.json in your project if it is not necessary to lock the version, specify –no-lock when installing the module.
If package-lock.json is present in the project, the module will be downloaded and installed using the version and address specified in this file. (Unless it doesn’t match the version specified in package.json.)
Finally, if the version is already locked and you need to update direct dependencies, install the specified version directly, and both package.json and package-lock.json will be updated synchronously. If you need to update indirect dependencies, you need to install them manually, as in this article, to ensure that package-lock.json is updated to. Or if the locking of other modules is not that important, you can simply delete package-lock.json and reinstall it, which is equivalent to updating all (directly dependent + indirectly dependent) modules.
Original link: View original article