Fork me on GitHub
#clj-kondo
<
2022-06-22
>
borkdude08:06:52

New clj-kondo release. Check #announcements

🎉 2
ingesol10:06:37

I have a function schema like this:

{:malli/schema [:=> [:cat :some-type [:maybe :coordinates]] :some-other-type]}
When I generate clj-kondo config for it, it generates an {:op :keys} for it, which is not nilable. So when a caller passes explicit nil to it, it produces a linter warning. Is this expected? I could do [:or :coordinates :nil] , but that produces :any in clj-kondo, which is far less useful for linting.

borkdude10:06:32

This should probably be fixed in malli

ingesol10:06:46

I just realized myself 😉

robert-stuttaford10:06:21

M1 support yaaaaay

🎉 3
ingesol10:06:28

But how do you express a nilable map spec in clj-kondo?

borkdude10:06:30

@ingesol good question, I'm going to find out now

💯 1
borkdude10:06:29

@ingesol Maybe it's better if malli generated :nilable/map in this case, if there are no keys specified

borkdude10:06:59

We could also support {:op :keys :nilable true} or so

borkdude10:06:05

but that's not currently in there

ingesol10:06:21

@borkdude Having the :ops spec there is very useful when there are keys specified. So :nilable support would be nice. I also realize I should have inserted my actual spec for coordinates , which is something like [:map [[:x number?] [:y number?]]

borkdude10:06:52

ok, PR welcome

borkdude11:06:52

or at least an issue

👍 1
andrea.crotti12:06:37

I'd like to be able to show a warning when someone requires a certain library in the ns declaration. Is that something I should do with clj-kondo hooks or maybe there are even easier ways? I mean potentially even grepping could work in this particular case, but that's not really a great idea in general, would rather at least parse the code properly and grep.

andrea.crotti12:06:31

hehe that's great timing

andrea.crotti12:06:20

I'll try it then, incredible turnaround, getting features even before you ask for them

😆 3
plins12:06:15

I have a fn that is being used only by tests (but no production code is using it) is there a way of clj-kondo to hint me about these?

delaguardo12:06:29

:discouraged-var in combination with :config-in-ns should work. You might also need to declare :ns-group to separate test namespaces from production

Joshua Suskalo15:06:43

Is there a particular reason you couldn't put this var into a test utility namespace? There's no reason that you can't have non-test vars (or even namespaces with no tests) in your tests directory.

plins20:06:37

its production code, but no one is using it yet, and I want the linter to say to me “Hey you have an unused function” this is not happening because the tests are currently using this function

Joshua Suskalo20:06:21

Ah I see, that's the opposite of the problem we thought it was.

Joshua Suskalo20:06:46

You can do this by just not including your tests on the path while you lint. I'm not 100% sure how you ensure that in kondo though.

plins20:06:13

I still want to lint the tests (so maybe this is a tricky one)

Joshua Suskalo20:06:13

Right, the point here would be to basically run the linter twice, once on the source directory, and once on the test directory. When running it on the tests you need the source to be on the path, and when you run it on the source directory you need the tests to not be on the path.

Joshua Suskalo20:06:20

I don't know if there's a convenient way to do this at the moment however.

borkdude19:06:11

Can you re-state the problem? > I have a fn that is being used only by tests (but no production code is using it) > > is there a way of clj-kondo to hint me about these? It isn't at all clear to me what the problem is. What should clj-kondo hint?

Joshua Suskalo19:06:25

This I think is actually about the clojure-lsp lint of unused public vars (@UKFSJSM38), but the problem is that vars should still be considered unused if they are used in tests.

borkdude19:06:22

yeah, this is a clojure-lsp feature

ericdallo19:06:17

the issue is: how clojure-lsp know that usage is from a test and not a different source-path?

Joshua Suskalo19:06:17

I think it'd just be a config option for that lint that specifies ignored directories

ericdallo19:06:55

sounds like a valid setting