This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-16
Channels
- # announcements (11)
- # atom-editor (4)
- # babashka (26)
- # beginners (126)
- # calva (35)
- # chlorine-clover (14)
- # clj-kondo (50)
- # cljfx (1)
- # cljs-dev (1)
- # cljsrn (3)
- # clojure (31)
- # clojure-europe (144)
- # clojure-germany (2)
- # clojure-nl (3)
- # clojure-serbia (17)
- # clojure-spain (11)
- # clojure-uk (38)
- # clojurescript (87)
- # community-development (1)
- # conjure (1)
- # datalog (1)
- # datascript (160)
- # datomic (28)
- # duct (2)
- # emacs (4)
- # events (1)
- # figwheel-main (1)
- # fulcro (15)
- # graalvm (4)
- # honeysql (53)
- # jobs (2)
- # jobs-discuss (14)
- # juxt (6)
- # lsp (59)
- # malli (13)
- # music (1)
- # off-topic (8)
- # pathom (22)
- # portal (7)
- # re-frame (2)
- # reagent (3)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (1)
- # shadow-cljs (25)
- # sql (3)
- # tools-deps (38)
- # xtdb (17)
I'm having a problem with clj-kondo integration in emacs, where it sometimes does not lint functions defined in the project but only those defined in required libs. I'm not really certain about how to start debugging that - anybody got a hint maybe?
weird thing is, it works fine with fns defined in the same namespace, but not in those defined in other namespaces in the same project
if you can make a repro using a minimal project + command line examples, I can take a look. Hard to say anything without more details
Getting odd false warnings from clj-kondo
(ns witan.small-test
(:require [tablecloth.api :as tc]))
(defn add-series-name [ds series-name]
(if (contains? (set (tc/column-names ds)) :series-name)
ds
(tc/add-column ds :series-name series-name)))
If so, then you should either add a config for this custom macro, or add the tc namespace to :exclude in the unresolved-var linter
(defn add-column
"Add or update (modify) column under `column-name`.
`column` can be sequence of values or generator function (which gets `ds` as input)."
([ds column-name column] (add-column ds column-name column nil))
([ds column-name column size-strategy]
(let [process-fn (prepare-add-column-fn column-name column (or size-strategy :cycle))]
(if (grouped? ds)
(process-group-data ds process-fn)
(process-fn ds)))))
yeah, looks like normal defn (I know potemkin is used in other places, but it doesn't look like in this place)
If you have some same-named namespace somewhere else it could be that the definitions are overwritten
@otfrom rm -rf .clj-kondo/.cache should then solve it, but I assume clojure-lsp is linting your deps
the cache getting messed up over a number of updates sounds like a reasonable culprit until it happens again
clojure-lsp tries to lint all of your deps automatically. clj-kondo doesn't do this, unless you tell it to
also clojure-lsp using an incremental diff when you edit files, which might go wrong - there were some discussions about this in the lsp channel
you can try clj-kondo --lint $(clojure -Spath)
(assuming deps.edn) and see if you get the issue again
(ns witan.small-test
(:require [tablecloth.api :as tc]))
(defn col-wrapper [ds]
(tc/column-names ds))
ok, that's what I suspected. taking a look at that api ns: https://github.com/scicloj/tablecloth/blob/master/src/tablecloth/api.clj so these vars are all defined using some custom machinery. you must either configure clj-kondo to make it understand this machinery, or to ignore this
it looks an awful lot like potemkin/import-vars but not quite, so you cannot simply use :lint-as
for this
you can either write a hook, or use the workaround I suggested. this is expected behavior
thx. sorry for snitch tagging you on zulip, but I was wondering if someone else had already solved it
fwiw @lee has a nice way to generate the potemkin-like-code using a couple of functions instead of using a macro, this makes all the tooling understand it
more docs are here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md
Referenced in hooks.md, but https://github.com/lread/rewrite-cljc-playground/commit/09882e1244a8c12879ef8c1e6872724748e7914b when I needed it (I no longer do because I abandoned import-vars - too many headaches!).