Just: A library of dependency-free JS utilities that do just do one thing
github.com
github.com
The size or scope of left-pad wasn't the issue, the ability to unpublish modules which were depended on was [1]
http://blog.npmjs.org/post/141905368000/changes-to-npms-unpu...
That is not what a predicate is.
Copied here nevertheless:
> 2. (logic) A term of a statement, where the statement may be true or false depending on whether the thing referred to by the values of the statement's variables has the property signified by that (predicative) term.
> 3. (computing) An operator or function that returns either true or false.
It doesn't, really. Criticizing poor choice of terminology is still criticism.
I just prefer brevity more than you do. But you would've still downvoted me even if i'd provided a link, no?
You comment was not useful (or at least not as useful as it could be).
Put in more effort next time - a comment is written once, but read many times.
IMHO, people in the technical industry should first try to find knowledge by themselves, and ask only when it is not easily accessible. If you keep asking questions which you can find answers by Googling, hmm, how do you even survive in this industry? That is, if you're not in management, of course.
In mathematics sure, but not everyone has had the same level of exposure to mathematics in software.
It's likely OP was using this definition, which in a programming context is effectively synonymous with "unary function".
Not trying to restart any discussion here, just wanted to clarify for any future visitors.
So these modules are small, but anything that uses them is going to contribute to the proliferation of dependencies just as much as ever.
// extend
Object.assign({}, { foo: 'bar' }, { baz: 'qui' });
// pluck
[{ a:1, b:1 }, { a:2, b:2 }].map( obj => obj["a"] )
// filter obj
Object.keys(obj).reduce( ( result, key) => {
const value = obj[key];
if ( value < 6 ) {
result[key] = value
}
return value;
}, {})
// map obj
Object.keys(obj).reduce( ( result, key) => {
result[key] = obj[key] + 1;
return value;
}, {})
// template
const data = { a:1, b: { c: 1 }, d: 2 };
`some ${data.a}, ${data.b.c}`;
// unique
[1,2,2,3,4,4,5].filter( ( value, index, self ) => self.indexOf( value ) === index )
// last
[1,2,3].slice(-1)[0]
// union
[1,2,3,4].concat( [6,7,8,9] ).filter( ( value, index, self ) => self.indexOf( value ) === index ).sort( ( a,b ) => a-b )Ended up writing my own mini-routine instead. If I ever need enough of Lodash to care I'll just import the whole thing, which is the only way to get lazy evaluation anyway.
It also offers modules inside the primary package now, e.g. require('lodash/chunk').
There's babel and webpack plugins to make cherry-picking and bundle size optimizations a breeze too.
Back to plan A: Don't use Lodash in client code unless I'm willing to use the whole thing (so that I can get the chaining optimizations, which cherry picking doesn't support anyway).
Babel works great without shims in modern enviros (I don't use shims in my projects).
1: https://twitter.com/angustweets/status/754375515159441408
I'll never criticise anyone for releasing OSS but ultimately he just becomes the things that half of NPM relies on and the vicious cycle continues.
There are 10 modules that you need to imports if you are using 10 functions. I think it's unnecesary
(It was ridiculous then, and it is ridiculous now)
I agree. WTF? LoDash was here all along... What is this discussion about?
Somebody wanted to write code in a particular way and extended the language with a couple of utilities for doing so, then decided to publish it for others to use.
I don't see the problem. Could you elaborate?
This, like many stuff I see in the javascript world, is overegineering.
* https://github.com/angus-c/just/blob/master/packages/array-l...
E.g typescript. Entire compiler and language server. No dependencies.
Es6 is a decent library out of the box. I always only add a dependent if it's something not trivial.
A lot of the shitty packages came out before tree shaking was a thing.
There is an argument. Should you just have a large hash table of functions that you reference. Those in the bandwagon go for the one function packages.
That aside, to me, putting the data argument first would seem to make the code more readable.
It sure is confusing why the author implemented these functions...
Regardless, any sort of environment where you can do `import extend from 'just-extend';` is going to (have a way) support map and filter.
That is not true for the now-fairly-common use case that browserify/webpack satisfy. I write code with ES6 module syntax and build with browserify (& babelify) to target the browser. But I still need to pull in modules like lodash.map/lodash.filter if I want to target IE8.
(I could use es5-shim but that makes for less portable code).
It's _not_ because it's convention everywhere else.
(I realize that only really makes sense if you know why it makes sense, so this video gives a pretty good explanation in ~30 minutes - https://www.youtube.com/watch?v=m3svKOdZijA)