5 ms·

always hilarious to see the dumb dependencies that these projects have https://github.com/sindresorhus/arrify https://github.com/sindresorhus/arrify https://g

always hilarious to see the dumb dependencies that these projects have https://github.com/sindresorhus/arrify https://github.com/sindresorhus/arrify https://github.com/JedWatson/classnames https://github.com/JedWatson/classnames

voltagex_ 8y ago
Is there a way to see what code in the project actually uses these dependencies? I gave up on learning Typescript for another 6 months after a starter template dragged in 400 dependencies.
- siftikha 8y ago
  Most low effort way is to search the repository on GitHub for the require. Also worth noting the ones I listed aren't transitive dependencies. Those are both explicit dependencies of this project
- maaaats 8y ago
  Why would that matter for learning typescript..?
  - Aeolun 8y ago
    If using typescript requires 400 dependencies, it’s a non-starter, and learning it is off the table until your boss forces you to.
    - voltagex_ 8y ago
      A Microsoft template for Vue+Typescript (which I've since learned was unmaintained) pulled in 400 dependencies.
city41 8y ago
Curious what your issue with classnames is? Is it just because it’s a small and simple module (50 lines of code)?
- anonytrary 8y ago
  I was curious so I checked out their Github page. I found this example: classNames('foo', 'bar'); // => 'foo bar' classNames('foo', { bar: true }); // => 'foo bar' classNames({ 'foo-bar': true }); // => 'foo-bar' classNames({ 'foo-bar': false }); // => '' classNames({ foo: true }, { bar: true }); // => 'foo bar' classNames({ foo: true, bar: true }); // => 'foo bar' ... var btnClass = classNames({ btn: true, 'btn-pressed': this.state.isPressed, 'btn-over': !this.state.isPressed && this.state.isHovered }); Look like the button example is a good enough convention for me, I don't need any of the other conventions. Can anyone tell me why this is not sufficient?: const classNames = (pojo, c=[]) => { for (let k in pojo) if (pojo[k]) c.push(k); return !!c.length && c.join(" "); } Do I need array-flattening support, multiple argument support? The size of this library probably comes from it supporting a handful of different coding styles. I would say the size (50 lines) is too large, if anything. Dependency worthy? I'm not convinced. I am very much so against requiring trivial utility functions from other people. Roll your own if it's trivial! It's better than depending on something over the network.
  - paperpunk 8y ago
    Roll your own, untested function vs a small, widely used library with a well-understood, well-tested API that your devs have a good chance of being familiar with already. I too want to avoid bloated npm dependencies but this seems like a fair engineering trade-off..
    - anonytrary 8y ago
      This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expect(classNames({a:true})).to.equal("a") }) it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) it("should work with falsy and truthy values", () => { expect(classNames({a: 5, b: ""}).to.equal("a b") }) This isn't redux. It's a trivial utility function. Your kind of thinking is too often applied without thinking. Before depending on someone's code, ask yourself if you can roll your own in under 5 minutes. The answer could easily be yes. There is no good reason to depend on someone else's code if it's trivial. Having more dependencies than you need is a cardinal sin that way too many javascript developers commit.
yuchi 8y ago
While I can understand your skepticism on the first one, the second package is actually very useful. It doesn't just concatenate strings filtering out falsy values, it supports the whole old AngularJS class format. You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Pretty neat, actually.
- anonytrary 8y ago
  > You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Why is this something you can't do on your own in a few lines of code? const classNames = (o, c=[]) => { for (let k in o) if (o[k]) c.push(k) // booleanish return c.join(" ") } This is not cool at all! Why import a trivial function over NPM to do this for you? Better to lower your dependency count and have a "util.js" file for helpers like this.
  - alexchamberlain 8y ago
    Playing devil's advocate, why is lowering your dependency count a good thing?
    - bthornbury 8y ago
      Dependencies have cost. You have to monitor for updates, notify the maintainer(s) of any bugs, keep an eye out for security vulnerabilities, and sometimes (gasp) even step through them with a debugger. Doing that for one dependency is bad enough, but for 100s it's a nightmare. Personally, I prefer to just pull the pieces I need out of an open source library (unless it's very well maintained, or huge). It's like doing a code review at the same time, so you're aware of what's going on in your application.
      - sumnulu 8y ago
        Replace “dependency” with “code / function” in your post and you will see the problem.
      - 8y ago
anonytrary 8y ago
const arrify = a => a && (Array.isArray(a) ? a : [a]) vs. introducing a potential attack vector.
- darekkay 8y ago
  arrify(null) returns null, unlike the arrify library . I expect that a function which turns things into an array returns an empty array as fallback. This ist just an example for why one would favor well-tested utilities over re-inventing the wheel (not that I would use arrify as a dependency myself).
  - anonytrary 8y ago
    > This ist just an example for why one would favor well-tested utilities over re-inventing the wheel No, it really isn't. The library does not dictate how things should be done, that's the fantastic thing about using your own utilities. In my implementation, we return the value itself if it's falsy. In yours, we return an empty array. Again, trivial "fix" (not that there's anything to "fix", it's a matter of convention, not correctness).

