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 https://clj-kondo.michielborkent.nl 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 clj-kondo.foo/*analysis*) and the result of the program would be data like:

[{:line 10 :column 20 :message "missing docstring" :type :warning}]

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

Great 🙂

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

@dominicm Maybe juxt?

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

Sorry, I was joking :)

ha...ha... 😉