Fork me on GitHub
#clj-kondo
<
2022-06-24
>
nixin7205:06:09

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.

borkdude06:06:55

Perhaps a configuration error in config.edn

borkdude06:06:43

Yes, the error could be in that lint-as config: no fully qualified symbols give an error

borkdude12:06:16

So maybe you could post your config, to see if that is the case?

borkdude12:06:26

And/or move your config to see if this causes the problem

gordon14:06:12

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?

borkdude12:06:05

--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

👍 1
borkdude12:06:58

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

borkdude12:06:14

but the condition is that the config.edn etc hasn't changed since last time

borkdude12:06:25

I'd say try it locally and observe the difference. There may be something off in the CI setup too

gordon14:06:22

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.

👍 1