“This article has participated in the call for good writing activities, click to view: the back end, the big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

Introduction (Problem Description)

Today, the team has a new project, and the framework is already available, so let’s follow the normal process:

  • 1. Clone project codegit clone ***.git
  • 2. Switch to the node version and install the dependency on YARNnvm use ***; yarn install;
  • 3. Then run the projectyarn run ***;
  • 4. Finally, you can modify the code or business development

The imagination is so beautiful, the reality is cruel.

Analysis: in the second step, I failed to install the dependency and failed to download the dependency from the network. Then I looked at the dependency which needed a specific Intranet to install, and I did not have the VPN, so the installation was unsuccessful. Remember that the UI already had this dependency package in other projects before, so immediately came up with a solution:

Solution 1: Manually import dependency packages

Remove the dependency from the configuration, install other installable dependencies, and copy the dependencies from somewhere else to the node_modules of the current project. This operation is fine and should work.

However, this operation has A pit, dependency A contains dependency B, and dependency B failed to install for the same reason, then the operation will generate A new error.

The following diagram shows the installation of dependency package A:

From this it is found that the installation of dependency package B failed.

Node_modules = node_modules = node_modules = node_modules = node_modules = node_modules = node_modules = node_modules = node_modules

The big downside to this is that if the rest of the team does the same, it’s too annoying to continue development. So we thought of something better.

The following configuration rules depend on the configuration:

Before we talk about option 2, let’s talk about some rules for dependency configuration. The main points of this article are:

1. Dependency package name :VERSION

This is the most common dependency configuration. VERSION is a VERSION number configuration that follows the SemVer specification. When NPM installs, packages that fit the specified VERSION range will be downloaded from the NPM server. For example, install vuE-bus of the latest version of vUE with a specific version number

"Vue" : "2.5.17", "vue - bus" : "^ 1.2.1",Copy the code

2. Dependent package name :DWONLOAD_URL

DWONLOAD_URL is the address of a downloadable tarball package. This.tar will be downloaded and installed locally when the module is installed. Such as:

"test2-js": "http://cdn.com/test2-js.tar.gz",
Copy the code

3. Dependency package name :LOCAL_PATH

LOCAL_PATH is a local dependency package path, such as file:.. / pacakges/pkgName. This works when you are testing an NPM package locally, and should not be applied online.

"@ yh/ICONS - SVG: file:. / lib/ICONS - SVG - 4.0.1..tgz",Copy the code

4. Dependent package name :GITHUB_URL

GITHUB_URL is github username/modulename, for example, ant-design/ant-design. You can also specify the tag and commit ID at the end. Such as:

"Antd" : "ant - design/ant - design# 4.0.0 - alpha. 8",Copy the code

5. Dependent package name :GIT_URL

GIT_URL is the git URL of our clone code base, which is also the git ***. Git used in my second solution, for example:

"@ yh/ICONS - SVG" : "git + http://10.16.0.137:8086/wb/icons-svg.git",Copy the code

This is my Intranet warehouse, will fail to connect, if you have to try:

 "vue-count-to": "git+https://gitee.com/wangxiaoer520/vue-count-to.git",
Copy the code

With that said, we can move on to my second solution

Scheme 2: Git download and install dependency packages

Some people may look at this and ask, why not release the dependency package? This is related to the project constraints, although it is a simple package based on Ant-Design, but it belongs to the company and is explicitly required not to publish to the Internet, only to live on the Intranet platform (open source spirit, I don’t know).

So on to plan two:

Create a new project and upload the dependency packages

New project in own warehouse:Class in an existing dependency package

git init
Copy the code

Add the repository source address to the dependency package

git remote add origin ***.git
Copy the code

Upload and submit

git add .; Git commit -m 'commit info '; git push -u origin master;Copy the code

This dependency package can then be used in the configuration:

Dependent package name :GIT_URLCopy the code

Modify the configuration file of the original project:

I just learned that dependency B(@yh/ ICONS -svg) in dependency A will fail to be installed. I created A new project in the Intranet code management platform for managing dependency B, and then changed the file dependency configuration in A to the corresponding onegit ***.git Assuming there is no dependency in the icons-SVG dependency C is required to be installed on the Intranet, as I have already verified!Then create another project in the Intranet code management platform to manage dependencies A(@hsa/ hSA-UI)

Then upload the code and tell colleagues, you can directly connect to the Intranet of the company to download the dependency successfully, and there will be no dependency installation failure.

PS: How to create new projects and upload dependency packages in the warehouse, this I will not write it!

Conclusion:

In fact, the operation I did is to change the dependency package to a colleague and I can access the download place, not the original source address, perhaps no technical content, but a porter.

If you have a better solution, welcome to comment to tell the landlord, younger brother modestly consult.

! Thank you very much for reading it carefully

Might as well point a praise, encourage the building Lord, thank you!

digression

Flag: I want to move up and get a prize