What are your thoughts on the left-pad npm case?

[simison]

...since you've published quite a bunch of very popular packages.

Background:

• http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
• https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.tpfxnpq1h
• https://news.ycombinator.com/item?id=11340510

Would you do the same?

[jtheoof]

Perhaps a useful read? #10 (comment)

[Richard-W]

I fundamentally disagree with that comment.

Containing complexity is not about putting everything in one-line functions/modules. It is about abstracting complicated logic. Quicksort is a good example. You wouldn't want to rewrite the algorithm every time you needed it. negative-zero is not, because you rarely need it and it is perfectly obvious when you know the specs. Managing a module for that actually makes it more complex because adding and maintaining modules has a slight complexity overhead. After all I expect programmers to be familiar with the specs of the languages they're using.

[sindresorhus]

Containing complexity is not about putting everything in one-line functions/modules.

Nobody said it had to be one-line functions. I actually argue the opposite. Lines of code are irrelevant. Containing complexity is about taking something that is hard or error-prone and make it robust and easy to use & reuse. It being one line or hundreds.

It's easy to pick on the smallest module you can find to further your argument, but keep in mind that most of the small modules I make and use are not that small. This is closer to the average size. The project I spend the most time on these days have thousands of lines of code, because it wouldn't make sense on it's own.

negative-zero is not, because you rarely need it

That's exactly why it should be a module. It's very hard to recall knowledge you rarely use.

it is perfectly obvious when you know the specs

Very few JavaScript developers have actually read the specification. Even less remembers the exact definition of a negative zero and even less how to actually figure out how to detect it based on that information.

Don't believe me? Let's hear from devs: https://twitter.com/sindresorhus/status/715858614670327808

After all I expect programmers to be familiar with the specs of the languages they're using.

That's like expecting all humans to be honest and peaceful. While it sounds wonderful, that reality doesn't exist.

I would also recommend reading: In Defense of Hyper Modular JavaScript

[sindresorhus]

Would you do the same?

Would I have unpublished all my modules? Never. While I disagree with the decision npm made, I think what Azer did, even though it was his right, was highly unprofessional and childish. Some part of me is glad it happened. It forced npm's hand towards better safety and immutability, which we have been begging for for years.

I also fail to see how small focused modules have anything to do with the unpublishing of left-pad. It would have been just as bad if lodash were unpublished (Actually worse as lodash has 10x the downloads). Let's not abandon good practices just because of one dumb crisis. It's fine that not everyone believes in small focused modules. Diversity is good. And it probably wouldn't work in many other ecosystems, like Python and Go, where dependencies are more painful.

It's sad how aggressive people get just because we're not doing things their way. We can do better.

[petkaantonov]

Lodash probably covers tens of thousands of micro modules, depending on how ridiculously you want to define "one thing". If you use lodash, you only have to trust jdalton but if you use tens thousands of micro modules you are trusting thousands of random authors on modules that didn't take any commitment from their authors. Even if the risk is the same on these 30 second modules as it is with a well established project, it's still multiplied by the amount of different authors and that's not even considering that one author could just transfer ownership of micro module to another.

[sindresorhus]

@petkaantonov Yet, most include lodash for a just couple of methods. Just use micro-modules from authors you trust then. I've depended on thousands and thousands of modules through the years, and I can count on one hand how many times I've encountered breakage because of some module, and it was quickly fixed each time. I'd rather trust people. And for production, I always shrinkwrap anyways.

[petkaantonov]

Not utilizing the entire thing only matters for browsers and even then it has a technological solution (make them individually requireable or use es6 imports with tree shaking or closure compiler). In many node.js scenarios it just doesn't make any difference how many methods you use of something, it's like optimizing code by removing semicolons.

Just because a risk hasn't materialized for you doesn't mean it didn't exist. The person with longest lifespan smoked 90 years. You might rather trust people but do the people you work with and for feel the same way? Do you even tell people that you are actually massively multiplying risks rather than just mentioning the upsides?

[YurySolovyov]

@petkaantonov where would you draw the line between trusting people and implementing everything yourself?

[sotojuan]

To be fair you can treat lodash as a collection of micromodules—each function can be installed and required by itself. I think that's a goof argument for both sides. A large, trusted project made of small, focused modules.

[nickpetrus]

@petkaantonov please take your time and compile all existing smaller modules into larger trusted one, that would be a perfect solution and contribution to the community.

I speculate that at the end very few people would switch and that would be a user vote towards OKing having array of small modules. Basically it's a waste time project that could be spend building few more new small useful modules and really contributing to community.

Remember, nobody reports good news!

[jamestalmage]

While I disagree with the decision npm made...

Which decision? Transfering the kik name, or un-unpublishing the module?

I certainly don't disagree with the un-unpublishing decision (I applaud it even). This is the beauty of open source. I have full control over the vast majority of my development stack. Not even the authors / maintainers of the code can strip me of my right to reuse (and in most cases redistribute) their work.

Transferring the name is a bit more troubling to me. I certainly wouldn't want the name of any module I developed taken away. That said, I think kik had about as strong a case as you can get: Hundreds of millions of users, a registered trademark for the exact module name, and they actually intend to ship code using that module name. Azer's response to kik was pretty horrible, and I'm sure that didn't do him any favors.

