The first point is obvious: you will not write something like jQuery or React for every project, but directly use what others have already written. The traditional method is: go to the official website to download the corresponding js file, and then put it in the corresponding path of your project, such as /assets/js/. And now with things like npm and yarn, 99.9999% of open access packages are in one centralized place, making them easy to find and download. It's like you used to have to go everywhere to download software, but now with 360 Software Manager, you only need to search and download it here. A lot of time is lost.
The second point is actually a developed version of the first point. Because all the packages written by everyone are placed here. If I want to write a new package, a small program in it happens to have been written by someone else, so I use it. This means that my package has a dependency on other people's packages. The dependency relationship of a large library (package) may be complex. For example, it depends on dozens of other packages. At the same time, each package is required to correspond to a certain version (because the versions are too different, there may be API incompatibilities. Condition). In this way, if you manually download each dependent package, it will be an exponential task:
A package depends on B and C, while C depends on D and E, B depends on F, G, H, D depends on I, J, K...
This is basically a task that humans cannot accomplish.
Of course, before there was a package manager, no one wrote a package that would rely on so many other people's packages. The result was of course duplication of work: each package implemented some commonly used functions by itself.
The above are the uses I can think of for now. If I think of others, I will add them.
After that job is done, you start doing a new job. Now you need this function again, and you need to make improvements:
function add(x, y, z){
return x + y + z;
}
It’s very simple, just copy and paste it and add z
02
The work you did in 01 to allow add to accept three parameters is a new version 库. However, you have received a new job, and this time you have to make improvements:
You have made countless improvements. One day when you need the simple addition function in 00 again: ———— You slowly go through your previous codes among the 99 tasks you have done. . . . Then copy it
This is a very troublesome thing. . .
Package managers automate all these tasks. You can package your code, then simply require the reference and use the npm command to install it with one click (you can also specify the version)
Repetitive and troublesome things will be solved by programming
There are at least two advantages:
Reuse code that others have already written
Manage dependencies before packages
The first point is obvious: you will not write something like jQuery or React for every project, but directly use what others have already written. The traditional method is: go to the official website to download the corresponding js file, and then put it in the corresponding path of your project, such as
/assets/js/
. And now with things like npm and yarn, 99.9999% of open access packages are in one centralized place, making them easy to find and download. It's like you used to have to go everywhere to download software, but now with 360 Software Manager, you only need to search and download it here. A lot of time is lost.The second point is actually a developed version of the first point. Because all the packages written by everyone are placed here. If I want to write a new package, a small program in it happens to have been written by someone else, so I use it. This means that my package has a dependency on other people's packages. The dependency relationship of a large library (package) may be complex. For example, it depends on dozens of other packages. At the same time, each package is required to correspond to a certain version (because the versions are too different, there may be API incompatibilities. Condition). In this way, if you manually download each dependent package, it will be an exponential task:
This is basically a task that humans cannot accomplish.
Of course, before there was a package manager, no one wrote a package that would rely on so many other people's packages. The result was of course duplication of work: each package implemented some commonly used functions by itself.
The above are the uses I can think of for now. If I think of others, I will add them.
00
You write a function and use it to do the work
01
After that job is done, you start doing a new job. Now you need this function again, and you need to make improvements:
It’s very simple, just copy and paste it and add z
02
The work you did in 01 to allow add to accept three parameters is a new version
库
.However, you have received a new job, and this time you have to make improvements:
99
You have made countless improvements. One day when you need the simple addition function in 00 again:
———— You slowly go through your previous codes among the 99 tasks you have done. . . . Then copy it
This is a very troublesome thing. . .
Package managers automate all these tasks. You can package your code, then simply require the reference and use the npm command to install it with one click (you can also specify the version)
Repetitive and troublesome things will be solved by programming