This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-27
Channels
- # aleph (1)
- # announcements (39)
- # aws (11)
- # beginners (58)
- # calva (10)
- # cider (7)
- # clj-kondo (65)
- # cljs-dev (5)
- # clojure (90)
- # clojure-dev (48)
- # clojure-europe (23)
- # clojure-madison (1)
- # clojure-norway (1)
- # clojure-uk (40)
- # clojured (11)
- # clojurescript (20)
- # conjure (12)
- # core-async (4)
- # core-logic (4)
- # cursive (3)
- # datalevin (1)
- # emacs (7)
- # events (2)
- # fulcro (48)
- # introduce-yourself (2)
- # lsp (36)
- # malli (11)
- # missionary (1)
- # off-topic (1)
- # other-languages (72)
- # pathom (4)
- # polylith (13)
- # portal (94)
- # re-frame (14)
- # react (5)
- # releases (1)
- # sci (12)
- # shadow-cljs (29)
- # spacemacs (3)
- # vim (4)
- # xtdb (12)
It takes 713ms (measured by criterium
) to analyze (and lint) src/clj_kondo/impl/analyzer.clj
itself, with a more-or-less default config. With var-usages
disabled, it takes 550ms. It takes 2740ms to analyze all of src/clj_kondo/
, and 1955ms with var-usages
disabled. That’s 23% and 29% faster, respectively, a modest but somewhat surprising amount. I didn’t expect it to change that much since it’s still doing all the work to find var-usages, just skipping the call to reg-var-usage!
.
Skipping analysis of def(n) bodies is a more dramatic improvement. 107ms for analyzer.clj
and 514ms for src/clj_kondo/
, 85% and 81% faster than baseline.
I didn’t go to the trouble of turning off any of the linters, though many of them don’t make sense if you don’t analyze var-usages. In quick tests, turning off linters reduces the size of the :findings, but doesn’t decrease overall time much.
@U07M2C8TT That's quite significant. Let's talk in #clj-kondo-dev for further details
Is there a way to make kondo use namespace aliases as the key for sorting the requires?
So for example
(ns mynamespace
(:require
[cljs-http.client :as http]
[com.fulcrologic.fulcro.dom :as fulcro.dom]
))
is how kondo would like them to be, since cljs-http comes before com. But in longer lists that makes it harder to see where the alias is coming from, have to use search.
So the option would be to have it sorted by the alias; fulcro before http.The reason this isn't supported is that tooling like clj-refactor and clojure-lsp do not respect custom sorting rules
I’m seeing cljs.core/clj->js is called with 3 args but expects 1 [invalid arity]
in emacs. I tried to reproduce this with clj-kondo from the command line and cannot reproduce though.
❯ echo "(clj->js [1 2] :keyword-fn name)" | clj-kondo --lang cljs --lint -
linting took 115ms, errors: 0, warnings: 0
I’m confused about this discrepancy as i don’t think clojure-lsp would falsely say this because it relies on clj-kondo’s analysis?interesting!
metabase on master [$?] via :coffee: v17.30 on :cloud: metabase-query
❯ echo "(clj->js [1 2] :keyword-fn name)" | clj-kondo --lang cljs --lint -
<stdin>:1:1: error: cljs.core/clj->js is called with 3 args but expects 1
linting took 175ms, errors: 1, warnings: 0
yes, that matters, if there is some other version of clojurescript in your dependencies, then it may have picked up on that
we don’t declare a version of clojurescript. we run shadow-cljs from the command line which brings in its own version
It seems the arity was changed 5 years ago: https://github.com/clojure/clojurescript/commit/e3a9f0cd8511dcfe0c80f37834b5aa32c7b058d4
it could be that clojurescript is being brought in via one of your dependencies, an ancient one
we have lots of exclusions in deps.edn. and nothing brings it in. the version depends on the ambient shadow-cljs
used
if it comes back, my only logical explanation would be that there is an ancient CLJS version on your lsp classpath somewhere
yes. its just the metabase repo. It was reporting the errors from hsql. not sure how that state got there
yeah. i can’t recreate it after deleting the cache. sometimes it is aware of honeysql and complains about some macros from there
I already say this behavior, but never managed to reproduce, it's pretty rare and usually happens on complex projects, but I have a guess it's related to kondo cache, erasing LSP cache just make we re-scan everything which makes clj-kondo repopulate cache, next time, we can try removing kondo cache first
That's interesting. I've never heard of deftest-
but you can solve it with:
{:lint-as {clojure.test/deftest-i clojure.test/deftest}}
Opened this feature request issue: https://github.com/clj-kondo/clj-kondo/issues/1671. As I said in it, I would be willing to write the lint.
This has never happened to me before, but probably because I don't use a lot of pre/post :)
It’s never happened to me either but I've now found it in 3 places in my job's codebase so it seemed worthwhile to add
That’s a great point. If you're interested I'm willing to write it up, but no worries if you're not
so I'm reluctant to support this linter as it doesn't seem that important to me and it could possibly lead to false positives
I reacted on the issue. I don't think this is important enough to justify the effort
if you really still want to find duplicates in your code, you can use grasp. I'll give a link later today
Will do! I like writing these things so if others end up wanting it, I’ll still be willing to do it