npm Blog

Yes I think you are right when NPM first introduced it, which was in NPM 5 [1]. At that time package locks were new.

Node 16 shipped with NPM 8, and by then this was not the behavior any more. I don't remember exactly when, but I believe it might've been in NPM 7 when this changed. Node 15 would have been the first release to ship with at least NPM 7 [2]

EDIT: Node 16.0.0 shipped with NPM 7.8.0

https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.0.0

EDIT 2: A StackOverflow confirming NPM 5 behaved the way you remember: https://stackoverflow.com/questions/45022048/why-does-npm-install-rewrite-package-lock-json

EDIT 3: And, as that SO documents, 5.4.2 changed the behavior to prevent this, here's the GitHub issue: https://github.com/npm/npm/issues/17979#issuecomment-332701215

Honestly no guarantees it worked as intended right at that release, but the intention is clear.

EDIT 4: I realize that the following may present retort but it matches my mental model perfectly:

> If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.

This is what I've mentioned elsewhere: You should not update package.json's versions and deploy it and expect that versions won't change when NPM install runs. In fact, npm ci will just fail in this situation,…

I did a quick browse through the threads in question and suggest others do the same. Yes, there is negativity, but the actual debate is more complex than simply one grumpy side slamming a poor developer.

The most relevant comment I found was by /u/bixmix:

> It's getting much worse - not better. The internal churn within pip also is not community driven as much as it is developer driven. It's like we didn't learn from the debacle of python3 vs 2.

I'm not a Pythonist so I had no idea there was such a huge debate over how to manage deps. At various points the past few years I've googled "bundler for python" and come up with different projects. I remember trying pipenv early on (didn't work with conda Python install). Then I revisited it months later--the project was much more developed--and it worked great. FWIW I like pipenv, it solves my largest gripe with Python development.

If you have as part of your community philosophy "there should be one—and preferably only one—obvious way to do it," it seems like you're going get a lot of stubborn tug-of-war situations (see 2 vs 3) where each side thinks their way is the superior way and there is less room to compromise for the sake of keeping the community together. That said, this pattern of debate is pretty universal across communities.

Ruby--even with it's MINASWAN motto--had it's own RVM vs rebenv drama back in 2011. Same sort of developer/community vs developer/community drama. Nowadays I think rbenv has a larger…

There's two distinct problems I see here, which probably plague most package managers:

1. Package naming: All the good names will be gone soon, which'll probably lead to big players trying to get package names of little players. Which will then result in broken dependencies a la left-pad. Afaik the latter has been solved in NPM [1]. The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.

2. The power of deps and our reliance on good will: When installing dependencies, we basically grant them the power to wreak any kind of havoc they want. The ways we mitigate the worst: Belief in the magical power of open source, mostly using libs that are popular (hence might've gotten a good read by an IT-sec person) and at enterprise scale some static analysis tools to get an idea of how it interacts with your system. I think we're in need of a technical solution at the package manager level, where a dependency has to explicitly ask for certain capabilities (similar to how Android apps work).

[1] http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

NPM added namespaces in version 2, which was released in Sep 2014, just 2 months before cargo was announced. I don't remember anyone making a big deal about using scopes in NPM for several years after that, it was just there as an option. The announcement blog post of v2 only gives two paragraphs to scoped packages and explicitly frames the feature as being for enterprises and private modules [0]:

> The most prominent feature driving the release of npm 2 didn’t actually need to be in a new major version at all: scoped packages. npm Enterprise is built around them, and they’ll also play a major role when private modules come to the public npm registry.

My memory is that the industry as a whole didn't really start paying attention to the risks posed by dependencies in package managers until the left pad incident.

To be clear, I'm not saying that it was a good idea to not have a better namespace system or that they were completely ignorant of better options, just that they were very much following the norms at the time.

[0] https://blog.npmjs.org/post/98131109725/npm-2-0-0.html

Here's what isaacs writes in the NPM blog post (https://blog.npmjs.org/post/612764866888007680/next-phase-montage). It doesn't seem like anyone on the NPM team did great financially from this:

"I have a set of goals that I wrote down back then, and have shared openly with the team.

...

3. Get a big enough exit that I can quit my job and see what comes out of me a second time.
4. Share the rewards equitably with the people who got npm to where it is.

...

On (3), well, I’m still working a jobby job, but I always knew that was a long shot, and “make npm a better package manager” is a job I enjoy. And as for (4), I’m proud of the deals that we’ve been able to negotiate for the team.

It’s not a kajillion billion dollar 10x startup cinderella story, and we’ve taken our hits, but in the end we’ve done right by our community, team, and careers, and I’m extremely proud of what we’ve achieved."

> NPM wants to have its cake and eat it too, which is the problem here. The solution is just to say that if you publish a package to NPM you give it the perpetual right to distribute it as-is, and then remove the ability for users to delete their packages at-will.

Yes, exactly!

Kind of unrelated, but I think it is important to remember that the left-pad was also ENTIRELY npm team's fault. You can't just take away a namespace from someone just because some startup like kik comes knocking.

Toyota does not have a right to my domain dot tld slash toyota The correct answer would have been npm to tell kik to pound sand.

npm has never fixed this grave error.

https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

> We stand by our package name dispute resolution policy, and the decision to which it led us.

npm deserves to die.