Fork me on GitHub
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: 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


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


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

👍 1

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


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


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


or #clj-extras-plugin


as it assumes that that is the root of the project


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


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


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?


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


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?


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

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


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

There's already a linter for that

👍 1