@vemv You can do this by adding the config to a dependency in resources/clj-kondo.exports/your.org/your.lib/config.edn. When you then add this dependency to the classpath, and call lein clj-kondo --skip-lint --dependencies --copy-configs it should copy the configuration in your .clj-kondo dir and then clj-kondo should pick up on it.

Just make sure that library with exported config isn't used by anyone else, since exported configs should normally be just be about one specific library.

Nice!

Got it, thanks

I kept thinking about my scenario and perhaps a .jar isn't the best solution to begin with.

We use a plugin similar to https://github.com/achin/lein-parent . So a kondo config could be defined in a parent project as Lein config.

Example:

;; project.clj
:clj-kondo {:config {:linters {:docstring-leading-trailing-whitespace {:level :warning}
                               :reduce-without-init                   {:level :warning}
                               :single-key-in                         {:level :warning}
                               :used-underscored-binding              {:level :warning}}}}

This would be similar to Eastwood config (which also is often expresed inline in project.clj or deps.edn) and overall a pretty vanilla feature that could serve various use cases.

PR OK?

I'm fine with this, as long as it doesn't raise the expectation that "vanilla" clj-kondo supports reading configs from project.clj.

Maybe you're not aware of this, but if the shared config is part of a git mono-repo, say in $repo/shared-clj-kondo-config, you can refer to it from other projects in $repo/$project/.clj-kondo/config.edn with :config-paths ["../../shared-clj-kondo-config/config.edn"]

Yes, I had heard of monorepo niceties, however I'm using a polyrepo in this scenario

OK, even if you have polyrepos it works, as long as the directory structure matches. If the directory doesn't exist, then it won't crash, but it will just not include the config.