Using GitlabCI, my lint job fails once in a while (not very often at all):

$ clj-kondo --parallel --lint src test
test/salus/server/fixtures/citizen.clj:66:29: error: Attempting to call unbound fn: #'hooks.salus.server/with-serializable-txn

@adam678 which version of clj-kondo is this?

There was a bug once when you used --parallel because the require stuff in SCI isn't thread-safe

Looks like it's still 2021.03.31 in the Nix env

yeah, that's probably it then. upgrading it should fix it

When importing dependencies, do you have to import twice perhaps when your macros rely on files that haven't been cached yet?

The reason ns-analysis returns nil if the file hasn't been cached yet I gather. In any case, once I got dtype-next working correctly in its own project I moved to avclj, ran the --config --dependencies cmd to generate them and none of the imported definitions are present in the metadata.

Is there a way to re-run the linter, forcing it to regenerate the cache?

removing the skip directory in the cache caused clj-kondo to re-run thus picking up the definitions that relied on ns-analysis to work. If I require the namespaces at the top level without an alias will that cause them to be linted before this namespace and thus cause the caching mechanism to work correctly the first time?

i have this in my .zshrc, @chris441

rekondo () {
  rm -rf .clj-kondo/.cache/ && clj-kondo --lint "$(clojure -Spath)" --parallel
}

just as a really blunt "let's start all this again, shall weeee?" button

That is helpful but removing the entire cache won't work. I have macros that import definitons from other namespaces that rely on clj-kondo's ns-analysis api which itself relies on the file being cached already. If it is not -as is what happens on first run, then ns-analysis returns nil and the linter macro incorrectly fails to define the functions. If I run the linter, thus creating the data namespaces and then remove only the skip dir and run again it produces the right answer.

This also is causing clojure-lsp to fail to lint correctly so I need a more thorough fix I think.

It is specifically an issue with the order that clj-kondo lints to source tree.

@chris441 I agree that we should somehow improve this, at least within one library / dependency. Perhaps with a tools.namespace dependency like approach.

So far it hasn't been much of a problem, but with hooks that need pre-cached analysis it is.

I'll make an issue for this

and prioritize it

However, this is another challenge. The cache is not read or written to while linting, this is only done at the very end.

but perhaps ns-analysis can be made so that it also reads from the in-memory results (so far)

https://github.com/clj-kondo/clj-kondo/issues/1476

@chris441 if you tell me how I can test this out with your project in the above issue, that would help

@borkdude - I really appreciate your support a lot but thinking this through I think a better design for my project is to use code generation to generate the api .clj files. Even if we work through these issues I still don't support Cursive and I feel like this is perhaps not worth changing clj-kondo for and no matter what would still get a partial result. So let's pause on this and I will investigate implementing code generation on top of the existing api files, just renamed. Perhaps it isn't necessary to solve this issue for this reason at this time.

@chris441 Makes sense. Code generation is always a way out.

We've recently created a stub library to create stubs for closed sources like the datomic API. This also helps clj-kondo. Cursive / IntelliJ has a similar approach.

Is that stub library opensource? My current plan is to just call ns-publics, call meta on each one and try to define fns, defs, and macros with correct return type hints.

yes: https://github.com/clj-easy/stub