This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ai (35)
- # announcements (3)
- # babashka (16)
- # babashka-sci-dev (2)
- # beginners (37)
- # biff (16)
- # calva (5)
- # cider (2)
- # clj-commons (81)
- # clj-kondo (29)
- # cljfx (2)
- # cljs-dev (4)
- # clojars (4)
- # clojure (92)
- # clojure-europe (72)
- # clojure-losangeles (8)
- # clojure-nl (1)
- # clojure-norway (10)
- # clojure-uk (1)
- # clojurescript (20)
- # clojutre (2)
- # conjure (2)
- # data-science (18)
- # datomic (1)
- # emacs (10)
- # fulcro (49)
- # joyride (1)
- # kaocha (23)
- # leiningen (8)
- # lsp (14)
- # meander (5)
- # off-topic (93)
- # polylith (4)
- # re-frame (20)
- # reagent (9)
- # reitit (2)
- # remote-jobs (8)
- # sci (1)
- # shadow-cljs (21)
- # testing (3)
- # vim (27)
- # xtdb (35)
@borkdude I almost have a fix for #1758, but just one quick question. What is going on https://github.com/clj-kondo/clj-kondo/blob/master/src/clj_kondo/impl/overrides.clj#L49-L57? Why is it assoc'ing
cljs.core into both
[:cljc :defs cljs.core :clj ...] and
[:cljc :defs cljs.core :cljs ...] (both :cljs and :clj)?
@alex.sheluchin This has to do with some things being both functions and macros in CLJS
Okay, that makes sense. I can't seem to find any examples of how to get the :var-definition of something from clojure.core to compare it against the overrides in a test.
@borkdude I put the PR up for #1758.
I don't know if putting the overrides check right in
reg-var! is a great idea in terms of performance. The other options would be to get the overrides map higher up in the call chain and pass it down to
reg-var!, either in a new parameter, or attached to
@alex.sheluchin This is likely an effect of what your changes do to what's stored in the cache
@borkdude indeed, that was it. But the test also passes back in my branch after:
✔ ~/repos/clj-kondo [add-overrides-to-reg-var L|…3] $ rm -rf .clj-kondo/.cache/ ✔ ~/repos/clj-kondo [add-overrides-to-reg-var L|…3] $ clojure -M:test -v clj-kondo.analysis-test/analysis-test Ran 1 tests containing 37 assertions. 0 failures, 0 errors.
Yep, that's it. Okay, thanks for the tips. I gotta run for now but I'll fix it when I get back.
I'm seeing what looks like config caching when running clj-kondo. The behavior I'm seeing:
clj-kondo --lint src in directory I haven't run clj-kondo in before. No
.clj-kondo directory in pwd.
• see undefined vars from a dependency (due to symbols being generated at run-time)
• create a
.clj-kondo/config.edn file which includes
some-dependency/.clj-kondo/config.edn excludes those dynamically created vars
• clj-kondo in original directory no longer complains about the undefined vars.
rm -rf ./clj-kondo/ to try to reproduce the original undefined vars message
clj-kondo --lint src still no has no complaint about the original undefined vars
I know this has to be user error. I haven't been able to create a small repro case yet (and the actual code is internal so I don't feel comfortable sharing it here). Is there clj-kondo config possibly getting cached someplace else?
I do. I’ll delete that and try again. FWIW, both a coworker and I are seeing the same behavior. I hate asking for help with such vague details. I’ll see how else I can slice this into smaller pieces.
Okay. I think I found out what’s going on. The results are being returned in different orders, so what was apparently “missing” is actually just returned in a different location.
The last piece I need to track down (some other time) is why I’m not seeing a
:lint-as getting transitively pulled in from a referenced
clj-kondo/config.edn. Too many plates spinning right now to dig into that when I can patch it with a little duplication.