Fork me on GitHub
#clj-kondo
<
2022-03-23
>
Charlie Briggs11:03:44

I was wondering if I'm doing something funny to get this issue when using the claypoole config from clj-kondo/config: https://github.com/clj-kondo/config/issues/13 It's causing issues with using claypoole, which we use frequently - any references within the cp bodies are reported as unused

AJ Jaro21:03:09

We have a mono-repo with a few projects within it. When I have the File Watcher IntelliJ plugin configured to run clj-kondo on a sub-project it won’t pick up the parent config if there is a .clj-kondo directory that exists in the sub-project. Here’s an example structure. If I edit a file within the projects folder I would expect that the parent config.edn is picked up, but it doesn’t seem to work that way

.
| 
 -- .clj-kondo
   |
    -- config.edn
|
 -- projects
   |
    -- .clj-kondo
      |
       -- metosin
...

borkdude21:03:31

It does not work that way. clj-kondo does not merge configs from parent directories, but you can refer to a shared configuration using :config-paths.

AJ Jaro21:03:12

ok, thanks. A config.edn doesn’t exist in the projects folder, so there (theoretically) should be nothing to merge

borkdude21:03:39

The closest .clj-kondo directory to the file you are editing is the one that gets picked up.

👍 1
borkdude21:03:49

If you want to include config from some other place, you should use :config-paths

AJ Jaro21:03:08

gotcha, fair enough

AJ Jaro21:03:42

That directory gets automatically created by “some process” (🤷 ) and I suppose I can just add a config file pointing to the proper place

borkdude21:03:28

clj-kondo doesn't automatically create a .clj-kondo directory, but some kind of editor tooling might be doing that

borkdude21:03:14

usually when you have a deps.edn or project.clj and you open that directory as a project in an editor, then clojure-lsp or so might be creating a .clj-kondo to store analysis information there

borkdude21:03:20

or #clj-extras-plugin

borkdude21:03:57

as it assumes that that is the root of the project

borkdude21:03:59

in general, there should be only one .clj-kondo directory per project. if you have a mono-repo then there should be one .clj-kondo directory for each project in that repo

borkdude22:03:23

and you can have a shared configuration for all of these projects, adding that happens through :config-paths

AJ Jaro22:03:59

Gotcha, that helps. Thank you. It could be clojure extras, who knows. but the config paths is the right way forward for us I think

jacob.maine23:03:08

At startup clojure-lsp calculates the classpath and if anything has changed, asks clj-kondo to analyze the entire classpath. Most files on the classpath will be unchanged, meaning a lot of extra work is done. We were just brainstorming ways to make that faster. One of the ideas would be for clj-kondo to keep a cache of its analysis. Has that idea ever been discussed?

jacob.maine23:03:17

Obviously it’s something we could do in clojure-lsp itself, but I thought I’d bring it up here in case it’d be useful for the larger clj-kondo community

ericdallo00:03:59

Example: if one of the paths, like /path/to/.m2/repository/org/codehaus/plexus/plexus-utils/3.4.1/plexus-utils-3.4.1.jar passed to kondo was already linted before by clj-kondo, there is no need IMO to re-lint, clj-kondo could cache the output analysis of that, right?

borkdude06:03:09

You should cache analysis yourself as the things you want to cache are different per application. Clj-kondo has its own cache specifically optimized for its own linting

👌 1
borkdude06:03:52

Clj-kondo also skips the jar if it has linted it before already but not when config changes since it might affect any analysis of any lib

dpsutton23:03:46

here’s a weird one. Lovely to mark vars as unused with a prefix. _db. Should it lint if those vars are prefixed but are used?

👍 1
borkdude06:03:27

There's already a linter for that

👍 1