Fork me on GitHub

this type checking stuff is very interesting… especially for libraries to have them


are there some plans to have a “shared place” from where clj-kondo will discover type information?


like a database of “function sha -> type signatures”


I'm interested in a project wide lint: are all namespaces aliased consistently. I currently couldn't build this on the analysis cache (no alias information) and also kondo has no notion of project. Should I be going this alone, or is the scope of kondo open to change for these things?


@dominicm clj-kondo has analysis data export. Aliases can be added to that. Then it’s only a matter of only linting your project sources to discover consistency.


@tatut libraries could provide their annotations as config and clj-kondo could somehow pick up on this. One caveat: I haven’t fully figured out the right config format yet, so things might change


@dominicm feel free to create a PR or issue


@dominicm I was referring to this: The cache is an implementation detail that you should't really rely on as a user


ah, that makes more sense.


arch updated.


@borkdude opened a PR! That was super easy. Something really key was spotting that I could run the analysis in the repl (copied from some of the examples). I assumed I'd have to run the cli via deps.edn and inspect the resulting file.


Just curious, it would be pretty cool to run a linting pass by providing programs to clj-kondo to run. Maybe sci programs? The output would be some data shape which clj-kondo would use to produce messages.


@dominicm Thanks. Can you move the :as down as an argument to assoc-some? That way it doesn't end up in the EDN if it's nil. Can you also update the tests so this will be tested?


About your idea: I'm not sure if I understand it.


Maybe it doesn't make sense. I was just thinking about the fact that to get my linter setup I have to figure out graalvm, I have to release binaries, etc. etc. It would be really cool if I could just upload a sci gist somewhere and have people attach it to their existing clj-kondo process.


@dominicm do you mean something like but as an API?


Feel free to sketch out a scenario/example, since it's still not entirely clear to me, but it sounds interesting already 😉


No. I mean that clj-kondo would use sci to generate additional lint warnings. e.g. the missing docstrings example in the analysis folder. So you perhaps would stick some files in .clj-kondo/linters/*.sci, and clj-kondo would execute them each with the analysis available (maybe bound to*analysis*) and the result of the program would be data like:

[{:line 10 :column 20 :message "missing docstring" :type :warning}]
Which clj-kondo would then format into messages and append to the messages output.


ah like hooks


Kinda, yeah. Although hooks usually imply several points at which you might "override" a behavior (e.g. pre-analysis, pre-parse, etc.). This is essentially a way to provide custom linters to clj-kondo.


ah, so instead of writing your own program on top of the analysis, clj-kondo will use sci snippets to emit extra warnings. yeah, that could work


Yeah. Exactly. The intention being that it's quite a high barrier if you just want to add one or 2 little linters on top of clj-kondo.


It's a cool idea. I would say store this idea in a Github issue so we can chew a little bit on it


I don't know what the performance impact of emitting the analysis output is. For this feature it would have to be always on. Maybe it's neglectible and it would be ok.


Also when you edit only one file, the sci program would only see the analysis for that one file.


And for most analyses it's more interesting to see the output of the entire project/source dir


Also executing sci programs could potentially slow down the linter


This can be easily tested by writing some babashka scripts (which uses sci) on top of some analysis


At least people already have a way of making their own linters (like you wanted with the aliases) and they can run it in CI every so often


Yeah. It's cool that it's an option 🙂 Don't get me wrong. But I know that I have to get people to set it up in their tooling, and write emacs/vscode/etc plugins. It's a lot of work!


RE emitting the analysis, do you mean to disk, or to memory? The sci scripts would only need to operate on the in-memory analysis.


Also. Isn't the analysis cache available, which would serialize data from other namespaces and make it available to the sci script?


emitting in memory so it will be printed by clj-kondo


The cache is consulted only specifically when you are requiring namespaces that clj-kondo wants to know something about. It's very expensive (like 1 second, depending on how many libs you have cached in there) to read all of the cache into memory, I put effort into this to make it as fast as possible by only loading the necessary data.


That's why I think most analyses are better off as a custom tool outside of clj-kondo probably


And if these analyses are very useful, they can eventually end up as a built-in linter


Last chance to get your company logo in this sheet for ClojuTRE:


We do use it on some client projects. If that's enough to make the list, feel free to include us :)


yeah, only one person is enough 😉


Made a small tweak to your PR


@dominicm One other idea would be (since you mentioned the REPL use) is to run that analysis in the tests of your project and throw/print a warning when people use different aliases. Tests are ran by developers locally right? 😉


What's a test?

trollface 4

Sorry, I was joking :)


ha...ha... 😉




Yeah. Could fail a test. That tends not to be set up quite in the same way as tests are though.


You could make the test just emit warnings. And using it as a test, you could keep clj-kondo outside the normal deps.


Emit warnings and hang for 5 seconds. That's a strategy I recently read when someone deprecated something 😉


PSA: clj-kondo has an invalid type for the third param of partition. This can be worked around as follows: Will be fixed in the next release.


@marc-omorain did kondo find a "missing test assertion", or what was going on there?


there’s a definite line between us making kondo look good and kondo making us look like amateurs 😞


I made kondo because I didn't want to look like an amateur when checking in inline defs, so welcome 😛


oh wow, the filename and the namespace declaration didn’t match


ah, that makes sense. that could probably be a linting rule


did it have to do with underscores?


at a guess i’d say the file was renamed at some point and the namespace had the old name - and because it was a test file, it was only ever implicitly loaded


right, leiningen didn't complain while loading the file?