Analysing 1.65M versions of Node.js modules in NPM
blog.nodeswat.com
blog.nodeswat.com
npm no longer allows dependencies to be unpublished after they've been up for 24 hours. The issue that happened with left-pad was solved.
It's possible for someone to instead publish a new non-functional version of a package, but I don't think that's unique to npm, and that won't affect people who have pinned to a specific version of the package.
"Grab a cup of coffee and enjoy the deep dive into the NPM ecosystem."
Now taking my last sip of the coffee, i'm happy never to have spend a single second on node.js. The rapid and simple development via node.js does not weigh up to the bizar number of dependencies and crazy stuff that can originate from that.
Interesting to see in your stats there is a decline in development, at least of new modules. Either the ideas people can come up with are drying up, or i'd be inclined to say (interest of) nodeJS development is in decline?
Also, you need to test and ideally stage before deployment.
If you don't want to deploy with `npm i` then just copy the files or compress and then copy that and uncompress.
Also the new flat modules reduce the total install time.
The author advocates copy-pasting code rather than including small modules. To me this is very misguided.
Npm is the greatest code-reuse system ever created. The failure of software engineers to recognize that is an indication to me of a lack of depth of engineering knowledge and experience.
Deploys may take a few minutes. You just need to factor that and don't switch off prod servers until updated ones are ready.
Especially dealing with many external dependencies is a real pain. A really big one.
Now I use npm i --save which gets versions so.. it really is not a pain to have many dependencies with npm.
In Java and many other systems, yes, it is very painful. npm is different.
I've run into it. Dependencies get bugs sometimes. Easy to pin versions with npm's shrinkwrap though.
>The author advocates copy-pasting code rather than including small modules. To me this is very misguided.
Yeah, I'm surprised how often people suggest this is the obvious solution as if it's not without its own problems. One of the things I dread most about working on a new codebase is finding an ancient version of some library code copy-pasted into the codebase with the inevitable unlabeled (and probably not high-quality) customizations made to it. Trying to figure out whether the library's documentation still applies, whether it still passes its original upstream tests with the customizations, or whether the copy can be safely replaced with a newer upstream version is painful.