Fork me on GitHub
#clj-kondo
<
2021-10-15
>
fmnoise17:10:45

Hi, does anyone uses https://github.com/cerner/clara-rules here? Any suggestion how to properly lint defrule and defquery?

fmnoise17:10:51

I use lint-as defn atm, but it doesn't solve it all

borkdude17:10:01

Without writing a more sophisticated solution using hooks, you can probably get away with {:lint-as {clara.rules/defsomething clj-kondo.lint-as/catch-all}}

fmnoise17:10:54

thank you @borkdude 🙌

🙌 1
simonkatz16:01:40

Very late to this, but for anyone searching and finding this old thread, I think that should be clj-kondo.lint-as/def-catch-all 🙂

🙌 2
seancorfield19:10:07

Perhaps my only feedback would be to try to persuade you to make this on by default since it catches beginners out and it doesn't hurt to have (:gen-class) in ns even when you are not AOT'ing and you are using clojure -M -m

borkdude19:10:59

Ah, it won't gen a class when you won't compile right? (EDIT: I meant a .class file on disk)

seancorfield19:10:48

It will cause -main to get compiled to static void main(String[]) but that's pretty harmless given that the ns itself will get compiled to a class anyway.

borkdude19:10:54

Right, but not on disk I guess, only when you AOT (that's what I meant with compile, as in compile , that was ambigious)

borkdude20:10:44

And perhaps there's some CIs that will break because of a false positive, that's why I'm leaning to disabled by default now

seancorfield20:10:04

If you use compile, the ns will get compiled to disk -- regardless of the :gen-class -- the only difference is what is done with -main.

borkdude20:10:41

yes, that's my understanding too.

seancorfield20:10:24

All of the *new tools generate projects that have :gen-class in the ns that has -main in it.

seancorfield20:10:05

It is far more unusual to not have :gen-class in an ns with -main -- and when someone does that, they can opt out of the linter.

borkdude20:10:34

Well, bb scripts do have that :-) (although there :gen-class is a no-op)

borkdude20:10:00

and CLJS but there gen-class doesn't make sense, that's already handled

seancorfield20:10:41

How much cljs has -main tho'? And couldn't you just not lint that one in cljs?

borkdude20:10:14

yes, that's already handled: in CLJS you won't get a warning.

borkdude20:10:16

I'll do a http://grep.app to see what's out there

borkdude20:10:38

I'm finding several examples, e.g. this one: https://github.com/metabase/metabase/tree/master/bin/build-drivers For now I'll leave it optional. I think it's better to not cause noise in projects that work perfectly fine without :gen-class and require people to change their code or configs to get a clean clj-kondo CI outcome.

borkdude20:10:30

btw you can enable it in your local home config and you'll get it for all your projects on your local machine

seancorfield20:10:24

@borkdude Has anything changed recently in project-based configuration of clj-kondo? I'm noticing quite a few of my project-level .clj-kondo/config.edn things are no longer working. Or maybe this is due to some LSP change?

seancorfield20:10:41

For example, I have

:missing-docstring {:level :warning}

  :single-key-in {:level :warning}

  :unsorted-required-namespaces {:level :error}}
and none of those linters seem to be in effect now. I have the .clj-kondo folder one level above my clojure folder where all my code lives (in subprojects).

seancorfield20:10:09

Ugh! Turns out, at some point a .clj-kondo folder got created in the clojure folder and it only had a cache in it -- no settings 😞

borkdude20:10:28

@seancorfield I see the issue. You should put this config in ~/.config/clj-kondo . Previously it probably just worked if you had no .clj-kondo directory in your projects and clj-kondo found that as the closest parent :)

seancorfield20:10:53

Well, these are project-specific settings, not personal settings.

borkdude21:10:40

Not sure why those .clj-kondo dirs were created: clj-kondo never does this automatically, but it might be something in #lsp (cc @ericdallo)

seancorfield21:10:57

There are a lot of :lint-as settings that are not relevant to any of my other projects -- and I want everyone on the team using clj-kondo to have the same settings/experience.

borkdude21:10:28

@seancorfield There might be a different solution for this. You can have a shared config and refer to that from each project.

repo/clj-kondo/config.edn
repo/project1/.clj-kondo/config.edn: {:config-paths ["../../clj-kondo"]}

seancorfield21:10:00

There's no Clojure elsewhere in the repo -- so I should probably just move it from the root down into the clojure folder, yes?

seancorfield21:10:35

(and there are no more-specific 'kondo configs lower down)

borkdude21:10:47

That might work too. But clojure-lsp might create a .clj-kondo directory automatically when it detects a project root by finding a deps.edn or so

borkdude21:10:25

This is necessary for it to work properly as it stores analysis data in the .cache directory when it uses clj-kondo for analyzing dependencies

👍 1
borkdude21:10:13

So it might be safer to use :config-paths for shared config between projects

seancorfield21:10:22

Yup, LSP is causing this. I moved the .clj-kondo folder and restarted VS Code and a top-level folder appeared (containing an exported config from test.chuck. I'll do the multiple config.edn dance, as you suggested. Thank you!

👍 1
borkdude21:10:04

@seancorfield By the same mechanism you can let other people profit from library configuration, if you add config.edn in clj-kondo.exports/your.org/your.lib on the classpath. Then after LSP is done, you will see .clj-kondo/your.org/your.lib with the config in it. All you have to do then it add it to :config-paths (`:config-paths ["http://your.org/your.lib"]`}.

borkdude21:10:34

We're keeping a list of examples here of libs that have already done this: https://github.com/clj-kondo/clj-kondo/issues/1383

seancorfield21:10:35

Yeah, I have a ticket open in Expectations to do that.

seancorfield21:10:21

I seem to recall that 'kondo has already special-cased some stuff for next.jdbc but I should probably set that config up in next.jdbc itself, right?

borkdude21:10:16

I'd be ok with leaving that in clj-kondo, but for future libs the config mechanism might be better to start with

borkdude21:10:06

I don't want to break anyone who is relying on built-in stuff

seancorfield21:10:10

Right, but I'm probably about to add a new macro that would need a 'kondo config so that one, at least, has to be exported from next.jdbc. So I might as well add all the other stuff, to be future-proof.

borkdude21:10:33

Cool, it certainly won't hurt to do so

seancorfield21:10:00

(only with-transaction is currently baked in for next.jdbc -- more is baked in for java.jdbc which is not likely to get updates)

borkdude21:10:15

Merged the gen-class linter to master, so when Eric bumps kondo in LSP it should be available soon in Calva. I'll probably release a new clj-kondo next week or so (but LSP typically uses the master version).

seancorfield21:10:04

In the LSP version I'm using (which is supposed to be "latest" according to VS Code), it has

"clj-kondo-version": "2021.09.25",

seancorfield21:10:30

LSP is

"server-version": "2021.09.30-15.28.01",
Does that sound right?

borkdude21:10:11

I think Calva auto-updates LSP nowadays too

seancorfield21:10:13

Yup. If you have the version set to latest Calva checks on every restart, and downloads a new version if available.