Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So many people use lodash as a drop-in standard addon library that I'm surprised people aren't just using the padding functions that are right in there... Some of the packages that broke yesterday even have lodash included as dependencies already!


Looking at the changelog, there have been more than 70 versions of Lodash in less than four years. The first was in April 2012. [1]

  _.padleft
does not exist. It was added as part of version 3.0.0 January 26, last year and renamed to _.padstart in Version 4.0 on January 12, this year.

So in less than a year "padleft" came and went away because all strings don't start on the left and someone decided that "left" means "start" except that the reason that it doesn't is the reason that it was changed. Even worse, the 4.0 documentation does not document that _.padstart renamed _.padleft. It's hard to grok what cannot be grepped.

Why blame someone for depending on padleft in a world where libraries swap out abstractions in less than a year? Breaking changes are bad for other people. Semantic versioning doesn't change that.

[1]: https://github.com/lodash/lodash/wiki/Changelog


Yes, I found a number of the stylistic changes made in Lodash 4.0 made it more complicated to upgrade than needed.

Dropping the this param with no period of deprecation? Pretty breaking change to make with no warning. Renaming first/rest to head/tail? Was it really worth it? Particularly when they go the opposite direction of replacing traditional functional names with more explanatory names by removing the foldr alias for reduceRight.

All this in a language that doesn't make it easy to do automated refactoring means that you basically break everything upgrading to Lodash 4.0 so you can't refactor parts to the newer style piece by piece.


The reason for the name change and the Parma change is that String.prototype.padStart is being added in the next ECMAScript release, and lodash was changed to be compatible with the newly built-in version (so it's a polyfill).


An easy solution would be to have both padStart and padLeft, with a note in tbe changelog saying padLeft is deprecated and will be removed in a future version.


Damn, yeah, that's a totally valid reason. I was under the impression that lodash was more stable than to have that kind of stuff happen.


What if lodash itself was unpublished? I'm having a hard time drawing a line here, obviously a 10 line function is too far on the bad side of lazy, but I can't tell what is an acceptable dependency.


I think it would be annoying but recoverable. It's used so widely that somebody would republish it, at worst under a different name.

Edit: But there would sure be a period of chaos.


So it's the same with pad-left. But some how people are wrong for depending on pad-left.


If you depend on Lodash, you depend on Lodash. You have 1 point of failure.

If you depend on 2,000 tiny individual modules, each from different authors, you depend on 2,000 tiny individual modules. You have 2,000 different points of failure. Any one of those authors going rogue will break your build or compromise your system, and every one of those tiny modules has a lot less attention and care paid to it than a larger library like Lodash.


Probably they do use that if they need left padding but also have a dependency on another package that thinks 'lodash is too big when all I need is left padding' so we get to this situation




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: