Fork me on GitHub
#clj-kondo
<
2023-02-01
>
markbastian15:02:12

Hey folks, is there a way to specify a specific linter config in the :config-in-ns block of the kondo config file? I have the following entry:

:config-in-ns
{printable-namespaces
 {:linters
  {:discouraged-var {:level :off}}}}
With the following discouraged vars
:discouraged-var
{clojure.core/println      {:message "Use clojure.tools.logging instead of clojure.core/println"}
 clojure.core/printf       {:message "Use clojure.tools.logging instead of clojure.core/printf"}
 clojure.string/lower-case {:message "Use metabase.util/lower-case-en instead of clojure.string/lower-case"}
 clojure.string/upper-case {:message "Use metabase.util/upper-case-en instead of clojure.string/upper-case"}
 toucan.db/query           {:message "Use mdb.query/query instead of toucan.db/query"}
 toucan.db/reducible-query {:message "Use mdb.query/reducible-query instead of toucan.db/reducible-query"}}
What I want to do is just disable certain of those discouraged vars. Something like this:
:config-in-ns
{printable-namespaces
 {:linters
  {:discouraged-var {clojure.core/println {:level :off}}}}}
I did try the above, but it doesn’t work. Is this possible? If so, how do I do it? Thanks!

borkdude15:02:29

What happens if you do :message nil instead of :level :off ?

borkdude15:02:46

or in addition to it

markbastian15:02:15

And still get the warnings on println

borkdude15:02:27

ok, then this linter doesn't work well with config-in-ns yet I think

borkdude15:02:36

feel free to post an issue. metabase right?

markbastian15:02:45

Will do, thanks!

dharrigan15:02:52

I hope we don't adopt the same with clj-kondo as our namesake as done? 🙂

😆 4
Noah Bogart15:02:16

we only need to worry when clj-kondo starts having children, I guess

😆 6
quoll15:02:15

I’m curious, I see clj-kondo used to report errors, but can it be used to update code? Or is that more for Joyride?

Noah Bogart15:02:34

I believe at this time any "automatically fix errors" functionality must come from outside clj-kondo

quoll15:02:48

That’s what I was thinking. Thank you

Noah Bogart15:02:58

no problemo. I also wish we had some "auto fix" functionality in clj-kondo, but i understand that it would be a dramatic increase in scope and require rewiring large portions of the app to support it

borkdude15:02:18

@U051N6TTC A lot of what clj-kondo reports can be fixed by clojure-lsp: those two projects are very much integrated

quoll15:02:22

I just had this idea around using common functions in other namespaces, and having the code automatically updated. Something like:

(let [lwr (lower-case a-string)]...)
And having the :require block updating to include [clojure.string :as string] and the code I’d just typed updating to:
(let [lwr (string/lower-case a-string)]...)
Or something like that anyway. Clj-kondo definitely feels like the way to identify these things

borkdude15:02:13

@U051N6TTC take a look at clojure-lsp: it supports a lot of IDE-like features, all based on the analysis done by clj-kondo

☝️ 2
borkdude15:02:22

renaming, navigation, etc

quoll15:02:23

Thank you

borkdude15:02:14

The default settings in lsp-mode are a bit too much, but asking in #CPABC1H61 for how to set it up with sane defaults might be good.

borkdude15:02:41

There is also eglot, which is slated to become the "official" lsp client in emacs

borkdude15:02:51

which is more minimal than lsp-mode

borkdude15:02:02

I'm very happy I waited with "fixing stuff" since clojure-lsp was the final puzzle piece which enables that and works in all major editors

😄 4
borkdude15:02:45

(except IntelliJ, but coming soon...?)

🤫 4
quoll15:02:47

heh @UKFSJSM38 this is actually the page I’ve pulled up and was going to work through when I get a little time 🙂

😅 2
pez16:02:58

For the record, and since it was brought up: #C03DPCLCV9N is for scripting VS Code. It could probably be used to utilize clj-kondo analysis for fixing lint problems, since it is for general scripting of your editor. But the solution would be VS Code only. (And clojure-lsp covers this base anyway.)

