Fork me on GitHub
#clj-kondo
<
2021-10-22
>
Pratik09:10:49

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

Pratik09:10:50

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

borkdude09:10:25

you put foo there, not your test nss

Pratik09:10:50

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?

borkdude09:10:40

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

Pratik09:10:46

I was looking for something like this option

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

borkdude09:10:15

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

Pratik09:10:21

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

borkdude09:10:21

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

Pratik09:10:56

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

borkdude09:10:32

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.

Pratik09:10:17

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

borkdude09:10:33

cool yeah that would be best

Pratik09:10:44

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

borkdude09:10:54

I'm not sure what you mean by this

Pratik09:10:53

something like this,

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

Pratik09:10:24

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

Pratik09:10:07

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

borkdude09:10:00

ah I see. let me take a look at this

borkdude09:10:55

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

borkdude09:10:47

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

Pratik09:10:51

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

borkdude09:10:21

the problem is mostly unresolved symbols?

borkdude09:10:15

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

borkdude09:10:46

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

borkdude09:10:55

or as a user you can do this too

Pratik09:10:24

yes, disabling those works

Pratik09:10:27

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

borkdude09:10:11

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:

borkdude20:10:46

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

borkdude21:10:14

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

borkdude21:10:33

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

borkdude21:10:16

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
borkdude21:10:52

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

borkdude21:10:16

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

borkdude21:10:24

but this is specific for clj-kondo

borkdude21:10:54

check ns-analysis

borkdude21:10:28

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

borkdude21:10:41

then you won't rely on the caching mechanism

borkdude21:10:24

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

borkdude21:10:37

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

borkdude21:10:27

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

borkdude21:10:23

run (ns-analysis 'sicmutils.foo) and print what it returns

borkdude21:10:38

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

borkdude21:10:43

else it won't return anything useful

Sam Ritchie21:10:57

do that inside the macroexpand hook?

borkdude21:10:00

and you can use that in your macroexpansion yes

Sam Ritchie21:10:13

okay, cool, I will give that a try

borkdude21:10:42

For example when I have

(ns app.core)

(defn foo [])

borkdude21:10:56

and I stick this in my hook:

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

borkdude21:10:10

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

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

borkdude21:10:56

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!