This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Some random thoughts on the design of copy-config: so as more and more libs I'm adding to my deps.edn, many of those libs may contain its own clj-kondo resources, and as a downstream consumer, I find myself duplicating more and more the same lint config from upstream libs again and again? It feels kind of weird to me. Let's say if some library is popular, then it's clj-kondo lint edns all get copied and committed to various downstream library or app repos with the same unnecessary duplicates? Or does it make sense to do implicit use upstream lints if exists without need to explicit copy (unless need to override some rules)? Also how does other lints in other langs handle such problem? Do they also need to duplicate things this way?
The model right now is kind of that of node_modules
where "dependency" config ends up in .clj-kondo
. This is done for the reason that clj-kondo has no idea about your project/classpath and also it's faster to get the combined configuration from disk instead of having to construct a classpath every time.
I'm open to alternatives ideas to reduce the amount of copied files though, just don't know any better ones right now
Does it make sense to cache/copy the "dependency" to somewhere $home by default? Then there's no need to duplicate them in project dir
the configurations can differ per dependency so I think that's asking for trouble, since caching is in the top 2 hardest problems in computer science
One idea that might improve things is to copy configs into a subdirectory instead of straight into .clj-kondo
, like .clj-kondo/imports
such that you can gitignore .clj-kondo/imports
or so