Fork me on GitHub
#clj-kondo
<
2019-09-23
>
tatut05:09:07

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

tatut05:09:02

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

tatut05:09:11

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

dominicm05:09:55

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?

borkdude06:09:21

@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.

borkdude06:09:25

@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

borkdude06:09:08

@dominicm feel free to create a PR or issue

borkdude07:09:28

@dominicm I was referring to this: https://github.com/borkdude/clj-kondo/tree/master/analysis The cache is an implementation detail that you should't really rely on as a user

dominicm07:09:18

ah, that makes more sense.

dharrigan07:09:08

arch updated.

dominicm07:09:41

@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.

dominicm07:09:09

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.

borkdude08:09:02

@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?

borkdude08:09:31

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

dominicm08:09:37

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.

borkdude08:09:48

@dominicm do you mean something like https://clj-kondo.michielborkent.nl but as an API?

borkdude08:09:18

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

dominicm08:09:00

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}]
Which clj-kondo would then format into messages and append to the messages output.

borkdude08:09:24

ah like hooks

dominicm08:09:52

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.

borkdude08:09:55

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

dominicm08:09:25

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.

borkdude08:09:26

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

borkdude08:09:47

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.

borkdude08:09:28

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

borkdude08:09:45

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

borkdude08:09:03

Also executing sci programs could potentially slow down the linter

borkdude08:09:55

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

borkdude08:09:12

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

dominicm09:09:25

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!

dominicm09:09:59

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.

dominicm09:09:23

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

borkdude09:09:46

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

borkdude09:09:07

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.

borkdude09:09:55

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

borkdude09:09:18

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

borkdude09:09:38

Last chance to get your company logo in this sheet for ClojuTRE: https://twitter.com/borkdude/status/1176064888080351235

dominicm09:09:06

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

borkdude10:09:42

yeah, only one person is enough 😉

borkdude10:09:10

Made a small tweak to your PR

borkdude11:09:34

@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? 😉

dominicm11:09:17

What's a test?

trollface 4
dominicm11:09:18

Sorry, I was joking :)

borkdude11:09:13

ha...ha... 😉

borkdude11:09:43

clojure.test/deftest

dominicm11:09:50

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

borkdude11:09:49

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

borkdude11:09:08

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

borkdude14:09:07

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

borkdude14:09:11

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

glenjamin14:09:35

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

borkdude14:09:23

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

glenjamin14:09:25

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

borkdude14:09:15

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

borkdude14:09:26

did it have to do with underscores?

glenjamin14:09:17

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

borkdude14:09:27

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