Transfer: https://www.cnblogs.com/weiyinfu/p/8471407.html

You don’t have to install node_modules every time, just use the soft connection: For Windows, mklink /j node_modules %APPDATA%\Roaming\ NPM \node_modules is used. For Linux, ls -s node_modules is used %APPDATA%\Roaming\npm\node_modules

Dependencies in package.json in NodeJS must have their own node_modules folder for each project, rather than sharing a set of node_modules between projects (as Maven does in Java).

Dependency management is a standard feature of every modern language. Dependency management and packaging tools are two different concepts, NPM is dependency management and Webpack is packaging tool. In Java, Maven implements both dependency management and packaging.

What is dependency management? Dependency management is basically building a directed acyclic graph. Project A depends on project B and project B depends on project C, so when your project depends on A, the dependency management tool will automatically make your project dependent on B and C. In order to construct directed acyclic graph, the most important thing is to transform items into nodes in directed acyclic graph. So there is often additional information about a project, such as description, author information, version information, etc. The hardest problem to solve with dependency management is versioning. Library A depends on library B, and library C depends on library B, but library A and library C depend on library B is not the same version, if the two versions of library B are compatible, ok, if they are incompatible, it will be very bad, this is an unsolved problem.

Dependency management in Java, Python, and Node.

  • The Maven repository in Java is global on the developer’s computer, with all project dependencies centralized in the local repository. Each project has pom.xml indicating which libraries in the local repository to rely on.
  • Much like Maven, PIP in Python also centrally stores packages on developers’ computers, but it doesn’t have versioning issues. That is, there is only one version of each Python library on your computer. In this case, when you rely on a library, you don’t need to specify the version number, just refer to the package name.
  • If you don’t write package.json, the dependencies are global libraries. If you write package.json, all dependencies are downloaded to the node_modules folder.

The node_modules folder has its pros and cons. The most obvious disadvantages are:

  • Every time you need to install a dependency, cost traffic, slow network time is very time-consuming
  • A waste of disk space, each node_modules contains a lot of tools, at 20 MB

The most obvious benefits are:

  • After installing using package.json, there is no version information in the node_modules folder, so package.json can be dropped. Moving/copying/packaging projects is relatively simple and is good for both development and deployment
  • This is the easiest package-dependent approach for those who design NPM. This is like maven automatically installing jar packages into the project’s lib after installing dependencies.
  • Feel free to change the code. You can change whatever is installed in node_modules without worrying about affecting other projects. When using Maven to manage projects in Java, if you want to customize a library and change its source code, you need to copy the library’s source code into the project, just like node_modules. The designers of NPM presumably assume that the front-end is constantly modifying the library’s source code.

I think different languages define dependencies differently. Libraries in Java are rigor libraries, libraries in Python are playthings, and libraries in Node are snippets of code. Since libraries in Node are positioned as code snippets, it is important to put the code snippets together with your project so that you can modify them easily. Over time, however, as the libraries in Node get bigger and more rigorous, this approach to code snippets becomes a bit of a bad one.

Conclusion: This is a kind of design, which has pros and cons.

Here are the answers from Zhihu:

The only benefit of global dependencies is that you save disk space. This kind of province is meaningless. First, if you’re haggling over hundreds of megabytes of hard drive space, you’re probably too poor for development. Second, it doesn’t save much if you need to support global multiple versions. As for the claim that NPM takes too long to install each time, I don’t think it’s a big deal. NPM install is not done every day, and the first time I checkout was slow, and the updates will be incremental. If it’s really slow (for example, because of firewalls), you can commit node_modules to Git. In fact, I think it can be made global, dependency modules are installed in the public directory, each project in NPM install using symbolic link to the corresponding version of the directory, or simply in require() to find the global module directory, so it is not troublesome. In fact, my team has included such a command, which is installed globally and init with symbolic concatenation, saving time and space. However, NPM did not do this. I think it was not considered in the beginning, so it would be difficult to change in the future. In fact, even the node_modules module’s multi-layer nesting caused the path to be too long, which was not considered in the design until NPM3.

Java solved this problem 20 years ago, and none of the subsequent languages were completely copied correctly


NPM installation warning, how to resolve?



E:\node\ Promise > NPM install bluebird E:\node '-- [email protected] NPM WARN enoent enoent: no such file or directory, open 'E:\node\package.json' npm WARN node No description npm WARN node No repository field. npm WARN node No README data  npm WARN node No license field. E:\node\promise>Copy the code

Why is it that every time I install the NPM library I get a message indicating that package.json is not found? I can’t find package.json in the node directory.


Because you need to
npm init, to create
package.json.



package.jsonBasic information and description of the project, author, warehouse address, dependent project, part of the NPM command, etc.



Package-lock. json is used for NPM install

Simple to understand: format XYZ

Corresponding to: Major version number. The second version number. The increment rule is as follows:

Major version number: When you make incompatible API changes,

Minor version number: When you make a backward-compatible feature addition,

Revision number: When you make a backward compatible problem fix.

Suppose we create a new project that will use Express. After running NPM Init, the latest express version at the time of writing this project was 4.15.4. (By default, NPM will install the latest version)

So in package.json,” Express “:”^ 4.15.4” is added as a dependency. Let’s say tomorrow, the express maintainers release a bug fix, so the latest version is 4.15.5. Then, if someone wants to contribute to my project, they will clone it and run NPM Install since 4.15.5 is a higher major release that was installed for them. We both have Express dependencies, but we have two different versions. In theory, they should still be compatible, but perhaps this bug affects the functionality we are using, and our application will produce different results when comparing Express versions 4.15.4 to 4.15.5.

The purpose of package-lock.json is to ensure that the dependencies of our application are consistent and compatible.

If the package-lock.json file does not exist, it will be generated automatically when NPM install is used. When the package-lock.json file is present, NPM install will install the version of the plug-in specified in package-lock.json, and will install it much faster than if the package-lock.json file is not present. The package-lock.json file already contains the version of the plug-in, the download address, the entire node_modules structure, and so on.

If package-lock.json is present, each NPM install will install the version of the plug-in in package-lock.json. In this way, the same package-lock.json file is installed with the same plug-in version.

If a plug-in version changes. You don’t want to delete the package-lock.json file and regenerate it. NPM install plugin@version and re-install the plugin and specify the version of the plugin so that package.json and package-lock.json are automatically updated. Of course, you can also modify the package-lock.json file directly, so that when NPM install, the modified version will also be installed. However, if you modify package.json but not package-lock.json, NPM install will still install the plugin version in package-lock.json.

https://www.cnblogs.com/shengulong/p/9463176.html