Hacker News Reader

Comment by andy_ppp | Hacker News Reader

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting.

How stupid of people to reuse small often used functions that only do one thing well.

How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?

It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. I can also use npm to share these snippets between the many projects I'm building.

* No I wasn't affected by this because I review the packages that I want to include, however the level of smugness here is absolutely ridiculous.

View on HN

> How stupid of people to reuse small often used functions that only do one thing well.

This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.

> trust their package manager

That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen.

The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library.

> It's not javascript devs fault that the standard library is so piss poor

Nobody is claiming it was. However, Javascript devs are responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a very good reason.

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.

The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

no this is the fundamental engineering issue... there is no magically mythical perfect package manager, and even if one exists there is a real intrinsic cost to adding a dependency. It is not a huge cost... it is minor... but the benefit of using a one line package is also minor... so when you are making a minor trade off over and over again as with npm where its not unsually to end up depending on 1000s of packages... then this is not a trade off that should be made without thinking...

just saying be an engineer. weigh the costs

I never said perfect, I said good. Some basic properties are that upstream changes don't break downstream dependents if you've protected against automatic version updates.

And yet, automatic version updates seem to be the first thing people bring up in defense of package managers when I mention that I generally think they're a poor strategy.

It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.

> The cost of a dependency for a good package manager is zero

The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.

I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.

That still isn't enough to refute "The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.". Sure, npm may be a bad package manager. If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. Most other ecosystems, with good or bad package managers, do not have tiny one-function packages -- it's possible to have an ecosystem not depending on it. If npm isn't good enough to have zero-cost dependencies, then your ecosystem should definitely not depend on tiny packages. This may be NPM's fault, but it's the fault of the ecosystem too.

For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.

> If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was.

That's great, and my point was that with a good package manager, that cost is effectively zero.

> And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken.

Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory.

Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.

> my point was that with a good package manager, that cost is effectively zero.

