Fork me on GitHub
#clj-kondo
<
2022-05-13
>
borkdude06:05:57

Can you try to put #_:clj-kondo/ignore in front of it?

pinkfrog06:05:38

I’d like to control it in ~/.config/clojure/clj-kond/config.edn

seancorfield06:05:37

The only place I would use "RELEASE" is in my dot-clojure file for dev tooling -- which clj-kondo isn't going to be checking generally (except when you're editing it -- but not when you're working on actual projects). Actual projects should never use RELEASE. As of Maven 3.5.2 it's deprecated and will likely stop being supported at some point.

seancorfield06:05:53

It breaks dependency caching in the CLI as well, another reason to avoid it.

borkdude07:05:34

And for the sporadic usage, you can use:

{:deps {foo/bar #_:clj-kondo/ignore {:mvn/version "RELEASE"}}}

pinkfrog14:05:08

> It breaks dependency caching in the CLI as well, another reason to avoid it. I haven’t tested it (and not sure how it is tested). But on the slightest possibility, will “RELEASE” make the path calculation slow, is this what breaks dependency caching in the CLI as well means?

borkdude14:05:18

It doesn't make it slow, as the text is just hashed and that is the cache key. But you won't ever get the newest RELEASE version unless you have a cache miss.

pinkfrog14:05:30

Ah. That defeats the purpose of release (to keep it updated)

borkdude14:05:05

Yes, unless you want to use -Sforce all the time

borkdude14:05:52

I made a command line tool which can quickly update a certain dependency to the newest, if that's interesting to you: https://github.com/babashka/neil It runs in milliseconds with babashka. There is also the excellent antq tool to update dependencies.

pinkfrog14:05:05

Thanks. I mainly use > There is also the excellent antq tool to update dependencies.

👍 1
seancorfield15:05:31

antq is awesome. We have a daily cron job to provide us a nice report each day of outdated deps in our monorepo. Mostly, we do patch updates as a matter of course every build cycle and often any minor updates too, at least with Clojure libs which are typically really good with backward compatibility... Java libs, not so much.

Noah Bogart20:05:04

would it be possible to expose the helper function arity-error in hooks? I discovered that when I use :analyze-call to rewrite a custom macro, clj-kondo stops checking arity on the call, so I wrote my own version of arity-error

borkdude20:05:27

Just calling reg-finding! with type :incorrect-arity does not work I guess? Do you have a github link to that function you want to get in?

borkdude20:05:23

We could also try to maintain the arity errors as seen pre-transformation

👍 1
1
borkdude20:05:31

That would maybe be a better thing to do

Noah Bogart20:05:22

I did not know that you could exclude the :msg in reg-finding! so that explains it lol

Noah Bogart20:05:06

actually, I made a mistake so that's not working as I thought. I can private message you the macro and the hook, if you want

borkdude20:05:31

I think reg-finding expects :message

Noah Bogart20:05:05

if i use :incorrect-arity but don't provide a :message, then the error just says error: with no message

Noah Bogart20:05:32

yeah, this isn't mean to be a bug report, just that if it's easier to expose arity-error, i would use it lol