291–300 of 887 posts
Granted, these modules don't do such useful things, but that's the environment their creators were immersed in.
Earlier quoted context omitted.
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!
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.
Edit: But there would sure be a period of chaos.
Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
Earlier quoted context omitted.
OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.
...and then the publisher pulls their library off npm, and another shows up and drops one of the same name in its place, with compatible version numbers (by happenstance or otherwise).
Earlier quoted context omitted.
This sounds like a symptom of an inadequate standard library. I do expect to be able to call "average" on a list of numbers without writing it myself, but I expect that to be part of the language not a 3rd party package.
> I do expect to be able to call "average" on a list of numbers without writing it myself Just out of interest, what kinds of functions would you expect to have to write yourself, if you're not happy about calculating the average of a list of numbers?
The problem is the lack of a test culture.
Earlier quoted context omitted.
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 "…
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 ali…
Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
This is more a reflection of how bad the JS language is than anything. Real programming languages have means of standardizing the most common UX and simple patterns into a standard library. Javascript is a consortium hell that never gets updated sufficiently, and has no good standard library, so NPM basically replaces the standard library with a thousand micropackages.
Earlier quoted context omitted.
This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…
They do NOT encourage code re-use because the effort required to understand your need, refrain from writing code, and hunt down a module in npm, far outweighs the effort to just write the code and stick it in your in-house utils library.