This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-07
Channels
- # announcements (1)
- # babashka (28)
- # beginners (212)
- # calva (13)
- # clara (3)
- # clj-kondo (39)
- # cljsrn (1)
- # clojure (16)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-nl (2)
- # clojure-spec (9)
- # clojure-uk (8)
- # clojurescript (66)
- # cloverage (3)
- # code-reviews (16)
- # cursive (12)
- # data-science (2)
- # datomic (118)
- # events (1)
- # garden (2)
- # improve-getting-started (1)
- # introduce-yourself (1)
- # jobs (4)
- # missionary (5)
- # numerical-computing (1)
- # off-topic (5)
- # pathom (3)
- # polylith (71)
- # re-frame (99)
- # reagent (17)
- # remote-jobs (5)
- # shadow-cljs (35)
- # tools-deps (5)
- # xtdb (4)
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 deftest
s… Is there a config setting to exclude the deftest
items from the unused public var check?
@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)
@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
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
https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/diagnostics.clj#L12-L14
but it's missing cljs.test/deftest
Perhaps it's a similar issue he was having with respect to cljs.test
vs clojure.test
?
it should be working on next clojure-lsp release @steven.proctor so you won't need to exclude manually via config
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?)
@steven.proctor If you need to do some ad hoc scripting with CLJS on Node.js, check out https://github.com/borkdude/nbb
I saw that… doubt we can move all our Lambdas from figwheel and shadow-cljs to nbb… 😉
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
yeah, most of the CLJS stuff I am hitting comes from working on things deployed to Lambdas at this point
When/if I hit small things that might need Node, definitely interested in nbb, if I can’t just uses babashka… ;)
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)
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
can you give an example of what goes wrong when linting it without configuration then?
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!
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)
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
I think that would just similar to this: https://github.com/clj-kondo/clj-kondo/issues/996
clj-kondo always sees the macro usage as well, so these rules would apply to macros as well
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