Sounds to me like the list has one item: “the npm registry once allowed users to delete packages”. [2] and [3] have nothing to do with immutability. None of them have to do with reinventing the wheel, either, unless you wanted Node to use Maven for package management?

They don't mean immutable as in language form, but immutable packaging system is the general form where you can add but not remove packages to it so as to not break things, which is the common form among most maven/cargo/hunter/etc.../etc... dependency packaging systems. It's generally considered that npm supporting deleting packages was a major mis-design, which became very public when a popular tiny package got deleted, which then broke so many things, so they learned that the hard way instead of learning from the systems that came before (obviously not cargo, but you get the drift ^.^).

> They don't mean immutable as in language form, but immutable packaging system

I know. [2] and [3] have nothing to do with a package repository you can’t delete things from.

Anyone who's acting like this wouldn't happen in Maven is lying. Just look at what happened when CodeHaus went out of business.

This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug, not a design issue - no package management system is immune to bugs.

The one thing Java has is that it uses namespaces, which may help with [2] (but barely). [2] certainly has been a problem in PyPI.

Certainly all of this could happen to PyPI. We see it happen with js more, I think, because js happens to be extremely popular so there's a ton of packages for it and it's also much younger (especially node) than others.

> This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

He does have it in his slides.

Slide titled: "Regret: package.json", last 2 points:

> Ultimately I included NPM in the Node distribution, which much made it the defacto standard.

> It's unfortunate that there is a centralized (privately controlled even) repository for modules.

Yeah, I remembered the package.json bit, but that part still had nothing related to the issues/ mistakes mentioned.

Understood, sorry I wasn't trying to dispute any of your points about said issues/mistakes.

Just trying to clarify that he does actually talk about NPM and his regret about it.

Yeah, I actually only remembered the bit about 'package.json' and not the other quotes as well lol

"The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again." - R.Jordan

I'm afraid the current frantic pace of reinvention in JS/web might cause the Breaking of the World and throw us into a Third Age where no one quite remembers the true lessons of the Ages before.

More frustratingly, at least for me, is that some of us have been warning about these things for absolutely years without many paying any mind, only for them to keep in happening again. Eg. https://news.ycombinator.com/item?id=16090120

I've found that some people tend to take a ton of pride in the assumption that they have to make mistakes to learn from them, but you almost always want to learn from other peoples' mistakes first. Probably overlaps quite heavily with those people who desperately want to tread on new paths.

The problem is, how do we know that those shouting warnings are not false prophets?

Presumably by reading and understanding their arguments.

But, how do we know which ones we should be reading and understanding their arguments?