BUG! (I think) using '#' as a 'ch' value pads the string with spaces: $ curl ' https://api.left-pad.io/?str=wat&len=10&ch=#' {"str":" wat"} Please provide github link to fork/submit pr :)
Left-pad as a service
111–120 of 269 posts
Re: Left-pad as a service
#112Hahaha - 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…
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.
Re: Left-pad as a service
#113Is it rate limited?
Re: Left-pad as a service
#114Earlier quoted context omitted.
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.
Re: Left-pad as a service
#115Earlier quoted context omitted.
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 th…
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…
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.
Re: Left-pad as a service
#116Hahaha - 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…
Re: Left-pad as a service
#117Earlier quoted context omitted.
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 p…
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.
Re: Left-pad as a service
#118Earlier quoted context omitted.
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).
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.
Re: Left-pad as a service
#119Earlier quoted context omitted.
> 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.
> 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