Fork me on GitHub
Ben Sless07:11:56

> Notice a typo in my slides as I'm giving a presentation with Alex in the audience That was fun πŸ™ƒ

Alex Miller (Clojure team)11:11:44

Typos happen, no worries. Good talk!

πŸ™ 1

Wow. πŸ˜„ Can't help but laugh at this chaotic-good stunt. > I will pay you cash to delete your npm module


NOt a front end dev, are people really pulling in a dependancy to check something is an array ? Or is this likely being pulled in by another popular dependency (that is istelf a lot more complicated)


And it's not about frontend necessarily - NodeJS is susceptible as well of course.

☝️ 1

I keep forgetting there are souls out there using javascript on the server.


I remember in uni, eons ago, we had a short course on javascript. It was maybe only a couple of months long and our lecturer at the time bemoaned he was having to teach this nonsense. Said we have to learn it to pass, but dont ever expect to ever do this in the real world. I'd love to talk to him now!


That's not the only component though - with leftpad and isArray, it would be easier to just copy the few lines of code themselves than to install a new library. The reason I've met the most to install something like that instead of vendoring it is "but what if the right way to do it changes - how will I know?"


The main root cause is IMO the same one as behind the bots that automatically update your dependencies, then create PRs, and self-merge them.


"handy for knowing" - yes. Although npm itself is sufficiently good for that IMO. What is bizarre is updating the dependencies automatically.


Tests reduce the probability of something failing, but they do not multiply it by 0, even good ones. Reading changelogs is good. Reading the actual code changes is the best.


The only thing that's even better is not updating a dependency you don't need to update. :)


> it's a lot of work It is!


NPM is indeed rather pathological here, with 1 thing depending on N with N >> 1, recursively.


That's amazing. What a Fantastic Gentleman.


From the "conclusion" section: > Most Node developers have no idea what’s in their dependency tree. Most of them are thousands of entries long, and have never been audited. This behavior is totally reckless and needs to stop. I'm careful about adding dependencies to Clojure projects because of a potential explosion of dependencies. It's why we mostly stopped using the taoensso libraries ages ago and why we switched from clj-http and Cheshire to Hato and recently.


Even as it is, our codebase drags in over 200 deps:

(! 1049)-> clojure -X:deps list :aliases '[:dev :everything]' |fgrep -v /Developer|wc
     234     468    8760


I've spent most of my career as a predominantly front-end developer, and node.js dependency trees across the board are an utter mess. The idea that "modules should do one thing and do it well" turned into "let's put individual functions into their own modules!". This is nice in some cases because it helps reduce build size on the front-end, but more often than not results in a dep tree that is impossible to understand.


@U04V70XH6 Interesting, I always thought of taoensso libraries as being rather lean, having only really necessary dependencies. Do you remember some specific offender that had a large dependency tree?


(! 510)-> clojure -Sdeps '{:deps {com.taoensso/timbre {:mvn/version "RELEASE"}}}' -Stree
Downloading: com/taoensso/timbre/maven-metadata.xml from clojars
Downloading: com/taoensso/timbre/5.1.2/timbre-5.1.2.pom from clojars
Downloading: com/taoensso/encore/3.12.1/encore-3.12.1.pom from clojars
Downloading: org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.pom from central
Downloading: com/taoensso/truss/1.6.0/truss-1.6.0.pom from clojars
Downloading: org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar from central
Downloading: com/taoensso/truss/1.6.0/truss-1.6.0.jar from clojars
Downloading: com/taoensso/encore/3.12.1/encore-3.12.1.jar from clojars
Downloading: com/taoensso/timbre/5.1.2/timbre-5.1.2.jar from clojars
org.clojure/clojure 1.10.3
  . org.clojure/spec.alpha 0.2.194
  . org.clojure/core.specs.alpha 0.2.56
com.taoensso/timbre 5.1.2
  . com.taoensso/encore 3.12.1
    . org.clojure/tools.reader 1.3.3
    . com.taoensso/truss 1.6.0
  . io.aviso/pretty 0.1.37
They're all fairly interdependent (or were, last I looked) and they all changed very frequently.


Oh yeah, should've mentioned - my perception of those libraries stems from the context where I myself usually end up using most of those, like e.g. carmine, encore, and sente all together. So they don't bring many thirdparty dependencies.

πŸ‘ 1

We did use Carmine for a short while too (but switched to plain ol' Jedis, with our own connection pool, written using core.async):

(! 511)-> clojure -Sdeps '{:deps {com.taoensso/carmine {:mvn/version "RELEASE"}}}' -Stree
Downloading: com/taoensso/carmine/maven-metadata.xml from clojars
Downloading: com/taoensso/carmine/3.2.0-alpha1/carmine-3.2.0-alpha1.pom from clojars
Downloading: com/taoensso/timbre/5.1.0/timbre-5.1.0.pom from clojars
Downloading: com/taoensso/encore/3.9.2/encore-3.9.2.pom from clojars
Downloading: com/taoensso/nippy/3.1.1/nippy-3.1.1.pom from clojars
Downloading: com/taoensso/nippy/3.1.1/nippy-3.1.1.jar from clojars
Downloading: com/taoensso/timbre/5.1.0/timbre-5.1.0.jar from clojars
Downloading: com/taoensso/encore/3.9.2/encore-3.9.2.jar from clojars
Downloading: com/taoensso/carmine/3.2.0-alpha1/carmine-3.2.0-alpha1.jar from clojars
org.clojure/clojure 1.10.3
  . org.clojure/spec.alpha 0.2.194
  . org.clojure/core.specs.alpha 0.2.56
com.taoensso/carmine 3.2.0-alpha1
  . com.taoensso/encore 3.9.2
    X org.clojure/tools.reader 1.3.3 :superseded
    . com.taoensso/truss 1.6.0
  . com.taoensso/timbre 5.1.0
    X com.taoensso/encore 3.4.0 :older-version
    . io.aviso/pretty 0.1.37
  . com.taoensso/nippy 3.1.1
    . org.clojure/tools.reader 1.3.4 :newer-version
    . com.taoensso/encore 3.9.2
    . org.iq80.snappy/snappy 0.4
    . org.tukaani/xz 1.8
    . org.lz4/lz4-java 1.7.1
  . org.apache.commons/commons-pool2 2.9.0
  . commons-codec/commons-codec 1.15


We were using Nippy at some point too, but again we switched away from it.


But even just with Carmine above, you see superseded, older-version, and newer-version in the deps tree so it's not even internally self-consistent and that bothers me.


Hmm, right, I see. Thanks!

Dmytro Bunin18:11:04

we have a library that uses isArray πŸ™‚ the code is copied over though

Ben Sless18:11:25

Not sure where would be the best place to share a gist for a weird piece of code I came up with


I thought there was a show-and-tell channel but apparently I was mistaken

Ben Sless19:11:29

yeah, it's a better fir for show&tell or releases


Oh that's right, #show-and-tell does exist and is probably more relevant than #releases

Ben Sless05:11:12

Sure, I'll put it properly in a repo later today

thanks 1
πŸ†’ 1
Ben Sless05:11:31

In a couple of hours, I assume


Super interesting, thanks!

πŸ‘ 1
Ben Sless13:12:59

Totally forgot about methodical. Now when I find the time I have to see how Cam implemented the double dispatch mechanism @πŸ™ƒ