This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-22
Channels
- # announcements (28)
- # babashka (77)
- # beginners (122)
- # calva (40)
- # circleci (3)
- # clj-kondo (47)
- # cljs-dev (9)
- # clojure (119)
- # clojure-australia (1)
- # clojure-europe (88)
- # clojure-nl (3)
- # clojure-uk (33)
- # code-reviews (64)
- # core-logic (37)
- # cursive (10)
- # datomic (13)
- # emacs (1)
- # fulcro (4)
- # graalvm (1)
- # graphql (5)
- # helix (4)
- # integrant (25)
- # jobs (1)
- # jobs-rus (1)
- # off-topic (3)
- # pathom (12)
- # random (1)
- # re-frame (48)
- # reagent (1)
- # remote-jobs (1)
- # reveal (1)
- # rewrite-clj (4)
- # ring (6)
- # ring-swagger (1)
- # shadow-cljs (21)
- # sql (8)
- # tools-deps (25)
- # vim (15)
- # xtdb (12)
@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.
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
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
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
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
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).
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
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.
thanks for leading me through the issue by testing, it really helps to get feedback and not get stranded
no problem. this issue was at the top of the list for a while... I noticed I accidentally made the level :warning by default
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
And then GraalVM native-image came along, rewrite-clj luckily worked the first time, and boom, the right combination