This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-24
Channels
- # announcements (39)
- # aws (4)
- # babashka (18)
- # beginners (32)
- # biff (10)
- # calva (22)
- # clj-kondo (11)
- # clj-on-windows (2)
- # cljs-dev (20)
- # clojure (31)
- # clojure-europe (130)
- # clojure-norway (21)
- # clojure-spec (24)
- # clojure-uk (17)
- # clojured (2)
- # clojurescript (6)
- # conjure (1)
- # core-async (5)
- # cursive (11)
- # datalevin (1)
- # datomic (9)
- # emacs (24)
- # figwheel-main (42)
- # fulcro (6)
- # gratitude (6)
- # honeysql (8)
- # juxt (16)
- # kaocha (6)
- # lsp (235)
- # malli (2)
- # nbb (7)
- # off-topic (23)
- # other-languages (24)
- # pedestal (7)
- # reitit (6)
- # sci (1)
- # shadow-cljs (21)
- # tools-build (22)
- # tools-deps (57)
- # vim (24)
Hi, I’m getting this error in one of my projects at the top of every file on the ns
form and I’m not sure why:
Can't parse /path/to/file.clj Configuration error. Expected fully qualified symbol, got: defn (lsp)
It looks like this is coming from clj-kondo? I’m not sure what the error message is supposed to mean in this context.Yes, the error could be in that lint-as config: no fully qualified symbols give an error
The CI config for one of our projects lints the entire classpath, before then going on to lint the src
and test
directories.
It's also trying to save/restore the cache that linting the classpath generates, presumably to decrease run time.
I've observed that:
1) the presence of a cache in .clj-kondo/.cache
makes no difference to the run time of lein clj-kondo --lint "$(lein classpath)" --dependencies --parallel --copy-configs
. So restoring the previous .clj-kondo/.cache
seems to provide no benefit.
2) the presence of the cache makes no noticeable difference to running lein clj-kondo --lint src
So the net effect is that our CI job spends twice as long linting than it maybe needs to.
Before I remove the part that lints the whole classpath and saves/restores .clj-kondo/.cache
I'd like to check my assumptions.
Should the presence of a pre-populated .clj-kondo/.cache
noticeably change the run time when you are linting a project in CI?
--dependencies
is faster if you have a previous cache with jar files linted. clj-kondo will tell you that it will be faster since it prints: skipping jar such and so, because I've seen it before
borkdude@m1 ~/dev/clj-kondo (master) $ clj-kondo --lint $(clojure -Spath) --dependencies
borkdude@m1 ~/dev/clj-kondo (master) $ clj-kondo --lint $(clojure -Spath) --dependencies
[clj-kondo] fs-0.1.2.jar was already linted, skipping
[clj-kondo] cheshire-5.11.0.jar was already linted, skipping
[clj-kondo] transit-clj-1.0.324.jar was already linted, skipping
[clj-kondo] datalog-parser-0.1.9.jar was already linted, skipping
[clj-kondo] bencode-1.1.0.jar was already linted, skipping
[clj-kondo] sci-0.3.2.jar was already linted, skipping
I'd say try it locally and observe the difference. There may be something off in the CI setup too
Thanks @U04V15CAJ
I spent more time prodding at CI to find out why the cache didn't seem to be having an effect. Your comment about config.edn
was spot on.
We're using CircleCI's caching for the clj-kondo
cache, based on the checksum of our project.clj
.
What happened was a deletion from project.clj
reverted it to a former state, which then led the cache restoration to restore a clj-kondo
cache taken before a change to config.edn
.
And because CircleCI caches don't get overwritten, this older incompatible cache was constantly being used.
Basing the cache off the checksum off both project.clj
and config.edn
does the right thing.