It mainly explores the impact of different Dependencies configurations on projects

A, devDependencies

How to add devDependencies dependencies

NPM install <package-name> --save-dev // NPM I <package-name >-d

​

This configuration item places the compile, package, test, format modules, etc., that you need to use during local development

When you install a dependency, devDependencies is not installed

Second, the dependencies

How to add dependencies

NPM install <package-name> // abbreviation NPM I <package-name>

​

If you don’t have the code you need to actually run your project, you’ll get an error

1. Unique dependence

​

For example, the Faker-Project relies on the SDK-A

/ / faker - project {" name ":" faker - project ", "dependencies" : {" SDK - a ":" 1.0.0 "}}

​

SDK-Core is included in the dependencies of SDK-A

/ / SDK - a {" name ":" the SDK - a ", "version" : "1.0.0", "dependencies" : {" SDK - core ":" 0.0.1 "}}

​

After the faker-project executes NPM install, the directory structure is as follows

Faker project | ├ ─ ─ node_modules | ├ ─ ─ the SDK - a | └ ─ ─ the SDK - core | └ ─ ─ package. The json

All dependencies are set horizontally

2. Repeated dependencies

2.1 are not compatible

Suppose the Faker-Project relies on SDK-B again

/ / faker - project {" name ":" faker - project ", "dependencies" : {" SDK - a ":" 1.0.0 "+" SDK - b ":" 1.0.0 "}}

​

SDK-B also happens to rely on SDK-core, but the version of SDK-core is different

/ / SDK - b {" name ":" the SDK - b ", "version" : "1.0.0", "dependencies" : {" SDK - core ":" hundreds "}}

​

After the faker-project executes NPM install, the directory structure is as follows

Faker project | ├ ─ ─ node_modules | ├ ─ ─ the SDK - a + | ├ ─ ─ the SDK - b + | | └ ─ ─ node_modules + | | └ ─ ─ the SDK - core / / hundreds + | | | └ ─ ─ the SDK - core / / 0.0.1 | └ ─ ─ package. The json

Dependencies install a separate copy in their own node_modules to avoid conflicts

2.2 compatible

If the SDK-core version is compatible

/ / SDK - a {" name ":" the SDK - a ", "version" : "1.0.1," "dependencies" : {- "the SDK - core" : "0.0.1" + "SDK - core" : "^ 0.0.1"}}

​

