Fork me on GitHub
#clj-kondo
<
2021-09-07
>
Proctor20:09:16

Asking here, because as I understand it Clojure-LSP gets its diagnostics from clj-kondo… I get info level diagnostics of Unused public var on my deftests… Is there a config setting to exclude the deftest items from the unused public var check?

borkdude20:09:39

@steven.proctor This is documented over here: https://clojure-lsp.io/settings/#clojure-lspunused-public-var I think it would be reasonable if #lsp didn't flag tests as unused (cc @ericdallo)

borkdude20:09:04

@steven.proctor Your other issue (https://github.com/stevenproctor/cljs-ns-aliasing-troubleshooting) is still in my TODO list :) Is there a corresponding clj-kondo issue in Github for this? I kind of forgot the original problem statement

Proctor21:09:24

I don’t think I put a issue in.. I can create one if not

Proctor21:09:35

I will check

borkdude21:09:09

Please do. About the unused var: I think the LSP docs show that you can configure this using the :exclude-when-defined-by setting, hopefully clojure.test/deftest works there

Proctor21:09:38

looks to have done it… needed both cljs.test/deftest and clojure.test/deftest

Proctor21:09:48

also added the issue to clj-kondo

borkdude21:09:03

thanks a lot, I'll take a look when I find time, I marked it as high priority

ericdallo21:09:32

BTW clojure-lsp already excludes deftest from unused public vars:thinking_face:

borkdude21:09:26

Perhaps it's a similar issue he was having with respect to cljs.test vs clojure.test ?

borkdude21:09:46

you should probably add cljs.test/deftest as well

ericdallo21:09:04

Yeah, I just added right now :)

ericdallo21:09:46

it should be working on next clojure-lsp release @steven.proctor so you won't need to exclude manually via config

Proctor12:09:14

:thumbsup:

Proctor12:09:52

Yeah, we are in pretty heavy in Node Lambda land, so most things I have been touching are CLJS, but there is a slow attempt to move to CLJ on Java Lambdas (maybe Graaal?)

Proctor12:09:47

but clj-kondo and clojure-lsp have been fantastic… ♥️ ♥️ ♥️ ♥️

ericdallo12:09:03

Nice, thank you!

borkdude14:09:55

@steven.proctor If you need to do some ad hoc scripting with CLJS on Node.js, check out https://github.com/borkdude/nbb

Proctor14:09:06

I saw that… doubt we can move all our Lambdas from figwheel and shadow-cljs to nbb… 😉

borkdude14:09:21

That's not what it's for. For lambdas you probably want to have compiled fast CLJS if you want to maximize performance, this is just intended for scripting, perhaps things you put behind cron jobs etc

borkdude14:09:35

Although some people use babashka for lambda as well :)

Proctor14:09:54

yeah, most of the CLJS stuff I am hitting comes from working on things deployed to Lambdas at this point

Proctor14:09:39

When/if I hit small things that might need Node, definitely interested in nbb, if I can’t just uses babashka… ;)

borkdude14:09:07

yeah that's how it's intended to be used

vemv21:09:10

what's a good way to teach clj-kondo that (my/with-transaction tx ,,,) takes tx from the environment and rebinds it to a new value? i.e. it macroexpands to (let [~s (foo ~s)] ,,,) where s is an arbitrary symbol (unusual macro shape I know)

borkdude21:09:47

@vemv this macro shape is equivalent to cljs.test/async 😁

👀 2
vemv21:09:07

didn't do the trick sadly!

(fn [p]
  (sut/with-transaction p
    1))
will cause an unused-binding to be emitted for the first p

borkdude21:09:28

can you give an example of what goes wrong when linting it without configuration then?

borkdude21:09:21

I don't understand what is the problem if it takes an already existing binding

vemv22:09:25

Good suggestion, removing the macro entirely from .clj-kondo/config.edn gets rids of the warnings I don't think it was like that yesterday, maybe something changed in my WIP. Will create an issue if something persists, hope not thanks!

👍 2
vemv22:09:09

Another thing Checking out https://github.com/clj-kondo/clj-kondo/tree/master/analysis . Can clj-kondo be used to forbid the use of a macro? (which is different from using it for forbiding the use of a var, I guess... a macro "goes away" after being macroexpanded)

vemv22:09:11

This is implementable in Eastwood since a given AST node can be queried for all its "parent macros". It's how if-inside-macroexpansion-of is impl'd Simply curious about what's possible

borkdude22:09:59

clj-kondo always sees the macro usage as well, so these rules would apply to macros as well

vemv22:09:28

A possible nuance is that macro usages can be hidden behind other macros' expansions. And so on recursively So one could get false negatives? As long as one isn't doing arbitrary macroexpansions in clj-kondo We chatted briefly about the topic in this channel one day, the conclusion seemed to be that there's no generalized macroexpansion atm