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

Feedback on this one welcome: https://twitter.com/borkdude/status/1449092017573842946

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

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

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.

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

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

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.

yes, that's my understanding too.

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

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.

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

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

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

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

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

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.

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

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

For example, I have

:missing-docstring {:level :warning}

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

  :unsorted-required-namespaces {:level :error}}

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 😞

@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 :)

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

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

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.

@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"]}

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

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

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

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

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

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!

@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"]`}.

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

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

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?

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

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

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.

Cool, it certainly won't hurt to do so

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

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

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",

LSP is

"server-version": "2021.09.30-15.28.01",

Seems right: https://github.com/clojure-lsp/clojure-lsp/releases

I think Calva auto-updates LSP nowadays too

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