Hacker News new | ask | show | jobs
How one developer just broke Node, Babel and thousands of projects (theregister.co.uk)
44 points by traxmaxx 3747 days ago
6 comments

I completely agree with the developer here, I also think npm crossed the line by republishing the module.
Yeah, though I'm curious what the proper solution would have been.

It seems to me that once published to NPM there should be some process for deprecating a module that is then "unpublished"... rather than just breaking every module that uses it as a dependency instantly.

They could spawn automatic emails to all dependent module owners about the hard deprecation and give them 7-30 days to replace the module before it's removed from the package ecosystem.

I think it is also a reflection on the state of the node ecosystem, including an external dependency for a few lines of simple code. Note this isn't only nodes issue, ruby has a similar issue with gems.
This is gold...

A module for padding the left of a string?!

Used by big projects like Babel?!

NPM takes down a modules without asking the dev

NPM republishes another module without asking the dev.

Then the whole NPM3 mess (unrelated to this article)

If have the feeling those people there have no clue whats on.

it's not one module at question here. it's 250 modules with thousands of installs.
It seems like it was less the developer than the package system.
"When NPM took Kik away from the developer, he [...] unpublished all of his NPM-managed modules"
Which was his right as the publisher of the modules. Open Source < > Public Domain.
Which should make anybody depending on such "publishers" think carefully about the effects of such dependencies.
I've had problems with NPM where a deep dependency was wrong for my system, and was tempted to solve it in the following way: fix the deep dependency in a cloned-project, and create github clones of every dependency in the chain that refers to it using the new package address in their package.json. That sounded wrong so I didn't do it.

One mechanism that could fix that problem, and the left-pad problem is to allow defining a package substitute in your root package.json file. Then you could swap out the dependencies of your dependencies.

packageReplace : [{source_name: 'left-pad', source_version: '1.0.1', target: 'https://github.com/foo/bar' }]

...something like that

If the old left-pad is open-source, is it perfectly valid for an arbitrary entity to continue publishing left-pad from an abandoned URL?
There was a heated debate last week when someone choose to distribute a 100 lines css framework via npm... I've chosen my side.