Yes, you can. See https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#refer-all

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

no

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,

#_clj-kondo{:ignore-function}
(defn foo [] (prom/mlet [...stuff]))

we are using this https://github.com/kumarshantanu/promenade 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?

Then you can disable those here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#unresolved-symbol

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

👍

You can write a macro-expansion hook for this

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

https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md#macroexpand

reading now!

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

?

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

@U017QJZ9M7W have you read https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration?

Here’s an example of clj-kondo exports for rewrite-clj https://github.com/clj-commons/rewrite-clj/blob/main/resources/clj-kondo.exports/rewrite-clj/rewrite-clj/config.edn

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

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

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

@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

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

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

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

the UX thing I am trying to avoid is

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

(I get why there is a divergence here!)

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

run (ns-analysis 'sicmutils.foo) 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

do that inside the macroexpand hook?

and you can use that in your macroexpansion yes

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

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