Fork me on GitHub

can we exclude some type of warnings from all the test files? In our codebase, if we have foo.clj, in the foo_test.clj we are always importing foo with :refer :all and I want to stop the flagging for that


yes, but I have to manually put all the test files here and update it if I add a new test file, right?


you put foo there, not your test nss


then I have to do the same thing for all the source files, if I add a new source file, I’ll have to mention it in the config.edn, correct?


correct, but you can also just globally turn off this linter. I don't see why you would want to make an exception for tests, just use :refer or an alias


I was looking for something like this option

{:refer-all {:exclude :all-tests}}


I think :refer :all doesn't make tests more readable, but this is my personal opinion.


yes, it’s just that we are using it across all our codebase, but we might as well switch to aliasing rather than turning it off


are you using clj-kondo on the JVM for linting in CI? why is it a problem that these "legacy" issues appear?


ah, so my story is, we were previously using replace in our configs(mistakenly) which was only picking up like 5-6 of the configs, we recently turned it off and added a pre-commit hooks


Perhaps it's possible to make a .clj-kondo/config.edn in project/test and refer to your base config with :config-paths . I'm not entirely sure if this works correctly with clojure-lsp etc though.


this will add extra config file to maintain even if it works, I think we can switch to aliasing or turn off it globally


cool yeah that would be best


on a separate thing, is it possible to ignore the full functions from linter warnings?


I'm not sure what you mean by this


something like this,

(defn foo [] (prom/mlet [...stuff]))


we are using this library in some legacy parts of our codebase and I tried to ignore those warnings with :lint-as but couldn’t make it work


we only have countable functions written with this library where clj-kondo gives warnings, if we can disable some type of errors for the whole function then it will help my case


ah I see. let me take a look at this


why doesn't {:lint-as {promenade.core/mlet clojure.core/let}} work for you?


preferably libraries will include clj-kondo config and export it so everyone can use it instead of everyone ignoring it


hmm, there are other functions like either-as-> and if-mlet which I remember not working when linting as -> and if-let


the problem is mostly unresolved symbols?


with :exclude [(promenade.core/mlet)]


the author can also provide macroexpansion hooks for clj-kondo to make linting better


or as a user you can do this too


yes, disabling those works


not sure about macroexpansion hooks, I can probably create an issue on the repo


what you could do is try to figure those out yourself and then contribute, but this is obviously more work. for now, disabling is the workaround then

Sam Ritchie20:10:43

Hey all! quick question about some clj-kondo “errors” I’m seeing in a #sicmutils project; I have a bootstrap-repl! macro that expands to a require form, so I can do the equivalent of use for REPL interaction in both Clojurescript and Clojure. The problem is that clj-kondo doesn’t see these required forms, leading to:


You can write a macro-expansion hook for this

Sam Ritchie20:10:48

And yes, in a library or production codebase it would be quite poor style to reference vars this way. But this came up when using VSCode to work on a more interactive namespace that I am rendering using #nextjournal’s Clerk project

Sam Ritchie20:10:58

@U04V15CAJ if I am writing these for macros in a library, like in this case, is there a good way to share these

Sam Ritchie20:10:29

for example I have a bunch of macros in #sicmutils that DO work in SCI already

Sam Ritchie21:10:36

ie I have rewritten them already to work in the SCI context; it would be nice to not have to copy them again over to a config namespace


@U017QJZ9M7W let's focus on this bootstrap macro for now and not try to optimize everything at once


in general you can't run everything in clj-kondo like you can in SCI, clj-kondo isn't a normal Clojure runtime


so I expect you could share some macros but probably not all, like when you use resolve or ns-publics or whatever, you will have to make changes

Sam Ritchie21:10:18

@UE21H2HHD that’s awesome, that for sure answers how to bundle these config options with the sicmutils library.

👍 1

although we could try to support that use case, it's currently not supported

Sam Ritchie21:10:05

@U04V15CAJ yeah, this particular one does use ns-publics to go grab everything from the sicmutils.env namespace and make it available


we do have something else for that now

Sam Ritchie21:10:20

of course I could write something that just manually grabs everything on a library public


but this is specific for clj-kondo


check ns-analysis


but it's far more reliable if you can pre-generate all your public vars and just let your clj-kondo macro-expansion spit them out for example


then you won't rely on the caching mechanism


so, you could programmatically create your clj-kondo macroexpansion hook I mean


and update it when your library changes, using a script

Sam Ritchie21:10:08

it would work for published versions…. it would have to be a commit hook to be stable for git deps

Sam Ritchie21:10:24

so that any commit, at least to main, would have things up to date

Sam Ritchie21:10:40

the UX thing I am trying to avoid is

Sam Ritchie21:10:49

of course, where the editor can see a var but clj-kondo can’t

Sam Ritchie21:10:04

(I get why there is a divergence here!)


ok, you could try to use ns-analysis I guess


run (ns-analysis ' and print what it returns


this will assume that you have already got a cached version of that namespace


else it won't return anything useful

Sam Ritchie21:10:57

do that inside the macroexpand hook?


and you can use that in your macroexpansion yes

Sam Ritchie21:10:13

okay, cool, I will give that a try


For example when I have

(ns app.core)

(defn foo [])


and I stick this in my hook:

(prn (api/ns-analysis 'app.core))


and then lint a file, I will see this in my console:

{:clj {foo {:ns app.core, :name foo, :fixed-arities #{0}}}}


of course you should not print in your expansion "in production", I was just trying to tell you how you could inspect the contents of this stuff

Sam Ritchie21:10:52

just saw this extra stuff, this is great. Thank you again!