Can you try linting the dependency that you have on your classpath with clj-kondo? Could be a built-in vs what you have difference

Damn, I should have thought of that 😞. Yes I'll try that and let you know if it's a clj-kondo issue

No worries

Doesn't seem to be an emacs issue.

pavlos$ clojure -M:clj-kondo --fail-level error --lint src/lala.clj | grep error
...
src/lala.clj:5:1: error: clojure.test.check.generators/generate is called with 3 args but expects 1 or 2
linting took 81ms, errors: 1, warnings: 0

(ns lala
  (:require [clojure.spec.alpha :as s]
            [clojure.test.check.generators :as gen]))

(gen/generate (s/gen int?) 1 500)

pavlos$ clojure -M:clj-kondo --version                                             
clj-kondo v2022.10.05

The clj-kondo alias in deps.edn looks like this:

:clj-kondo {:replace-deps {clj-kondo/clj-kondo {:mvn/version "RELEASE"}}
                         :main-opts ["-m" "clj-kondo.main" ]}

Did you lint your dependencies?

@UEQPKG7HQ

clojure -M:clj-kondo --lint $(clojure -Spath) --dependencies

after that, try again

You're right, it works now... The instructions are very prominent in the clj-kondo docs as well, not sure how I missed it. However, I don't really understand why clj-kondo recognized the 1- and 2-arity signatures but needed a cache refresh for the 3-arity. I would understand it if the 3-arity was a recent addition but it was actually https://github.com/clojure/test.check/blame/b6a318af92e836f1f20960f38a5944168b88d60d/src/main/clojure/clojure/test/check/generators.cljc#L198.

Maybe you first linted with an old dependency from 6 years ago? I can't reproduce the issue locally :)

$ clj-kondo --lint - <<< '(ns lala
  (:require [clojure.spec.alpha :as s]
            [clojure.test.check.generators :as gen]))

(gen/generate (s/gen int?) 1 500)'
linting took 28ms, errors: 0, warnings: 0

Ah, yes. That's very likely, the project in question had some dependencies that were quite old and we upgraded them recently. Would it be possible for clj-kondo to check if the cache is outdated when it runs and warn the user if so?

how are you using clj-kondo, from your editor or command line?

Usually from emacs (during development) but every now and then I'll do a full sweep of the entire project as a maintenance task

and which editor?

and using which "plugin"?

emacs + flycheck (is that what you mean?)

and you're not using lsp right?

not for Clojure

ok. clj-kondo doesn't do anything to keep in sync with your dependencies automatically, but you can run:

clj-kondo --lint $(clojure -Spath) --dependencies --parallel

so any time you change your project / deps file, you can re-run this. clojure-lsp does this automatically for you

I see, that's good to know! I'll see if I can set up emacs to mimic that fire-and-forget behaviour, thanks for all the info 🙂

any time

We already have that as the :consistent-alias linter

I did see that one, but it requires user configuration. My thought was that including a default list with the aliases listed in the Clojure Style Guide would be helpful to make code bases more consistent. Not sure if putting a default list on :consistent-aliases or adding a whole new linter for it would be better.

We could add an option to :consistent-aliases that populates the idiomatic list from the community guide

:community-guide true

Having to use the spec alias for clojure.spec.alpha already puts me off though :P

That is a nice idea. I wonder if such a flag can be useful in other linters as well. > Having to use the spec alias for clojure.spec.alpha already puts me off though 😛 That straight up seems like a bug in the community guide :face_with_raised_eyebrow: How is that idiomatic when every bit of official documentation uses s? I guess this is a good argument to making the entries in the :community-guide option override-able with explicit configuration.

haha

I had to laugh a bit because of the story "someone suggests linter for community guide aliases" and then the conversation goes "how is that entry in the guide idiomatic!"

This turns clj-kondo configs into a voting mechanism.

I guess you could also do the community guide aliases as a clj-kondo library which is merged automatically when imported

I'll file an issue for the :community-guide/idiomatic aliases flag so it's on the radar. Seems like it could use some more thought.

> I guess you could also do the community guide aliases as a clj-kondo library which is merged automatically when imported I'm not sure what you mean by that..?

Same mechanism as hooks

Do you mean to create a new lib that would just export the community guide alias configuration for clj-kondo so that anyone that wants to use the list can do so by installing the lib?

yes

by adding the lib to your :deps

Interesting approach. I guess that would require no new work for clj-kondo but would require maintaining a separate library and users would need to understand the path and install the dep.

yes

Okay, @U04V15CAJ. Thanks for your consideration. I will log the ideas in the ticket.

but it would also not need a new release of clj-kondo to get these defaults

In the least it'll require some clj-kondo documentation to explain it, I think.

Sure

> That straight up seems like a bug in the community guide :face_with_raised_eyebrow: How is that idiomatic when every bit of official documentation uses s? Seems like an issue should also be opened with the style guide to get this fixed.

I think having a “community-guide true” flag would be nice. Extra dependencies are hard, especially when running clj-kondo as a standalone bin instead of a project dependency.

https://github.com/bbatsov/clojure-style-guide/issues/245

https://github.com/clj-kondo/clj-kondo/issues/1839

Looks like this is with

Downloading  to /tmp

Locally, I get no errors with

[sritchie@wintermute ~/code/clj/sicmutils (sritchie/tidying)]$ clj-kondo --version
clj-kondo v2022.03.04

Heya @U017QJZ9M7W this is a little bug that slipped into last release.

got it, no worries, glad to hear it’s something that’s on your radar!

It's already been fixed on master

I guess I could do a new release for just that :-s

https://github.com/clj-commons/rewrite-clj/blob/c0e9184a9b5566e7932cff4f3769a2c49e647f31/.clj-kondo/config.edn#L18. Easy peasy.

Since this is the only reported unknown require option in a week, I think I'll do a new release this weekend and leave the linter on

With an :exclude option which still has to be made

sounds good

@U017QJZ9M7W I just published a new version of clj-kondo to clojars, could you test with that?

sure, will do shortly