Clojurians Log v2

one problem with doing so is that it could override analysis for the more complerte source analysis if both source and .class exist

https://github.com/clj-kondo/clj-kondo/issues/2792

sounds good. but I wonder how to ensure that source has priority, if the .class file is linted later than the source file

can that happen if they are both in the same jar?

sure?

or people accidentally run clj-kondo on a target dir where they built an uberjar

for jars, does it matter - the class file data is cached, but the source info is always returned and processed, iiuc. There are maybe some failure cases which could leave the cache populated but not have processed the source.

I don't understand sorry. • "for jars, does it matter" - what do you mean? clj-kondo doesn't only accept jars, but also directories or separate files. • the class file data is cached - huh, who caches it? what do you mean? the source code info is always returned and processed: huh? sorry, you need to explain

My understanding: • the sources-from-jar jar processing happens as part of process-files, the first step in the lint pipeline, • For source files, the source info is returned, and processed later in the pipeline,, by index-defs-and-calls and then sync-cache, writing the cache for for the vars based on source. the proposal: • Write the cache files for init.class files during sources-from-jar. • source info is processed after this, which would overwrite the cache info from the init.class file.

Do you mean to make your lib more user friendly for end users or so?

Refer all is discouraged anyway

In clj-easy we have a lib to create a stub library with just the signatures. Users could then add this to their classspath for kondo and LSP

Yes - remove warnings for undefined symbols from the namespaces it defines. :refer :all is discouraged, but this is for an embedded language with hundreds of symbils. I was aiming for something that worked without any special user setup.

for the stubs, we would need to ensure the mtimes were older than the .class files, which seems like a potential source of confusion.

I'm on my phone right now but Clojure-LSP has some useful docs on this I think. You only have to add them to your lint classpath, not to your dev classpath

I'm open to suggestions though, eg deriving the signature from class files now that we have libs for it anyway

But why even bother just shipping class files. With Claude etc you can probably reverse engineer the Clojure these days anyway

Or maybe ship Clojure files for the API only and class files for all the impl?

that last one might fly

looks like a no go. Support in clj-kondo could either go through stubs in some way, or just analyse .class files. The later seems easiest. Would that be something you would be open to?

If it doesn't get too crazy, worth a shot

let me know if I can provide any further conntext/clarity

I'll be hopefully able to review this code soon

(there is no urgency)

So if I understand correctly, the flow is: When analyzing a jar, only analyze a init.class file when there isn't a corresponding source file, which makes sense. But why write to the cache etc directly and not just return a map of information like the other namespaces and then let clj-kondo do the writing at the very end