clj-kondo 2023-01-26 | Slack Archive

Hi everyone, I have a library and I wanna configure clj-kondo on library level so all library consumers will not need to add that configuration into their projects. What I do is ns-level config in library

{:clj-kondo/config '{:lint-as {...}}}

but when this library is used in another project, this config is ignored so I have to copy that into that project config.

borkdude19:01:50

Hey @U4BEW7F61 - that config only applies to the code being linted there. If you want to export configuration you can do that like this: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration

borkdude19:01:30

If you have a more concrete example of what your project / config looks like, that will help guide you further

fmnoise20:01:55

thanks @U04V15CAJ, documentation you mentioned completely covers my case

Sam Ritchie18:01:29

odd… in https://github.com/mentat-collective/Mafs.cljs, when I run

clj-kondo --lint src

I see

src/mafs/debug.cljs:6:22: warning: Unresolved var:
src/mafs/line.cljs:14:14: warning: Unresolved var:
src/mafs/plot.cljs:16:10: warning: Unresolved var:
linting took 40ms, errors: 0, warnings: 3

but when I run on the specific file:

clj-kondo --lint src/mafs/debug.cljs

I see

linting took 13ms, errors: 0, warnings: 0

borkdude19:01:47

maybe a hook issue?

borkdude19:01:45

yes, it seems so, if I pull the var reference outside of defcomponent it works:

m/Debug

(defcomponent TransformWidget
  (.-TransformWidget m/Debug))

borkdude19:01:09

so you likely have to restore some metadata on some node

👍 2

Sam Ritchie19:01:13

okay, I’ll check it out!

Noah Bogart18:01:46

Linter idea: in test/is, if the assertion is a list and the function is = and there are two entries and one of the entries is a data literal, make sure it's in the first position. aka (is (= 4 (+ 2 2)) "this is good") vs (is (= (+ 2 2) 4) "this is bad") . maybe allow customization in the linter to say whether to put the literal first or second?

borkdude20:01:17

Worth a shot :)

escherize20:01:45

It’s probably been brought up a bunch of times. But is there some concept of “fixing” certain linting mistakes? example: we have some discoruaged vars config like:

:discouraged-vars {my.thing/plus {:message "use our.new.thing/plus instead of my.thing/plus"}
...
}

It would be kinda cool to be able to put in, idk. A default value or even a rewrite-clj function/hook that could be run to “solve” certain linter issues. Is there somwehre I can learn more about this imaginary mechanism if it exists, and/or the reasons behind not offering it?

borkdude20:01:13

The fixing can be done by taking the linter output programmatically, taking those locations with you and then write some rewrite-clj code. The same approach is taken in e.g. carve and clojure-lsp

borkdude20:01:02

Another small example: https://github.com/babashka/babashka/blob/master/examples/normalize-keywords.clj

🙏 2

escherize21:01:14

Thanks, makes a lot of sense

borkdude21:01:16

And these scripts can be written in babashka and hooked up to your elisp whatever editor functions (or joyride)

escherize21:01:21

this would make a slick blog post

2023-01-26

Channels