Clojurians Log v2

How stable is this part of the tools.deps API:

user=&gt; (require '[clojure.tools.deps.alpha.util.dir :refer [with-dir]] '[hf.depstar :refer [uberjar]] '[<http://clojure.java.io|clojure.java.io> :as io])
nil
user=&gt; (with-dir (io/file (str (System/getProperty "user.dir") "/projects/api"))
         (uberjar {:jar "../../../build/uberjars/api-2.0.0.jar" :main-class 'api.main :aot true}))
[main] INFO hf.depstar.uberjar - Compiling api.main ...
[main] INFO hf.depstar.uberjar - Building uber jar: ../../../build/uberjars/api-2.0.0.jar
nil
user=&gt; 

Hi all. I’m just getting around to tackling the https://clojure.org/releases/tools#v1.10.2.790 https://clojure.org/releases/tools#v1.10.2.790 warning now for my monorepo. I have read through Sean’s posts and conversations in this channel about monorepo setup with this new constraint. I have outlined my https://gist.github.com/athomasoriginal/47913c6b946fc7416c3d839be101e600 and wanted to see if this aligns to the “recommended approach”? > I use “recommend” lightly. My goal is to be sure the approach is not going against the grain too much or setting myself up for future pain. Thanks!!

Sounds about right but I'll elaborate a bit on a couple of our monodeps setup...

I assume you mean :extra-paths in there, not :external-paths

Our "workspace-level" deps.edn has an :everything alias which has :extra-deps listing each subproject as a :local/root dep and :extra-paths listing each subproject's test folder -- we use this alias for starting a global REPL to work with the entire codebase. I think that's an important affordance.

That top-level deps.edn file is where we declare any/all tooling -- but we don't have cljs subprojects so I don't know how that would change the equation (if at all).

why are app and app-server separate? app is what you build and app-server is what you deploy?

one thing coming is the ability for projects to publish that they must be "prepared" before use and for consumers of that project to ask to do that preparation

I'm trying to understand your bigger use case here and whether that could be used for advantage (having app-server consume app as a local dep, which has a prep step)

> I assume you mean :extra-paths in there, not :external-paths Yes. My bad 😞

> why are app and app-server separate? • app is the ClojureScript application (client) • app-server is the web-server serving static assets and a REST API My preference is separation because i’ve found it makes it easier to understand the backend/front end divide and helps avoid coupling tooling. Before I go further though, does that clarify? I’m not sure I understand your comment: “app is what you build and app-server is what you deploy” :thinking_face:

I suspect app-client and app-server might have been less confusing names 🙂

I think you are correct 😉

ah ok, that makes sense

I think I understand your build v. deploy question now though 🙂

> I’m trying to understand your bigger use case here and whether that could be used for advantage Does the use case make more sense now? It might be outside the scope of the feature you’re considering though?

not sure, might still be a good match?

app would have some build process and publish in its deps.edn how to run it. use :path including the output of that process. app-server would depend on app

Yeah, that’s it.

there may be some tooling that will need to catch up to all that though

> That top-level `deps.edn` file is where we declare any/all tooling @seancorfield I am re-reading your post again, but in my scenario my driver for relying on paths external to the app-server project was only so I could have access to app-client s resources and target dirs because I feel it’s awkward to have those specified in the app-server project while your developing the app’s front end. So I believe a difference is that I don’t actually need to work with clj code, I just did it to serve static assets in development.