Clojurians Log v2

@didibus I just had another idea. Maybe clj-kondo can be equipped with a small nREPL client to double-check if some vars really don't exist, instead of a runtime plugin which you have to run yourself. Haha, wild idea.

Hum, could it be made into a middleware maybe?

I have to say all the runtime things start to confuse me lol. Especially, I get confused how different it becomes then to what Cider does with nRepl already

Yeah. Or maybe nREPL isn't such a good idea since it excludes other tooling like socket REPLs, so maybe it should be its own thing that clj-kondo can talk with. Just a one time data dump that you run every once in a while is easier

And possibly this can work for CLJS as well

Hum. Well I was thinking. If say you had it as just a command: clj-kondo --runtime-analyze or something like that. Then I was wondering, could the editor, like in Anakondo, I could have an editor command that runs it on your project. And I could run it on your project the first time you open it up as well. Something like that. So maybe you don't need to "connect" to a REPL, maybe it could be something the editors integrate with.

In fact, could be an option to the analyzer, so it analyzes but also loads all ns, evals all top level forms, and returns the analysis from that, as well as populate the cache.

That way the analysis would also be able to list those vars that are created by the macros, and it could use it to auto-complete them and all.

To load "all ns" you need to have a classpath. clj-kondo doesn't have a notion of classpath, it just takes what you feed it to --lint

clj-kondo would have to invoke a JVM and/or the CLJS analyzer in the JVM

Ya, but the editor has a notion of classpath, so I could pass it to clj-kondo.

That is right, you would get all the vars created by macros, that is the idea.

This might work better with the non native clj-kondo I guess. Would be easier as an alias, then it get the project classpath easilly.

yeah, I think a JVM "co-pilot" program would make more sense than letting the clj-kondo binary do this

Ok, I see what you mean, ya it might be a seperate tool then I get it now.

I think it should be a program similar to https://github.com/clj-kondo/inspector, or maybe it can all live inside that project

If I think of a nice workflow for it, like personally. I'd have it as part of my build. Like I have a step that compiles my code to see if there is any compile errors, then runs my tests, runs kibit, runs eastwood, runs clj-kondo. I can easily add that tool to this. The nice thing is, I naturally only run this when I know its going to compile, or when I'm about to commit or something like that.

Yeah, and you can even commit the output of this to source control, like additional "config". https://github.com/clj-kondo/inspector/issues/5.

I want it to be useful for editor integration myself, I'm using clj-kondo more during development than in CI

Ya, its the ergonomics I'm trying to imagine. If its too REPLy, well, I mean, people already used to Repls and Cider will have no issue. But the aspect of clj-kondo of like: it just works even if I'm a beginner, would be a bit lost to this.

yeah, that's why I was thinking, if clj-kondo could peek into a running REPL, this would not require you to run this tool

and I could easily bake in some thin nREPL ops into kondo

I'm just wondering, in the REPL, how would you distinguish between a var that ther user defined in the REPL only, and is actually missing from the source code (even in the sense that the code to def it isn't there).

I would use the runtime output only as a second opinion to prevent false positives

e.g. (defvars x y z). x is unresolved, check runtime output, ooh, it's there, ok, ignore.

I guess its because I'm coming from the perspective of tools.namespace refresh. People will often like eval a defn and later delete it. So now if you peek in the REPL, you will see that it is there, but that's the bug they want to be warned against.

yeah, that's true, this is also where clj-kondo shines right now: it will tell you the var doesn't exist anymore .. hmm

Its like a battle between false positive and false negative 😛

yeppp

I'm almost convinced now by your argument that this isn't going to result in an improvement ;)

Personally, for this use case, I'd lean on false positive. Cause I would see, oh it says that var is missing? Oh but this is a special var being deffed by hugsql, ok let me just add it to the clj-kondo exclusion.

yeah

the new unresolved var linter saved my ass a couple of times already today

thanks for leading me through the issue by testing, it really helps to get feedback and not get stranded

I did the easy part 😛

Thank you for the hard work

no problem. this issue was at the top of the list for a while... I noticed I accidentally made the level :warning by default

instead of :error, but maybe that's a good choice for the initial release

I honestly feel clj-kondo is the game changer Clojure was missing. Like because we can interop with Java, almost all other Clojure libs are redundant, even if I like a good Clojure lib over Java interop, I can easily make without. But, the IntelliJ like instant fedback of squiggly lines like hey this isn't how the syntax works, or like dummy you have a typo, this is what I was missing most from Java and C# 😛

I don't think its possible to try clj-kondo, and then decide to go back to not using it haha

So thank you for making it!

Yeah, the initial inspiration was joker: it showed the potential

And then GraalVM native-image came along, rewrite-clj luckily worked the first time, and boom, the right combination

Its also neat how indirectly, you're leading the way for native compilation of Clojure as well

I also love sci and babashka haha 😂

Just showing my gratitude here. Alright, got to go. Ttyl

Thanks a lot, cya!