What are js package managers like Yarn for?

Question

npm

First what I understand, then what is not clear.
Node.js is a Javascript interpreter on the server side.
In general, Javascript is a client-side programming language that is executed on the client side in the browser. Then someone thought, why not use it on the server side, what the heck. difficulties, I know javascript, I want to use it everywhere. But there is no browser on the server, so we came up with a tool that would understand and execute Javascript code on the server. Node.js became this tool. It was installed directly on the server and it did its job. It was necessary in order to write server applications in js, right? What does the npm package manager have to do with it? Why was it needed for node?
Everything is clear with bower. Tired of dragging all sorts of jquery plugins, js plugins, etc. on the frontend, code created by different people from sites and from github manually. I wanted convenience, we created a tool. I poked the command - all the code fell into the folder, connected it with the script tag on the page with html and rejoice.
Now I'll jump ahead a bit. NPM and bower had differences until recently. Now they don't seem to exist. A further development of npm is yarn, which makes sense to use if only because of its speed (parallel installation). Works with the same libraries as npm.
Now questions:
1) What does NPM have to do with it? Why the hell did he surrender to Node? And how did he migrate to the frontend? Is it just an interesting feature of Node that frontends started using while bower evolved in parallel?
2) It turns out that some libraries are adapted for bower, others are not adapted. Is it the same for npm? Theoretically, they can not intersect?
3) Why do I need (I will say simply) on the "site" some file package.json, lock.json? And in general, why do I need any dependencies? Installation - yes, convenient. But after all, all conditionally plugins (gallery, jquery, etc., etc.) are part of the site and usually do not depend on each other. Maximum - jquery plugin depends on jquery itself. Plus, it has the added benefit that you can pass in the lock.json file and recreate the work environment exactly on another machine. What for? I have everything stored in Vagrant's shared folder: all project files, all connected libraries, database - in the same place in migration files (I use Laravel). It is necessary to transfer the development environment - I give vagrantfile. It is necessary to transfer the project - I copy its folder and give it away, the person deploys the database and everything works. What would a thesis about advantage look like? I give the right person the public folder without pictures, without scripts and without css, and he: "So, so, cool, where is lock.json, now I'll upload all the javascripts to daddy." And let's load the scripts. In this way, you can also make pictures dependent on each other and load them with a third-party tool, css ... What is the advantage? I do not understand. If there is a target use that I just have not encountered, then tell me. Maybe this is necessary only for single-page applications on React, for example, when it uses calls related to a specific plugin (and they are more complex in structure and already dependent on each other), and should it be? In this way, you can also make pictures dependent on each other and load them with a third-party tool, css ... What is the advantage? I do not understand. If there is a target use that I just have not encountered, then tell me. Maybe this is necessary only for single-page applications on React, for example, when it uses calls related to a specific plugin (and they are more complex in structure and already dependent on each other), and should it be? In this way, you can also make pictures dependent on each other and load them with a third-party tool, css ... What is the advantage? I do not understand. If there is a target use that I just have not encountered, then tell me. Maybe this is necessary only for single-page applications on React, for example, when it uses calls related to a specific plugin (and they are more complex in structure and already dependent on each other), and should it be?
4) The bower developers wrote on their website that it is better to use Yarn. Everyone, forget about bower, forget about npm? I am for progress without ideological preferences. Better is what is more convenient and better.
5) One more time. Applied to web development. Are all three tools Yarn, NPM, Bower used for the same thing?
Simplifying, to compile a list of necessary js libraries for a specific site (project) and automatically and conveniently install them, but at the site creation stage, because the further use of such a list is doubtful. These instruments just went and developed in parallel and in their own ways. Now everyone has crossed paths, and only one thing will remain among the leaders?

Answer 1

1) What does NPM have to do with it? Why the hell did he surrender to Node? And how did he migrate to the frontend? Is it just an interesting feature of Node that frontends started using while bower evolved in parallel?

This is a package manager to distribute packages centrally instead of searching all over the internet. All languages/development environments have come/will come to this. c# has nuget, php has composer...
This is good if the code you write uses only dependencies of the first level of nesting. In larger projects, dependency nesting can reach levels 3 and 5. This is when the package you use depends on three more packages, each of which, in turn, depends on several more, each of which can bring a few more dependencies ... Can you put it together with your hands?
It is in your case. But that doesn't mean that everyone has the same.
vagrant is a third party dependency.
You don't see that Node.js is all that server. This is primarily a development toolchain, and then a js interpreter. For historically, before the advent of node, the mere thought of js on the server side evoked emotions like "WTF? O_o Seriously?" and "LOL xD". Therefore, node.js was released as a ready-made toolchain for development on top of the js interpreter. The fact that other managers appeared on the npm repository is the work of the community. How are they better / worse and in what cases - I think practicing people will answer you today. Although, most likely sent to the search.