voltagex_ 8y ago

Is there a way to see what code in the project actually uses these dependencies? I gave up on learning Typescript for another 6 months after a starter template dragged in 400 dependencies.

siftikha 8y ago
Most low effort way is to search the repository on GitHub for the require. Also worth noting the ones I listed aren't transitive dependencies. Those are both explicit dependencies of this project
maaaats 8y ago
Why would that matter for learning typescript..?
- Aeolun 8y ago
  If using typescript requires 400 dependencies, it’s a non-starter, and learning it is off the table until your boss forces you to.
  - voltagex_ 8y ago
    A Microsoft template for Vue+Typescript (which I've since learned was unmaintained) pulled in 400 dependencies.

city41 8y ago

Curious what your issue with classnames is? Is it just because it’s a small and simple module (50 lines of code)?

anonytrary 8y ago
I was curious so I checked out their Github page. I found this example: classNames('foo', 'bar'); // => 'foo bar' classNames('foo', { bar: true }); // => 'foo bar' classNames({ 'foo-bar': true }); // => 'foo-bar' classNames({ 'foo-bar': false }); // => '' classNames({ foo: true }, { bar: true }); // => 'foo bar' classNames({ foo: true, bar: true }); // => 'foo bar' ... var btnClass = classNames({ btn: true, 'btn-pressed': this.state.isPressed, 'btn-over': !this.state.isPressed && this.state.isHovered }); Look like the button example is a good enough convention for me, I don't need any of the other conventions. Can anyone tell me why this is not sufficient?: const classNames = (pojo, c=[]) => { for (let k in pojo) if (pojo[k]) c.push(k); return !!c.length && c.join(" "); } Do I need array-flattening support, multiple argument support? The size of this library probably comes from it supporting a handful of different coding styles. I would say the size (50 lines) is too large, if anything. Dependency worthy? I'm not convinced. I am very much so against requiring trivial utility functions from other people. Roll your own if it's trivial! It's better than depending on something over the network.
- paperpunk 8y ago
  Roll your own, untested function vs a small, widely used library with a well-understood, well-tested API that your devs have a good chance of being familiar with already. I too want to avoid bloated npm dependencies but this seems like a fair engineering trade-off..
  - anonytrary 8y ago
    This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expect(classNames({a:true})).to.equal("a") }) it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) it("should work with falsy and truthy values", () => { expect(classNames({a: 5, b: ""}).to.equal("a b") }) This isn't redux. It's a trivial utility function. Your kind of thinking is too often applied without thinking. Before depending on someone's code, ask yourself if you can roll your own in under 5 minutes. The answer could easily be yes. There is no good reason to depend on someone else's code if it's trivial. Having more dependencies than you need is a cardinal sin that way too many javascript developers commit.

yuchi 8y ago

While I can understand your skepticism on the first one, the second package is actually very useful. It doesn't just concatenate strings filtering out falsy values, it supports the whole old AngularJS class format. You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Pretty neat, actually.

anonytrary 8y ago
> You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Why is this something you can't do on your own in a few lines of code? const classNames = (o, c=[]) => { for (let k in o) if (o[k]) c.push(k) // booleanish return c.join(" ") } This is not cool at all! Why import a trivial function over NPM to do this for you? Better to lower your dependency count and have a "util.js" file for helpers like this.
- alexchamberlain 8y ago
  Playing devil's advocate, why is lowering your dependency count a good thing?
  - bthornbury 8y ago
    Dependencies have cost. You have to monitor for updates, notify the maintainer(s) of any bugs, keep an eye out for security vulnerabilities, and sometimes (gasp) even step through them with a debugger. Doing that for one dependency is bad enough, but for 100s it's a nightmare. Personally, I prefer to just pull the pieces I need out of an open source library (unless it's very well maintained, or huge). It's like doing a code review at the same time, so you're aware of what's going on in your application.
    - sumnulu 8y ago
      Replace “dependency” with “code / function” in your post and you will see the problem.
    - 8y ago

anonytrary 8y ago

const arrify = a => a && (Array.isArray(a) ? a : [a]) vs. introducing a potential attack vector.

darekkay 8y ago
arrify(null) returns null, unlike the arrify library . I expect that a function which turns things into an array returns an empty array as fallback. This ist just an example for why one would favor well-tested utilities over re-inventing the wheel (not that I would use arrify as a dependency myself).
- anonytrary 8y ago
  > This ist just an example for why one would favor well-tested utilities over re-inventing the wheel No, it really isn't. The library does not dictate how things should be done, that's the fantastic thing about using your own utilities. In my implementation, we return the value itself if it's falsy. In yours, we return an empty array. Again, trivial "fix" (not that there's anything to "fix", it's a matter of convention, not correctness).