Fork me on GitHub
Garrett Hopper16:06:12

@lee.justin.m What library were you trying to use that wasn't working. After @thheller pointed me to this issue:, I was able to build the closure compiler and the clojurescript compiler (to use the new closure snapshot), and everything seems to be working for me.


can't remember. it was some react component lib.


@ghopper I was trying to get ghostwheel to work. For the life of me I can’t figure out why it doesn’t.

Garrett Hopper16:06:38

Oh, ok. I thought you were having issues with some npm deps.


oh actually, he responded to my bug report. it was an actual bug.

Garrett Hopper16:06:27

:thumbsup: Cool Ghostwheel is one of those things on my list to play with soon. 🙂


@ghopper You can usually update your app to new Closure-compiler without touching ClojureScript by adding the closure-compiler dependency to your own project

Garrett Hopper16:06:11

Oh really? I'll have to try that.


Local dependencies override transitive dependencies (i.e. closure from clojurescript)

Garrett Hopper16:06:17

So just adding {:mvn/version "1.0-SNAPSHOT"} to my deps.edn should do it?

Garrett Hopper16:06:50

Huh, is there documentation on transitive dependencies somewhere to help me understand?

Garrett Hopper17:06:20

@juhoteperi, so by default dependencies are transitive and able to be overriden? Is there a way to specify this scope with deps.edn? The clojurescript deps.edn doesn't specify a scope for any of its dependencies.


I'm not really familiar with tools-deps. But I believe the default scope is compile there so the deps are transitive. And all dependencies are overridable, no matter scope, because JVM only supports single version of a class in classpath so several versions of a lib can't be loaded at the same time.


And the official clojurescript package is created by Maven so the dependencies are read from pom.xml

Garrett Hopper17:06:36

Oh, ok. That's very helpful. Thanks I didn't realize there couldn't be multiple in a JVM.


Clojurescript project has project.clj and deps.edn for development but pom.xml is what is used for packaging

Garrett Hopper17:06:12

Oh, right. I'd just did a grep replace to upgrade the closure version. Do you know why there's a deps.edn, pom.xml, and project.clj?

Garrett Hopper17:06:20

Ha, nevermind. You just answered my question.

Garrett Hopper18:06:12

Are there any known issues with using a remote library in :foreign-libs (with a URL as :file) and :npm-deps? It seems to be collapsing the to http:/url when :npm-deps is present. If not, I'll write up a minimum reproducible later.


@ghopper I don’t recall seeing any issues like that.

Garrett Hopper19:06:49

Hmm, ok. I'll play with it more later. Strangely, it's not even when I'm importing the foreign library, it's when I try to import the npm dependency that it complains about the URL of the foreign library.