This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-24
Channels
- # announcements (4)
- # asami (5)
- # babashka (20)
- # beginners (94)
- # bristol-clojurians (1)
- # calva (23)
- # cider (2)
- # clj-commons (3)
- # clj-kondo (43)
- # cljfx (2)
- # cljs-dev (13)
- # clojure (112)
- # clojure-dev (44)
- # clojure-europe (17)
- # clojure-nl (5)
- # clojure-poland (12)
- # clojure-spec (2)
- # clojure-uk (3)
- # clojurebridge (1)
- # clojurescript (92)
- # cursive (17)
- # data-science (8)
- # datahike (1)
- # datalevin (1)
- # datomic (3)
- # deps-new (7)
- # events (2)
- # fulcro (40)
- # graalvm (110)
- # holy-lambda (16)
- # introduce-yourself (1)
- # lsp (13)
- # malli (8)
- # missionary (12)
- # off-topic (10)
- # pathom (13)
- # polylith (10)
- # portal (28)
- # re-frame (37)
- # reitit (1)
- # releases (1)
- # shadow-cljs (30)
- # spacemacs (1)
- # tools-deps (9)
- # xtdb (10)
does clj-kondo respect type hints for non-primitives when linting function calls?
(defn ^DBObject find-one
"Returns a single DBObject from this collection matching the query."
([^DB db ^String coll ^Map ref]
(.findOne (.getCollection db (name coll))
(to-db-object ref))))
coll
here is type hinted as a String which doesn’t change anything about how the function actually works (due to the name
call), but if I write (mg/find-one db :example {})
, I get an error about find-one
requiring a stringif you hint it as a string, clj-kondo will think you will have to pass a string or nil there.
any way I can disable this?
i didn’t write the library, so I don’t know lol
you can override this with {:linters`{:type-mismatch {:namespaces {library {function {:arities {3 {:args [:any :any :any]}}}}}}}}`
cool, thank you.
the exact format is here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/types.md
In a hook, what’s the best way of adding clj-kondo suppression of certain lints (on the re-written code)? The re-written code defines some things that may not be used.
For clj-kondo integration with emacs, there are three possibilities - flycheck-clj-kondo, anakondo, and flymake-kondor. IS there are clear recommendation from the community as to which one is preferred?
@chris441 I'm using and maintaining flycheck-clj-kondo myself. But I'm also using clojure-lsp. If I wasn't maintaining clj-kondo myself, I might not be using flycheck-clj-kondo since clojure-lsp already packages clj-kondo.
But as I'm always on the latest master, I'm using flycheck-clj-kondo separately from clojure-lsp.
flymake is built in to emacs, so some people prefer that. especially if they’re using eglot
@chris441 check https://clojure-lsp.io/features/, clojure-lsp uses kondo under the hood
Right, so reading into those answers a bit perhaps using lsp-mode for emacs is also a recommended pathway. Especially since the point of this work is to enable a smoothr \flo
Then, is there a different setup you use if you are going to be configuring kondo hooks and such? Like I guess just running kondo from the command line?
but for seeing feedback in the editor from your hooks using clojure-lsp should be enough
@dpassen1 - I currently intermittently use flycheck-joker. But I want to integrate correct clj-kondo hooks into our stack which is kind of extensive so switching that portion of my system is the just not a big deal work-wise as compared to the actual work of going through each library and updating it so the various macros used to define the interfaces are correctly represented in clj-kondo.
kondo return the analysis for all other things like namespaces and requires, but I'd like a keyword analysis element for ::xt/
, even if is not correct, I'd like to know easily the namespace from that alias
this is useful to show to users completion items when they just ask for ::xt/
, to show all available :reg
keywords on that namespace.
Related issue: https://github.com/clojure-lsp/clojure-lsp/issues/649