Very nice article. Valuable conclusion as well. Somebody can think that almost every nodejs developer knows what's in https://nodejs.org/api/index.html https:/

Very nice article. Valuable conclusion as well. Somebody can think that almost every nodejs developer knows what's in https://nodejs.org/api/index.html https://nodejs.org/api/index.html - but I don't think that's actually true. One of the better tips on how to be a better nodejs developer is to simply read it from top to bottom. It's really not that long and gives valuable insights. Another insight, which I'm exploring recently in node projects, that is somehow related to this, is "debloating" node npms/projects. After looking at dependency tree used by some of my own npms/projects I was surprised (after few seconds of dependencies recursively unfolding themselves), then shocked (even well before they fully resolved). There is something good about many npms being available but there also seems to be something wrong about how dependency tree spreads out - in many cases duplicating functionality, bringing completly unnecessary dependencies and their friends and a lot of "garbage" in general (ie. thousands of test files/fixtures/what not are not necessary but they come to the node_modules party anyway) etc. I'm not trying to say that `npm i` is bad and should be avoided because that would be nonsense - but I'm trying to say that being concious about what it actually does in your npm/project is something valuable, especially for npm authors where those decisions will have multipled effects.