Sorry - I know this is hijacking the thread a bit here. Just interested to hear your take.

I wonder how many more man hours have been spent discussing the left-pad issue than it took to fix the original problem. (like in orders of magnitude)

[csicky]

OK, KIK is trademark, that is one thing.

However… NPM to UN-UN-publish something “for the good of community” is just plain wrong! If I have the button to UN-publish something it means I am the owner/admin of that thing. Nobody in the world should UN-UN-publish what the admin UN-published. If there are other admins to that thing, they can re publish, OK. But it’s not NPM’s call.

This breaks TRUST!!! People will think twice before publishing again anything.

If that package is missing, somebody else should publish it again under its name and that’s it, eventually giving credits to original author, after all it is open source.

[jamestalmage]

If that package is missing, somebody else should publish it again under its name

That's exactly what happened. The only thing special about this case was npm allowing the new owner to republish with the same semver version. All this is moot though - the new rules for unpublishing prevent this from happening.

Anyways, we should get back to discussing small modules.

[csicky]

There is more to this discussion than only small modules or collections under one name. What about the platform? Right now there are many... NPM, bower, NuGet, whatever. All serve their purpose and have their strengths. For example I use Visual Studio and from there NuGet is more comfortable to use, but sadly many packages available in NPM are not in NuGet. I have to use NPM. But there is something I need in NuGet too. Now I have to use both. And on top of that bower too. Bower and NPM work from cmd.exe but NuGet has its own command line in VS. Writing all this is extremely long already, imagine working this way is not a good experience.
Not to mention NPM and too long file name problem in Windows.
After spending a day trying to make it all work somehow I often realize it would have been easier to just write or copy paste it somewhere locally.

What if Microsoft decides tomorrow there are not enough people using NuGet and just stops the service? Or if any other platform owner decides this?

[jamestalmage]

Not to mention NPM and too long file name problem in Windows.

For this and many other reasons, use npm@3

[csicky]

For this and many other reasons, use npm@3

Thank you, I will look into it.

[dthree]

What if Microsoft decides tomorrow there are not enough people using NuGet and just stops the service? Or if any other platform owner decides this?

Such is life. There is also a small chance of a piano falling on my head, but I get on with it anyway.

---

NPM is fortunately the largest package manager on the planet, so it's a good pick for stability. There's a lot right about it, and a lot of people actively trying to fix some of the things wrong with it.

IMHO NPM will be around for a very long time, unless it is intentionally destroyed by a large effort to discredit it.

[stevemao]

I'll make sure left-pad will never disappear again 😄 Thanks guys.

[mk-pmb]

I totally agree with @sindresorhus's arguments in the original AMA thread, tiny modules are fine. Since it's locked, I'll debunk the argument about remembering module names here:

@MaxArt2501 wrote:

I disagree on this. The problem is that you might remember "negative-zero", but it was actually "is-negative-zero", or "negative_zero". Oh, look, there are both "negative-zero" and "negative_zero": which is the one I'm looking for? And what about this "negzero"?

That confusion can easily be solved by cordiality. Just star the packages that you like, and use a search tool that can use your stars for ranking.

As for the general issue: An important module disappearing on NPM is just a sub-issue of NPM disappearing from your reachable subset of the internet. There's a well-tested technology to solve this class of issues: caching mirror servers. Any large business that failed to set up their caching mirror servers, should re-think the targets of their blame.

__
Update: Feature creep for module search may include:

• Stars of people you trust
• Rank weighed by who starred it and when
• Stars, likes etc. from other platforms (NPM stars, github stars, usage in your own past modules, …)
• Keeping a cached local mirror of your stars list

Also I think left-pad is a very nice example of a task that young code ninjas consider so easy no-one should ever think deeply about it. They'll regret it when they start using neat smileys from the high unicode ranges and suddenly learn about surrogate pairs. (btw if someone is into Firefox addon development, I know some addons where the JS portion of fixing them is low-hanging fruit.) Also ANSI color codes, soft hyphens, text direction markers like right-to-left, … it's never a good idea to lock yourself to some past level of knowledge.

Then again, in cases where I expect the input to be some very precise, white-list limited range like a decimal integer with 1 to 14 digits, I often do write my own mini function rather than importing a module.

[MaxArt2501]

@mk-pmb

That confusion can easily be solved by cordiality. Just star the packages that you like, and use a search tool that can use your stars for ranking.

"Just"...

"Easily" is a very subjective word. Out of the box, you don't have such tools: you actually have to look for them, try them out, getting used to them and so on. npm just gives you stars, and it just outputs a dull array of package names. No descriptions, no tags, no last versions, no last updates, no authors, nothing.

And when you you've built your curated collection of packages, it may happen that you can't use it. Because you're not in your environment or whatever. Maybe you're forced to use something else. Maybe even nothing.

What I also said earlier in that same thread is:

Probably what we really need is new tools to handle our modules. Quality control tools, above all.

Discoverability on npm is a problem and it's not getting better, while npm is growing at a staggering pace.