Just start somewhere; and in a month or two, you would mostly know which libraries you need to add to your project.
The best way to go about it, is to check a few popular open source projects; what libraries they typically use.
> I am also asking if any of those libraries will be around in a year?
You can check the download stats of these in https://npmjs.com, and activity on the GitHub repo, before adding it to your project.
If they are still around, but have published a new major version to update a few APIs; you can slowly migrate to it.
If not, you'd read some Medium post or Hackernews discussion, about what is replacing that.
There's something called Greenkeeper (https://greenkeeper.io/) that integrates a GitHub bot to your repo, and files a PR when something needs to be upgraded.
You can implement something similar on your own, if you aren't interested in using something like this.
A materials engineer simply cannot afford to pick concrete unless she knows the specific load and weathering characteristics of it. The same should be true for software projects. You shouldn't use cheerio because everyone uses it in their project, but because you've looked through the source and considered all your options for need it fills.
Sorry for the rant, but I think it's important to encourage software developers to think before they code.
As an outsider the big amount of dependencies look daunting, but the tendency in JavaScript as of late has been to use small libraries that do one thing, do it well, and play well together with others (Composable is the buzzword). Whereas Java and C# for instance tend to have macro libs that "Have it all bundled in".
It's different approaches, and you might not _need_ absolutely everything, then again you might, and you are in a much worse position to evaluate that as an outsider than the developer who made it.
All in all, I quite like the JavaScript approach where pieces are just that, instead of a pre-built lego set which I'll have to study to build, I have small pieces which give me more flexibility to take my project where I want to take it. The tradeoff, and they naturally exist, is that dependency maintenance is substantially more difficult, and the likelihood of something you use being straight up abandoned raises for each dependency you add. Which might lead to having you either maintain that piece yourself, or abandon it, and add another piece that fulfills a similar role.
Do you see ancient but popular PHP frameworks going unmaintained and reach the point where they collect a significant amount of bugs and vulnerabilities? Not really...
Libraries of code.
> I am not saying he is wrong...
Good, because they are right.
> I am just saying that I don't have the capacity to play in that playground
Good, because you are right.
> I am also asking if any of those libraries will be around in a year?
Yes. Some have been around for years already.
Listen, it's fine that you are using Python. It's fine that the OP is using JavaScript. It doesn't make you wrong. It doesn't make them wrong. Just because you are confused doesn't make it wrong. Hell, Python should worry about itself; it has enough warts of it's own it doesn't need people pretending that a library like bcrypt is confusing.
I mean look at this:
What the hell is all that? I am not saying he is wrong... I am just saying that I don't have the capacity to play in that playground. I am also asking if any of those libraries will be around in a year?