Clojurians Log v2

I noticed there is no tag in github for yesterday's release, is that intended?

it's a JVM only release that fixed data_readers.clj

if nobody else complains I'll leave it like this until the next ;)

does this belong to the jvm release? https://hub.docker.com/layers/cljkondo/clj-kondo/2025.09.22/images/sha256-7b7edc6322306d535da3797d7ada88994ca04547a8e8855c6c76ac51c579fb09

I guess not

then it's a JVM + Docker release ;)

are you experiencing any troubles? I can make this a full release, but it's a bit time consuming to do this, so I thought it'd be ok this way

No issues. I just thought I'd bump the versions we/I reference in a few places, including a hook dev alias https://github.com/ekataglobal/expect-call/blob/2d60aefd30cc40921ce09ebda9cc6778f276dd9d/deps.edn#L8 and was surprised to not find the tag. No biggie, I can just reference the sha.

ok, let me just make a full release since I can see how this would confuse other people too

sorry, didn't want to put more work on you

no worries. it's a bit sloppy to half-ass a release anyway. github release is now available.

all done now

Much appreciated!

yes sorry about that :) I'll make a new release

this is the result of me trying to use the CIDER debugger (after so many years again rediscovered it) and then running tests on the command line...

Thanks for the release!

ah yes, the JVM release is already up

Thanks! Nesting seems to be a bit off in the suggested config in the op there

I'll try to make a few screenshots re: Cursive now

thanks, fixed the nesting

@borkdude I made some quick Cursive+aliases docs at https://gist.github.com/imrekoszo/9b879a4bd9c2042dbd56c2657f650cce

thanks!

nw, feel free to ask if need more info I'm secretly hoping that what's being cooked in the current thread, plus my docs might help https://clojurians.slack.com/archives/C02RPGUCQNB/p1753753932993599 when using both tools plus advanced clj classpath setups

i prefer when tools do that (as seen by how i've built splint)

what exactly do you mean?

sorry, i mean that i think your proposal of linting dependencies by scanning project.clj or deps.edn or whatever to be a good one.

splint either lints the files you tell it to lint, or it looks for a deps.edn/project.clj and finds the paths to lint from it

k. it's not just about paths, but also deps which may involve aliases, etc

sure. when i run tsc it picks up all of the type definitions in my dependencies as well (including dev dependencies)

With clj being as powerful as it is, I would like to be able to use clj-kondo to lint various classpaths in the same project actually. Effectively with clj you can have multiple completely different applications in the same project, using a single deps.edn. A non-contrived example of this is one where you have: 1. Your actual app (with top-level deps and paths) a. an optional extension of this where you also use your :test and/or :dev aliases together with the top-level 2. Your build scripts which normally live under some alias like :build , and use :(replace-)deps and/or :(replace-)paths, isolating it from the main app 3. clj-kondo hooks In the above situation I would ideally like to be able to lint: 1. just the production code for my app (so no dev/test deps accidentally override anything and hide an error I might have) 2. the production code with test code (I also like to have my tests in a good shape) 3. the build system 4. the hooks clj is flexible enough to allow me to create a classpath for any of the above, and still have some caching under .cpcache. I feel like anything less would make me prefer managing my own classpath. It would however be extremely nice for all of the above work without having to manually manage that classpath.

my initial idea would be to let you define multiple projects like this:

{:projects {:main {:deps true :aliases [:foo :bar :baz]}}
            :bb {:classpath-cmd ["bb" "print-deps"] :source-paths ["bb"]}}

clj-kondo --lint :main:bb 

when you combine multiple projects, it would just smash the classpaths together and also the project paths to report about

(maybe add a caching which md5 hashes the stuff or so for caching for project.clj)

I don't have anything better to suggest atm. How would copy-configs and caching work with these? If I maintain multiple apps, those will have different deps, different dep-exported configs/hooks etc. Would you consider making caching/imports multi-tenant?

it would work exactly the same as currently called from the command line

but sure, we could do a per-project cache perhaps, if that's useful, not sure

that likely wouldn't work well with editor stuff though, clojure-lsp etc

so initially, that's out of scope but something to consider maybe later

Maybe I'm too used to Cursive but there you select the aliases you want to work with. That drives a lot of things actually

can you make a screenshot or are there docs about it? one question I have about this is that some aliases exclude other aliases if they use :deps or :replace-deps instead of :extra-deps

I guess in that case you would maybe just define an extra project

Will do tomorrow if that's okay. @cfleming might have something at hand

https://cursive-ide.com/userguide/deps.html#working-with-aliases and the following section give some info but there are lots of nuances. I'm not sure if it's documented what things it affects

IJ has its own framework for static analysis and Cursive integrates with it. Aliases selected in the deps tool window affect what Cursive tells IJ about project paths and deps etc. Selecting a :deps alias (which Colin calls tool aliases) can have pretty drastic effects actually

drastic as in?

Made an issue: https://github.com/clj-kondo/clj-kondo/issues/2632