yes, which doesn't refute pdkl95's point. If you're not in the world with a good package manager, you should consider the cost of the dependency. The Node ecosystem seems to not have done that. That's the bottom line here, if there is a cost to dependencies (which you don't seem to disagree with, at least wrt NPM), then you shouldn't have dependencies for 11-line functions. Everything else is orthogonal.

It's not fully mutable. You can't change the code of a particular version, for example. The particular problem with left-pad was that npm is mutable in one way: deleting packages.

"Zero" isn't a cost of anything -- there's no free lunch.

NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to

    function whatever() {
        return "WHHEEEEEEE!!!";
    }

and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously curated package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.

Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates.

Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.

That's just a no-true-scotsman fallacy.

And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.

No, it's not an NTS fallacy. And the package manager is mostly useful for tracking updates and simplify the process; having it automatically update is completely optional, and personally, I never do.

Exactly. A notification that new updates are available would be nice, but I don't think automatic updates should be the default, even if "semantic versioning" says the update should be backwards compatible.

No, it's not an NTS fallacy.

No True Scotsman is so often mis-attributed, that the mis-attribution needs to be its own fallacy.

Exactly. That's the No True No True Scotsman Fallacy Fallacy.

Compare also with Fallacy Fallacy - just because the argument is fallacious, doesn't mean the overall point is wrong.

There's this "Tone Argument" Fallacy Fallacy. You can't win an argument by complaining that the other's tone is unpleasant. So that's a valid fallacy, but it only applies to a particular argument in a particular circumstance. Certain people on the Internet then make the illogical jump to the conclusion that they are therefore justified to use whatever tone they care to in any argument. (And lo and behold, they always "win" arguments.)

And wait till you hear what a sufficiently smart compiler can do!

http://c2.com/cgi/wiki?SufficientlySmartCompiler

But there already exist package managers that let you pin to a specific version like he's saying they should e.g. Maven, so I don't think your link quite applies here.

Npm allows that too -- you just specify an explicit version number, e.g. "1.5.3" instead of "*" or "^1.5.3" etc.

My comment was against this belief that "smarter" tools in general are some sort of panacea.

For example pining to a specific version won't help you match if the package is removed altogether (as in this case), and ever worse if it's replaced afterwards by another (newly registered) with an incompatible same version out. It won't try to overwrite your specific install of course (since the version already matches what you have), but you'll feel the pain when you try to duplicate/deploy etc a new install with the same package listing -- suddenly the package either won't be there (or will be modified in the worst case scenario).

So, then we opt for ever more features of a "sufficiently smart package manager", e.g. signatures, permanence of anything published etc...

Without knowing much of how npm works, I'm going to assume you have ways of protecting yourself there too. If nothing else, good old "cp -r" can effectively let you pin to a version.

The point is that people use package managers and third party modules installed from them to automate tedious work, and anything automated will have the potential to do something other than what you want. Is that risk high? Not really, but it's not zero either.

Yes, but a sanely designed package manager will at least require that to be a new, versioned release. _Already published_ versions of a package should be immutable.

If you do that, won't you have to increment your version number? Because with npm, except for left-pad due to oddities of the npm-specific ^ semver operator, you always have to increment your version and you can always pin earlier versions. That said, the ^ sevmer operator would probably upgrade to your sabotaged version if you went from 1.2.3 to 1.2.4, and people would have to figure out what the other operators meant.

As to curated package managers, I'd consider them a great counter-example. Try installing a recent (5.x) version of node and postgres (9.4) on ubuntu. You can go through the rigmarole of adding an entirely new repository for postgres (apt.postgresql.org) since the debian distributed version of postgres is rather old (and ubuntu-version specific). You can also do the same thing with nodesource for nodejs, but if you install node on ubuntu, you'll get a packet radio service instead.

Curated package managers are very conservative and move very slowly. Javascript is a relatively fast-moving, pretty anarchic environment.

The lesson of left-pad is probably: vendor your node deps and check them in. And also: npm probably needs to be replaced with a write-once store with cryptographic signing of packages. You still have to trust the author, but that's the point of open source. We're built on trust.

Node has a history of kicking out a new release virtually every week, often with crazy breaking changes. Quite sensibly the Debian packagers decided not to try to keep up with that game. There is an easy-to-add on repo if you really want it, although Typescript works just fine in the packaged version so I haven't.

Not sure what your point is on postgres, since 9.4 is right there in the repo.

postgres-9.4 is available in ubuntu 14.10 and later. If you're in 14.04 or 12.04 (current LTS versions), you have to use the postgres-maintained source. The process isn't super-simple.

Node moves fast, sure. I'm not sure I agree with your "crazy breaking" modifier there: I regularly do dev work against the latest 5.x branch of node, and rarely if ever have to worry about breaking changes. Then again, I'm just doing plain old restful api and business logic stuff, so maybe if you're dealing with the c++ interface it's a different environment.

Even still, I think it's easy enough to see from our disagreement over "too fast" and "quite sensibly" that there's plenty of ways to be a programmer. Rapid improvement can be kind of exhausting (especially if you get behind) but it's also a great way to see new ideas emerging. One of the things I actually love about the javascript world is how quickly things move. Things evolve very quickly because there's so much churn, speedy releases, pressure for mindshare, and so on. It's fascinating, both technologically and sociologically.

It ought to be pretty straightforward to say "apt-get install nodejs-5.3" and have that Just Work, but by the time the curators get around to updating their packages, you may well be a month or three behind. (again, unless you've updated your sources.list.d to include the nodesource repo).

So yeah: curated package managers have a place in the world for sure. But the trade-off here is that you're not getting the Latest and Greatest. Joyent tried to Slow Things Down with the 0.10 branch of node, and you see where that got them.

You could, and that's why it's trivial package manager hygiene to pin versions and always test before upgrading versions.

Yeah, except nobody does it. It's really the case where stupid ideas should be make harder to implement. Otherwise you get the present web, where a lot of companies fetch all dependencies from GitHub every time their CI server wants to run a build.

About the only good thing that comes from this is that we get to laugh out loud every half a year when there's a random GitHub outage and those companies all scream bloody murder.

> The cost of a dependency for a good package manager is zero

I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell

That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.

>The cost of a dependency for a good package manager is zero

Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...

>The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen.

Exactly. I'd like to know if andy_ppp reviews every update to packages that andy_ppp wants to include too.

Yes, I agree with you - there will always be some level of trust involved in your package manager. I think having a better standard library is probably the first desired solution, followed by npm keeping all old versions of a module around even after unpublishing and also some kind of review process build management system magic as part of your code review process.

It's all very easy to say of course and loads of people having been saying including small piece of code from your package manager is wrong. I'm saying it's not and giving reasons why. Trust your package manager or help make it trust worthy I guess.

Not to mention, their package manager is governed by a single for-profit company, that could disappear at any time, taking the entire infrastructure with it (breaking everything...)

There's a lot of talk of decentralizing npm - but come on folks, what motivation would npm the company have to do that? It's the same issue as with GitHub (only that, with GitHub at least, if you're using git properly, GitHub disappearing tomorrow should have little impact).

What motivation does Sonatype have for sponsoring Maven? What motivation do dozens of web hosters have with providing a free mirror for Debian or Ubuntu packages? As far as I know, NPM is not a profitable endeavour, so making it distributed would decrease costs, and the company behind it can focus on consultancy or whatever it is they do.

Sounds like there's a market opportunity here for a company that does dependency verification. Send them a copy of your npm-shrinkwrap.json file and they ensure every dependency + sub dependency change is legitimate and has no obvious security holes.

There are probably enterprises that would pay good money for this, especially 5+ years from now when these apps are much larger and harder to maintain.

The laughter is mostly the same as in the crowd points out the "new clothes" actually aren't any clothes at all. The modern, funky, hip, js "devs" told us we didn't "understand" they are doing modularity, code reuse, all those good things. Then the larger crowd realised they are publishing gazillions "modules" each of which is barely a function, some of which have horrendous runtime performance despite their wide inclusion by the crack a-team of js "devs".

I don't know why this got downvoted. This is exactly spot on.

I think it's less smugness (there certainly is some) and more disbelief / unfamiliarity.

JS isn't the first language without great libraries (C's stdlib, `math.h`, `string.h` are good but don't have string padding functions, for example) so there's precedence going back a very long way. Most solutions involve coming up with a utilities library that contains the basic things (like a math library, or a strings library).

There's nothing wrong with creating utility libraries for JS. I think people are surprised because the approach taken - that they are composable down to the function - is so radically different from the industry standard. Coupled with a package manager that requires fetching so many deps for such trivial functionality.

People do tend to form isolated communities around languages (look at the language for basic data structures between PHP, Ruby and Python) and this kind of thing probably helps shake up that isolation which is probably good for both sides.

(I could be wrong it could just be sneering)

sprintf and friends will pad strings for you, no?

printf("%20s\n", "Hello");

Even the Java ecosystem managed to get their crap together and make the excellent Apache Commons library collection to deal with a similar situation (anaemic to useless standard library). C++ has STL and Boost.

Only the PHP and JS communities seem to think that not having a solidly designed "base" library is fine (and even PHP seems to be getting better at it with 7).

The Java standard library is anemic? As in Java SE? That's rich. Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on.

There is no language with a less anemic standard library, and Java SE is often criticized for being too large.

This is true. One wonders if OP has actually seen the vastness of Java SE or is just "hating" to "hate".

I've seen it, and more often than not frustratedly turned to Apache Commons because the Java standard library is as vast as it is useless.

The JRE lib seems to be a compromise between "common types for everybody, but leave the convenience to external libraries" and "batteries included". This leaves both camps deeply dissatisfied, but allows for a great deal of integration between libraries. Maybe I have looked at Microsoft flavored C++ one time too often, but the fact that a single string type could reign unchallenged for twenty years makes it easy for me to accept that I need to use weird imports to tackle exotic convenience desires via statics (that, and the sad underutilization of CharSequence).

Java SE includes a lot, but it does emphatically not include a reasonable amount of useful string methods. These are the javadocs for string: https://docs.oracle.com/javase/7/docs/api/java/lang/String.h... and these are the rubydocs: http://ruby-doc.org/core-2.3.0/String.html

The difference is absolutely massive. When working on Java projects, I've always included commons/StringUtils reflexively, and even then Ruby is quite a bit ahead.

The same applies to collections / enumerables. There's a lot in Ruby that I don't like, but powerful "batteries included" standard libraries for the basics like strings and collections are the bedrock of any programming language. It only takes hard work to write them and test them, not any specific skill, so there is no excuse for all the language out there that are skill lacking, in 2016, a sensible collection of utility methods.

Much of that functionality is in other Java SE standard library classes. You can do left padding with Formatter.

http://docs.oracle.com/javase/8/docs/api/java/util/Formatter...

>There is no language with a less anemic standard library

PHP would like to see you out back in the alleyway, as some other posters in this thread have pointed out.

> Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on.

Yes. However, there are a lot of design decisions held onto because of backwards compatibility that continue to cause massive pain points. Object.toString() comes to mind. The fact that String.format() has to be either statically imported or typed out every time. I'm so sick of lengthy string concatenation in Java.

"When I use format " + createSentenceStringFromList(work.getCoworkers(), "and") + " act like I've committed " + A_HORRENDOUS + " crime."

PHP is absolutely the last language I thought anyone would accuse of missing standard features. PHP is massive and includes absolutely insane numbers of functions to do everything. If you can think of 3 basic, universal functions that PHP doesn't include, I'd be shocked.

Also, PHP 7 has absolutely nothing to do with standard libraries, as it doesn't really add anything in that regard.

the cool kids make fun of PHP.

You must not be a cool kid.

Everybody makes fun of PHP.

Except people busy running businesses and creating with it.

We run almost everything on Wordpress and still make fun of PHP. And JS. And Java. And ObjC. And Ruby. And Python. Every language has its share of problems and sometimes you just have to vent.

Sure, but: "we make fun of every language/every language has its share of problems, etc." is a completely different statement/message than "everybody makes fun of PHP" -- which singles it out as some huge abnormality...

apparently the humor of the post was lost on a few people...

I never said I like PHP. I use it daily for work and hate it. I was just refuting something on a factual basis -- PHP's "standard library" is absolutely enormous.

I don't consider C++'s Boost something to be proud about. Last time I've checked, Google forbade a significant part of it to their developers, and in my opinion rightly so. But who likes everything there should just as well understand this Node affair.

Boost has been incredibly successful as a breeding ground for new C++ libraries. Much of the functionality that was added to the standard library in C++11 came from Boost. This continues to this day.

It's a collection of libraries, no one is using all of it.

Google's c++ guidelines are idiosyncratic at best.

Google makes a lot of controversial decisions from engineering standpoint, not least of which is doing half of their stuff in Java.

(It always bewildered me - why hire the best of the best, and then make them work with lowest-common-denominator tools?)

From my point of view, if we remain by why not allowing everything Boost, it isn't controversial at all, for the same reason that Linus (an I too) believe that it is a good that Linux kernel is pure C and not C++.

And the same reason why some people now see that the presented Node popular practices aren't something that the battle-tested players consider reasonable to do.

> C's stdlib, `math.h`, `string.h` are good but don't have string padding functions

Of course they do; how would you align printouts otherwise?

    $ cat main.c
    #include <stdio.h>
    
    int main()
    {
      (void) printf ("%42s\n", "hello");  // right-align, 42 chars
      (void) printf ("%-42s\n", "hello"); // left-align
    }
    $ gcc main.c
    $ ./a.out | cat -A                                                                                                                                                 
                                        hello$
    hello                                    $
    $ ./a.out | wc -L
    42

Of course you can use `asprintf` to pad a string like you can use a for loop to pad a string in JS. But it's not a dedicated named function to pad strings like the `leftpad` we're discussing. Kind of missing the point of the argument.

Given how simple and popular `left-pad` module is (indicating the principle the community uses to determine granularity), I'd guess that if `String.format` was available in JavaScript there would still be a library to provide `leftpad`.

It's a memset followed by a strncpy, hardly worth linking to a library for. You'd be done writing the function before you finish googling for an existing one.

That's the whole point of the discussion.

I think the difference is that when a C programmer hits an undefined behaviour, they either blames the spec, the compiler, or themselves. A JavaScript programmer doesn't need a prompt to blame the spec proliferation and dilution, the necessity to write cross-platform by default, and their lack of foresight in not including a 3rd-party library that would have provided some vestiges of a targetable platform. The C code that started as a nice asprintf(3) for GNU/Linux will sprout a few if-defs once it has to run on some embedded PoS without a sane malloc().

A function is dedicated if it is well-suited for a use case. It does not require it to be ill-suited for other use cases.

Either you arguing that `left-pad` is not a "dedicated" function for padding by 42 characters, because it can also pad for 43 or 41, or I don't understand you at all?

The point is that it's easy to pad a string in C and easy to pad a string in JS but there's no specific function called 'padstring' in either.

The examples were really secondary to the point of my argument, which was about packaging functions into modules, not about the C language.

Javascript has an excellent standard library - lodash. Here is its string padding: https://lodash.com/docs#pad.

Lodash also ships hundreds of independent npm modules for those who don't need the entire package. Here is pad as an independent package: https://www.npmjs.com/package/lodash.pad.

Lodash is here today, it works, it is reliable, and it doesn't pull the rug from under you.

Lodash only got padLeft in version 3.0.0 (released last January), and then that method was renamed to padStart in 4.0.0 this January, so it's not exactly the paragon of reliability (although I understand your sentiment)

dalton likes to name methods as ecmascript itself, what I very much appreciate. padStart() was proposed as standard after lodash 3.0.0 was released. So he changed it on the next major release:

https://github.com/tc39/proposal-string-pad-start-end

Naw, I changed it on a major bump which requires opt-in and didn't pull the rug out from underneath people.

As @sod pointed out the change is based on the newish ES7 proposal.

That's not a standard library.

Sure, but one reasonably cohesive library is better than a whole mess of tiny ones.

That's exactly what is up for discussion here. One library with 1000 methods, where you only use 2, is probably not better then a library doing what you need.

I'm with Knuth here, a lot of the arguments for discrete function units sound like premature optimization. In the end, you won't get the equivalent of the MODULA-3 standard library or something equally well-defined, but PHP4's mudball of functions.

All this because a few bytes of functions would ruin your experience and/or dead code eliminiation isn't part of your pipeline.

> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting.

Obviously people shouldn't have trusted npm - that's the reason things broke in the first place!

> How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?

The usual method is to bundle dependencies rather than pull them down from the web at deploy-time. That or use a package manager with rather stronger guarantees on availability of packages.

> It's not javascript devs fault that the standard library is so piss poor you need these short code snippets

This is very true.

> the level of smugness here is absolutely ridiculous.

Also true, but funny nonetheless.

Wouldn't it be a lot easier and more secure if you simply looked up the code in these packages you're using, reviewed the code to make sure it's legitimate, then copied it to say, your own utils.js package? I'm not even talking about the left-pad package, which shouldn't even be part of the discussion... If you're worried about including 2-4 lines of code on your own then you shouldn't be making an application other people will use in the first place.

Apparently it's not obvious that having a ton of dependencies on 3rd party packages, of which can change at any time on the whim of the owner, is pretty insane in terms of security and minimizing complexity of your application.

You do realize that even though you reviewed the 20 different packages you use at one time, they can change at any time?

I would love to hear what a senior dev at any reputable, long established technology company thinks about including tens, if not hundreds (and some apps, thousands?) of 3rd party packages from strangers on the internet with no validity checks in place. Sign me up!

I use a lot of micro modules. And I think micro modules are a good idea.

But this whole thing is freaking funny. You gotta acknowledge that.

I dunno; I think it's a balancing act between dependencies and code reuse. I think npm needs to not let people unpublish stuff without thought - that is where the problem is and I'm sure they are thinking about a solution to this.

I think a lot of this is implying "don't use micro packages on your package manager, copy and paste code in helpers.js FTW". I've seen people advocating this as if it's a better solution than have npm remain consistent even after people unpublish packages.

Well, I don't think we can trust NPM on being consistent. They gave away this guy's package to a corp, despite his protest just because they felt like it. I'm not arguing if it was the correct decision or not, it's just an arbitrary decision based on isaac's mood that day.

It's best to treat NPM as mutable and don't depend on it. For example, I check in node_modules to git, even though everyone says no, use shrinkwrap! Yeah, that would definately help here.

NPM is to blame here and people are right to make fun of the entire ecosystem around it. Also, It's just easy and funny.

Noone will start copying stuff around just because of this I believe. The micromodule ecosystem emerged because it works for people apparently. Devs will find ways to make it work better.

Not exactly, "just because they felt like it."

But rather because they didn't wish to lawyer up for a trademark dispute that they had no particular reason to want to be involved in. (One where there was a reasonable chance that they would lose.)

You think the only thing about the whole situation that is a problem is that npm let an author unpublish, rather than all the projects came to depend on so many external functions, sorry got to get the npm terminology the right, "modules"?

What's that, you say? I can't "unpublish" my own code? Fine then, here you go.

    $ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js
    $ git commit -a -m "fuck you" && git push

There is (obviously, I would say) no possible solution to the problem of the maintainer of a module you depend on deciding to mess with you. The only serious way to even make a go of it is to move your repository to a curated model where you (in this case, the NPM owners themselves) personally vet all contributions before allowing them in, and even then, I'm confident I can slip something into my own code that will cause problems if I want to -- it's code that I wrote and I've maintained for years and that you've looked at briefly every once in a while.

That wouldn't mess with me. It would just create a new version, while my dependencies tracking file is locked to the previous one. I only fetch new versions to my local development machine, and only update the dependencies file after testing it locally and on the staging server.

How about adding a line that alters the output randomly every 1000th second. Is your UI testing strategy good enough to pick that up? Or do you code review all your dependencies on version changes?

I was bitten by a JS function change in a package that has been named also in this thread. It was an "oh, we moved that functionality to a new function, but reused the old name for a new function that does nothing like the old". And no semantic versioning.

Slipped through UI testing and broke production functionality. I did not like dependencies before, and I like them even less now.

And people keep wondering why everyone's software is so ridiculously bad.

Yes, but you're jumping in the middle of it.

A sane package repository won't disappear overnight, or ever. I can still install packages distributed with Debian Potato, the first ever Linux distro I used, which is now 15 years old. The code that I wrote against the libraries distributed with it will still compile, and had I only burnt stripped binaries to a CD back then, they would still runtime-link and run today on a brand-new install. And because it is all free software, the people and orgs who wrote those libraries, compiler, and standards, had given up their rights to force unpublication.

In a sane package management system, and with version pinning on the consumer's side, your hissy fit would have had exactly zero effect. Assuming your package were free software, people could fork it, and still make improvements.

Thank you. I thought I was the only one who thought the whole thing sounded like a smug "look, there are worse programmers than me out there".

Even more annoying, IMO, is the fact that this was a freaking denial-of-service over thousands of projects which was solved IN HOURS. Instead of celebrating the resilience of the duct-taped Jenga game that is the internet, we're complaining about how other programmers should be more like ourselves? What is this, vi vs emacs? :D

Well, Jane Street found Ocaml's standard library lacking and went on to build a better one. To me it seems much better than build a "standard library" piece-by-piece from one-function packages.

Isn't that kind of what Lodash is?

My understanding is that Lodash started as a replacement for Underscore.js and was originally fairly monolithic. Only in the most recent version do they make it so that each function is separately requirable and published. They have modularized after starting monolithically (without verifying, I also think that Lodash develops in a single repository, but publishes a bunch of modules from that one repo).

It even includes a function for padding strings. I think you would be doing better for yourself using lodash over left-pad, and the cost of including a bigger library on server-side JS is negligible.

>Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well.

I don't get the supposed irony.

Beyond a certain level it is indeed stupid of them.

And the examples we've seen were all below that level.

I think you're taking it too seriously. This criticism is a good think for npm. Too much cheerleading inevitably leads to lower quality in most communities. I assume people are not going to quit using npm anyway (although I don't use it myself).

>It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered.

Correct, it's the fault of the devs who prioritize their ego and feeling trendy over the practicalities of software design. JavaScript is not a good platform for Real Work(TM). The fact that the stdlib is tiny and such basic functions have to be imported from some random guy's library is a testament to this fact.

Personally I can't wait for the JS-everywhere fad to die out.

In most other languages you end up with a poor approximation of npm's micro-libraries via stackoverflow copy-paste.

Actually thinking about it, an ideal solution would be a combination of stackoverflow and npm: all the solutions to a problem grouped together in one place with community votes and comments, and then you can subscribe to an answer from your code.

This is what npm/github is! Rather than having comments in one thread you have them spread in issues and pull request.

> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting.

Well... Maybe a better word is naive? Because every additional package dependency is a risk. It's a risk in a security sense (has anyone ever wondered what is in left-pad in your organization?) and an engineering sense, as demonstrated by the latest JavaScript Bro if the month's industry-crushing personal power fantasy that you all cheerfully turned into reality by letting him control trivial but critical parts of your codebase.

It's true that to an extent, that risk is unavoidable if you want code reuse. Too little code sharing has the exact same problem! But I think that arguing that any programmer in a position to need left-pad should be given edit rights to a non-toy project is what were needling you all about.

The node communtiy has gone too far in one direction and embraced reuse for reuse's sake, not to address any real complexity.

> It's not javascript devs fault that the standard library is so piss poor you need these short code snippet

Well, they could use a better language which compiles to Javascript …

>How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?

By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.

Okay so have you checked all of the apt repos you've added to sources over the years or has one of the ppa's changed to something malicious?

I've added exactly 0 apt sources, precisely because relying on ppas and the like is terribly, terribly insecure. Allow some random person to run code on my machine as root — that's insane.

I use Arch and only official sources, that are checked over and signed by a small well-trusted team[1]. Nothing like npm's model.

[1]: https://www.archlinux.org/master-keys/

Yes, it's a smug joke, but I think it's a funny joke nonetheless (if you got the context). Don't take it too serious.

So many good things happen in the JavaScript ecosystem. Nothing is perfect. This kind of criticism can help. Even if it's a bit much these days/hours ;)

I can't imagine npm and many others won't learn something from this. What more can you ask for?

I think it's more that people writing libraries are depending on left-pad. You can write the function in almost the time it takes to add and install the dependency.

Furthermore, left-pad didn't really do one thing well. It did one specific subcase of one specific problem well. That's like a tenth of a thing, for a definition of well that basically means "written by a monkey taking an npm tutorial".

This also feeds into an extreme example of the continuing discussion around the cost/value/risks of extensive, transitive dependencies with the general consensus being that you would've been better off writing your own left-pad function 1,000 times rather than forcing the risk of this dependency onto your downstream.

This [1], discussed in another thread is an incredible summary of the issues; I hadn't even thought about packages that are required by other packages; it can lead to literally thousands of deps :-o.

Node/npm and the web need a standard library that can be included piecemeal, from a well trusted source and packages that only depend upon this small subset should be highlighted.

require('std/string/pad');

[1] http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/

I'm impressed how fast someone was able to turn this into a Unicorn :-) VCs will be stepping all over each other over this!

Seriously, some languages have broken package systems and it looks like it's not the case for JS ... in fact it's working so well they are used ad nauseam, for trivial things even. This is to be expected from a language that is very flexible, but does not offer 'standard' ways of doing things built in, or at least offers the functionality as part of the distribution of the language libs/modules. JS just hit puberty, and will mature ...

> isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons!

Exactly. And no amount of evidence or disasters will ever convince them otherwise, so we all laugh at them.

So you are refused to use react or babel, right?

There are two main factors that you're ignoring:

The first is that every added dependency creates ongoing cost, and that in a world where it becomes typical for a single application to have hundreds of dependencies, this cost is non-trivial and is, at minimum, worth considering.

The second is that even before the left-pad fiasco, a lot of experienced individuals (myself included) believed that npm is fragile by design; and that the dependency situation means that if you want to avoid nasty surprises, you need to pin every version of every dependency and you need to keep your own local copies of all of the files in case something like this happens.

Overall, you're accusing others of failing to fully understand the situation and of being condescending and rude; but you're doing it in a way that is condescending and rude, and that fails to fully understand the situation. Responses like yours are completely unhelpful. They do not change hearts or minds. They do not help npm fix their problems. And your caricature of those who find the situation funny is so distorted from reality that nobody will see themselves in it.

The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.

>>> a lot of experienced individuals (myself included) believed that npm is fragile by design

I agree with you!

>>> you're accusing others of failing to fully understand the situation and of being condescending and rude

I'm saying that people who say "massive helpers.js file yo" is not a solution. Improve the standard lib, npm and use lodash.

I'm also saying we all rely on other package managers so don't think just because you saw npm as flawed you get a free ride to say this couldn't happen with other systems. All of them have various ways of poking holes in any security you think they have.

At some point you have to put trust in your package manager. I'm riling against the people saying to copy and paste code everywhere.

>>> The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.

Disagree sure, but I think to say that my post is from a cesspool is a bit over the top!

Reply on news.ycombinator.com