The two will share a dependency (if one is installed first, then the other. Finally, the directory structure will behave the same as in the incompatible case.

Faker project | ├ ─ ─ node_modules | ├ ─ ─ the SDK - a | ├ ─ ─ the SDK - b | └ ─ ─ the SDK - core / / hundreds | └ ─ ─ package. The json

3. History

Node_modules are not set horizontally until NPM 3. Dependencies of dependencies are nested directly

Third, peerDependencies

I understand as “peer dependence”

Used in a published codebase to indicate that the host environment is required to provide module dependencies under this configuration, and is dependent on the host environment. NPM (after version 3.x, before version 7.x), yarn does not automatically install dependent modules in this configuration. An alarm is raised.

Time node:


NPM 3 – May 2015


NPM 5 – May 2017


YARN 1 – September 2017


YARN 2 – January 2020


NPM 7 – March 2021

​

PS: For ease of understanding, the following:

  • New versions: NPM 7 and above automatically install PeerDependencies
  • Npm 3.x ~ 6.x and yarn do not automatically install peerDependencies

​

1. Unique dependence

/ / SDK - a {" name ":" the SDK - a ", "version" : "1.0.2," "peerDependencies" : {" SDK - core ":" ^ 0.0.1 "}}

1.1 the old version

Dependent modules under this configuration will not be installed automatically. An alert will be sent. User installation is required

Warning "> [email protected]" has unmet peer dependency "sdk-core@^0.0.1".
Faker project | ├ ─ ─ node_modules | └ ─ ─ the SDK - a | └ ─ ─ package. The json

1.2 the new

Automatically installs, and only one always exists. Directly under node_modules

1.3 the difference between

Whether it’s automatic or manual, the end result is. The dependencies in peerDependencies are installed directly under node_modules

The biggest difference is that the older version is installed manually by itself. It is in the project dependencies, but not in the new version

/ / faker - project {" name ":" faker - project ", "dependencies" : {" SDK - a ":" 1.0.3 ", "the SDK - core" : "^ 0.0.1" / / difference}}

​

​

2. Repeated dependencies

2.1 are not compatible

2.1.1 the old version

Only the different versions of peer dependency information will be prompted at install time

Warning "> [email protected]" has unmet peer dependency" alert ". Warning "> aca" has unmet peer dependency "[email protected]".

​

2.1.2 the new

For version-incompatible dependencies, an error is reported at install time

You can prevent peerDependencies from being installed automatically with –legacy-peer-deps

2.1.3 How to handle incompatible peerDependencies

There is currently no way to make incompatible peerDependencies work individually. So when this happens, the usual way to deal with it is to change one of the package versions with a dependency on peerDependencies. Make it dependent on peerDependencies of another version and compatibility with other versions

2.2 compatible

/ / SDK - b {" name ":" the SDK - b ", "version" : "1.0.3", "peerDependencies" : {" SDK - core ":" ^ 0.0.1 "}}
/ / faker - project {" name ":" faker - project ", "dependencies" : {" SDK - a ":" 1.0.4 ", "the SDK - b" : "1.0.3"}}

Multiple projects are compatible with Peer Dependencies

2.2.1 the old version

Do not install automatically, prompt only

2.2.2 the new

Automatic installation, as well as the only dependent behavior

2.3 Special circumstances

If SDK-core exists in both peerDependencies and Dependencies

2.3.1 the old version

Will not be installed, equivalent to only peerDependencies

A new version 2.3.2

Will install automatically, equivalent to just Dependencies

In both cases, version compatibility is not determined

2.4 Nested dependencies

Or even more extreme, like in dependencies if you have peerDependencies. See the article below for details

​

Four,

  • Dependencies that are not needed at runtime are placed in devDependencies
  • PeerDependencies are used only for plug-in class dependencies (for example, SDK-Core is a dependency, and SDK-A and SDK-B are developed on top of it)
  • Requires runtime singleton dependencies (Vue, React, and so on can only have one instance at a time) using PeerDependencies
  • The rest of the cases use dependencies

V. Other Dependencies

Other less common dependencies

1. optionalDependencies

OptionalDependencies is optional, and you can use it if you have dependencies that will still run even if the installation fails or if you want NPM to continue running. Also, optionalDependencies overrides dependencies with the same name, so don’t put it in both places

For example, an optional dependency package is like a plug-in to a program, executing one existing logic if it exists, and another logic if it doesn’t.

try {
  var foo = require('foo')
  var fooVersion = require('foo/package.json').version
} catch (er) {
  foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
  foo = null
}

// .. then later in your program ..

if (foo) {
  foo.doFooThings()
}

2. bundledDependencies / bundleDependencies

The BundledDependencies object is an array of dependent package names that will be bundled into the final published package at the time of publication. Such as:

{" name ":" fe - weekly ", "description" : "the ELSE weekly", "version" : "1.0.0", "main" : "index. Js", "devDependencies" : {" fw2 ": "^ 0.3.2", "grunt" : "^" 1.0.1, "webpack" : "^ 3.6.0"}, "dependencies" : {" gulp ":" ^ 3.9.1 ", "hello - else" : "^ 1.0.0"}, "bundledDependencies" : [" fw2 ", "hello - else]}

Execute the packaging command NPM pack, and in the generated fe-week-1.0.0.tgz package, fw2 and hello-else will be included. However, it is important to note that both packages must be declared in devDependencies or dependencies first, otherwise the packaging will report an error.

reference

Several classes of NPM dependency package management you need to know –
https://zhuanlan.zhihu.com/p/29855253