This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (3)
- # babashka (24)
- # beginners (333)
- # clj-kondo (36)
- # cljs-dev (11)
- # clojure (75)
- # clojure-italy (3)
- # clojure-madison (1)
- # clojure-uk (15)
- # clojurescript (31)
- # core-logic (18)
- # cursive (2)
- # data-science (3)
- # datomic (1)
- # events (1)
- # fulcro (13)
- # graalvm (2)
- # jobs (1)
- # kaocha (2)
- # malli (1)
- # overtone (6)
- # re-frame (7)
- # reagent (17)
- # rewrite-clj (3)
- # shadow-cljs (10)
- # sql (9)
- # vim (1)
Hello. I have a quick question: Does clj-kondo know how to handle function args in var metadata?
If I have a unpopular library that introduces a with- macro, can I annotate it somehow so that kondo users don't need to add it to their lint configuration? Maybe something picked up as part of the full analysis
@dominicm I have been thinking about this as part of these issues: https://github.com/borkdude/clj-kondo/issues/253 https://github.com/borkdude/clj-kondo/issues/559 For #559 I've come to the conclusion for now that it would be most flexible to add a README page for third party library configs where library maintainers can PR their configs. https://github.com/borkdude/clj-kondo/issues/559#issuecomment-551949256 But #253 could help automate this and use rewrite-clj(c) (proper, not my fork) to include it in the config.edn
is there already support for more than one config to be merged? sort of like how for deps, ~/.clojure/deps.edn "merges" w/ a project's deps.edn
i guess 5 under design principles suggests that there is no at-run-time merging. may be the external tool being considered could do this kind of thing?
@sogaiu Currently there is .clj-kondo/config.edn and the --config argument that are merged
it's by design that no multiple configs are merged from multiple .clj-kondo directories, so people store a complete configuration in a project
supposing that library authors provide a config with their library, is it expected for users to have to manually merge this with their local configuration (for which the 3rd party library is a dependency)?
ah, so a user won't have to manually piece together 2 (or more?) existing config files?
the reason I want it to be another tool is that it can have more dependencies and also work in CLJS, so it can be hooked up with editor tooling
I imagine the devcards macros probably have the same shape as something else and that I could use
:lint-as, but I don't know what other thing is...
if I use the vscode extension, I should still put the config in