@ttx can provide aero support in #juxt, but you can make an #include optional, as long as you're on latest. Will invite to #juxt to continue discussion.

is there a built-in way to clear every cache in boot? i know I could probably rm -rf /path/to/.boot/cache/tmp/project but i’m curious

Hmh, I wonder why Boot doesn't just put the temp dirs on the project folder, under .boot or something

That would at least take care of removing the temp dirs at the same time as removing the project folder

yea i’m not sure. i’m still working on debugging https://github.com/boot-clj/boot-cljs/issues/168 . I know how it breaks (finally) but I’m not quite sure why. I think it’s something to do with an improper :dependencies [re-frame "" :exclusions [reagent]]

but ive been fighting with stale/cached internal libs and :checkouts via boot when debugging that issue.

@lwhorton Check boot show -d and check all versions of cljsjs/react-*

And cljsjs/create-react-class though I think only Reagent will depend on that

is there some canonical docs explaining how :exclusions works? I’m not sure I have my internal libs working properly wrt :scope "provided" and exclusions.

https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

I see. I think i’ve been working it backwards. In my main app I have something like [my-org.my-reframe "0.0.1"] and from my-reframe I exclude reagent. Then in the main app I bring in :dependencies [reagent "x.x.x"] so in essence it “brings the versions of reagent I want to use into my internal reframe”.

But I think this is backwards, and I should not even depend on reagent in main app, only my-org.my-reframe

Hmh, if you call reagent directly from your main app code, it is usually good idea to have direct dependency

If you use a, have dependency on it even if another package b has transitive dependency on a. This way you can decide which version of a you app needs, and you prevent problems in case if b removes dependency on a.

Also, I usually use :exclusions very sparingly. Instead I add direct dependency on the application if I need to ensure I get specific version of some dependency.

yes that makes sense, but i’m not sure the proper syntax. if app depends on a 1 and b 1, but a 1 has a dependency on b 1 too — what do you do?

nothing needs to be done if they depend on the same version?

so maven automatically takes care of packaging up the proper artifacts given the same version?

it works even if there are different versions

[a "1.0"] and [b "1.0"] where b depends on [a "0.1"] => you get [a "1.0"] and [b "1.0"]

[a "1.0"] and [b "1.0"] where b depends on [a "2.0"] => you still get [a "1.0"] and [b "1.0"] which are the "closest dependencies"

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies

in the latter case you'd update your project's dependency on [a "1.0"] -> [a "2.0"] to fix b

> "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0

Aha. I need to spend more time reading over the mvn site. thanks for hand-holding me through this

Did looking at the deps help with the problem?

i’m making sure all my sub-libs are using the proper deps before I report back the boot show -d . getting rid of exclusions and :scopes that aren’t necessary .. will ping shortly

here’s my deps listed out. https://github.com/boot-clj/boot-cljs/issues/168#issuecomment-320749755