This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-07
Channels
- # announcements (12)
- # aws (2)
- # beginners (233)
- # calva (68)
- # cider (23)
- # circleci (5)
- # clj-kondo (40)
- # cljsrn (4)
- # clojars (3)
- # clojure (200)
- # clojure-austin (1)
- # clojure-canada (1)
- # clojure-dev (16)
- # clojure-europe (1)
- # clojure-finland (1)
- # clojure-italy (4)
- # clojure-nl (16)
- # clojure-spec (3)
- # clojure-uk (102)
- # clojurescript (16)
- # cursive (14)
- # datomic (16)
- # figwheel-main (7)
- # graalvm (3)
- # hoplon (37)
- # jackdaw (23)
- # jobs-discuss (24)
- # joker (4)
- # kaocha (6)
- # keechma (64)
- # off-topic (66)
- # parinfer (1)
- # pedestal (7)
- # re-frame (7)
- # reagent (10)
- # reitit (45)
- # rewrite-clj (12)
- # shadow-cljs (1)
- # slack-help (8)
- # spacemacs (55)
- # sql (9)
- # tools-deps (9)
- # vim (7)
clj-kondo v2019.06.07-alpha! đ major new features: Clojure API, JSON/EDN output https://github.com/borkdude/clj-kondo/releases/tag/v2019.06.07-alpha
Ooohhhh somebody just pointed out clojure-toolbox on #clojure. Didnât know about that one yet, really awesome! @borkdude Are you adding clj-kondo there or do you want me to do it? đ
@stefan.van.den.oord Iâll give you the honors, thanks đ
I was just thinking about seeing this in a few places on a re-frame application, thought it might be worth detecting that it's unused & unnecessary: echo '(fn [[_ _]] 10)' | clj-kondo --lint -
@dominicm by convention, clj-kondo ignores symbols that start with _
for detecting unused args, so that would be a new type of linter: âunnecessary destructuringâ?
The argument which is performing destructuring is completely ignored, which is why I figured it would be unused args too, but sure :)
I guess you canât assume itâs completely unused, since destructuring fails on certain things and this may be used as a feature đ
also sometimes it serves as documentation like: a seqable of at least two elements are expected here
You mean that someone might be doing:
(try
(let [[_ _] :foo] true)
(catch Exception e
false))
?could be docs, yeah. I'm a little ambivalent on that, it's either: 1) A repeating pattern (like re-frame) and therefore the docs are elsewhere 2) unique to this fn, in which case you're ignoring the argument for no reason.
No warnings from clj-kondo on the two largest projects at work. A bunch of unused code deleted, thanks for that.
what if _
is in fact used somewhere, should it then also report _
that was marked as unused, but it is used? itâs like telling the linter: ignore this, but tell me when itâs not good to ignore, which doesnât feel right to me yetâŚ
My "purist" reaction is that it shouldn't be reported as unused, because it is! But I think use of _ arguments is usually a mistake.
the linter already doesnât report it as unused as of now, but if you do use it, should it report the contrary (I donât think so). but then [_ _]
would also not be reported because of this.
_
is telling the linter: I know Iâm not using this, but please donât report anything about it
a convention which isnât very clear yet among the community: how do you tell tooling to keep namespaces, although theyâre not used anywhere explicitly in the code.
some people have brought up attaching ^:keep
on a vector in which the ns name is wrapped: ^:keep [do-not.remove]
having it as an unwrapped to signal this could also work: (:require do-not.remove)
but there might be others that are accidentally also unwrapped. also that wouldnât work for java imports
I've thought that the declaration of having side effects (e.g. registering multimethods, launching rockets) should be at the (ns) level, not the the require level
maybe an ns can be required only for side effects in some namespaces, but for referring functions in another, so Iâm not sure about that
weâre talking side effects of loading specs, multimethods. side effects like launching missiles is probably not a good idea as a top-level form đ
this issue is not about documenting whether a namespace has side effects, but if youâre only loading it because of those
sometimes tools are automatically removed âunusedâ requires, and you want a way to prevent that
@borkdude emmm, I mean parsing the spec definition, but not using the spec. only handle the basic predicate like string?
, int?
, symbol?
and the regexp ops like s/*
, s/+
, etc.
by parsing the spec, it is possible to find the arity error and type error on literals.
@doglooksgood yeah, Iâve already considered that in one of the issues: https://github.com/borkdude/clj-kondo/issues/23