quoll18:02:19

Yes, I know it’s for VS Code. But everyone loves it so much, that I’m prepared to switch tools to gain the benefits

Daniel Jomphe13:02:12

Does clojure-lsp allow us, after being confronted with a lint warning, to "not only fix it in this occurrence, but also for all occurrences in this file" or even "in this project" like IntelliJ's inspections for e.g. Java?

ericdallo13:02:50

only for clean-ns ATM @U0514DPR7, removing unused requires and imports, sorting etc

Daniel Jomphe13:02:21

Thanks Eric. We're thinking about supporting not only VS Code, but also IntelliJ, if it means that such functionality would be available to our clojure codebase - haven't tried Cursive since 2016, though, to see if it's supported. But heck, at the speed at which all this tooling advances, who knows what VS Code will be able to do before we're ready to try IntelliJ again. (I miss IntelliJ every day I develop...)

ericdallo13:02:47

you can run that via CLI as well, on CI for example, then you don't need to worry about editors

Daniel Jomphe13:02:26

Hmm, you're right that it would be good for us to start putting our CI to more use!

borkdude13:02:29

> We're thinking about supporting not only VS Code, Who is supporting what?

Daniel Jomphe13:02:37

Speaking about my colleagues, who standardized our dev tools to VS Code for the past few years, even though some of us might prefer other IDEs. I'm the tool guy at our shop, who's tasked with helping the team use VS Code at its best, and might provide them with a second IDE config some day, when priorities allow.

👍 4
markbastian22:02:52

Is there a way to disable linter warnings in the hooks configured with the :hooks -> :analyze-call section of the kondo config.edn file? I’m trying to discourage clojure.core/print in my main code base, but some of the hooks expand with print usage. If I add #_:clj-kondo/ignore to the hooks themselves they don’t appear to be included in the expansion or that stage of analysis. Is there another way to add an ignore as metadata?

borkdude22:02:30

What do you mean by this one? > but some of the hooks expand with print usage.

markbastian22:02:12

Here are a couple examples: • https://github.com/metabase/metabase/blob/master/.clj-kondo/hooks/common.clj#L51https://github.com/metabase/metabase/blob/master/.clj-kondo/macros/metabase/test/util.clj#L4 IIUC, the linter will expand with-temp-env-var-value to that latter link as shown [here](https://github.com/metabase/metabase/blob/master/.clj-kondo/config.edn#L639). I’m trying to discourage print and variants via :discouraged-var but it picks up those items above. I’ve tried adding #_:clj-kondo/ignore as I mentioned in those locations above but that doesn’t seem to work. Basically I want to suppress the warnings from those locations.

borkdude22:02:15

Ah gotcha. You can check if a node is generated with api/generated-node? and if so, you can just ignore it

borkdude22:02:18

Oh, but the #_:clj-kondo/ignore doesn't work on the node that expands into the print, now I get it

borkdude22:02:38

Hmm, can you post an issue about this? I'll check later this week

markbastian22:02:45

Will do! Thanks!

markbastian22:02:22

That’s why I was hoping maybe there was/could be a metadata option that doesn’t get discarded.

borkdude22:02:35

if you want to always ignore the generated result, you could also choose to generate something else ;)

markbastian22:02:04

Yeah, thinking of that as an option as well. Maybe str.

borkdude22:02:35

ok, I'm going to log off for today, have a nice day

markbastian22:02:41

You, too. Thanks!

borkdude22:02:32

One option is also to introduce a special print function in your code-base like: metabase.utils/production-print which uses clojure.core/print for production usage and you ignore it only there, and all other clojure.core/print usages are forbidden

👍 2
borkdude19:02:52

@U0JUR9FPH Would you mind updating the issue with a full example, preferably something that can be cloned locally?

markbastian19:02:14

Yes, thanks for the reminder.

🙏 2
markbastian20:02:55

LMK if https://github.com/clj-kondo/clj-kondo/issues/1980#issuecomment-1423174419 works for you. You should be able to clone that branch and run kondo on the test dir to see the issue.