I have a transitive dependency to an artifact with a reported security vulnerability. With Leiningen, I'd add a :managed-dependencies entry for a version of that artifact where that vulnerability has been fixed. What's the "right" way to do this with deps.edn? Just add a :deps entry?

@flowthing I think so yes, tools.deps will pick the newest version possible that is required in the deps tree

All right, thanks. :thumbsup::skin-tone-2:

Hi all. Is there a way of referencing an alias (or indeed multiple aliases) in a git coordinate in a deps.edn file? The background is https://clojurians.slack.com/archives/C03S1KBA2/p1618904583308100 but essentially, I’d argue this approach might foster modularity and composability - permitting declaration of faceted dependencies. An example might be a repository aligned to a business domain with core code that can be used as a library, but an alias providing, say, ring handlers or graph resolvers that clients can explicitly opt-in or out of, to bundle the functionality into a server application. Possible with maven - by building different artifacts - and with a multiple repository model. Am I barking up wrong tree?

@mark354 I had something like this with boot: https://github.com/borkdude/boot-bundle But nowadays we just use some EDN to list the deps + fixed versions we need and use a babashka script to update our deps.edn. This is very fast and only needs to happen when we update a dependency.

Another approach might be to just make a library which depends on other libraries and use that as the managed dependency, tools.deps will always use the newest versions of a lib in a dependency tree, I think

(off topic, but slightly related: Found another good use for fs/modified-since (a new function in babashka.fs): https://gist.github.com/borkdude/35bc0a20bd4c112dec2c5645f67250e3#file-1-bb-edn-L2-L5 We rebuild our deps.edn from a template when any relevant files on which it depends changes, when invoking any task. )