This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-05
Channels
- # announcements (1)
- # babashka (61)
- # babashka-sci-dev (1)
- # beginners (54)
- # biff (17)
- # cider (4)
- # circleci (1)
- # clj-commons (39)
- # clj-kondo (26)
- # cljdoc (40)
- # clojure (41)
- # clojure-europe (32)
- # clojure-norway (4)
- # clojure-portugal (1)
- # clojure-uk (2)
- # clojurescript (59)
- # clr (69)
- # conjure (7)
- # cursive (22)
- # data-science (16)
- # datalevin (1)
- # datomic (19)
- # docker (31)
- # funcool (1)
- # honeysql (6)
- # hoplon (1)
- # hyperfiddle (41)
- # introduce-yourself (1)
- # juxt (2)
- # leiningen (5)
- # nbb (14)
- # nextjournal (38)
- # off-topic (47)
- # polylith (2)
- # rdf (5)
- # re-frame (4)
- # reitit (27)
- # releases (6)
- # scittle (10)
- # shadow-cljs (24)
- # sql (11)
- # squint (1)
- # tools-build (33)
- # tree-sitter (4)
- # vim (39)
is there a way to mark a form as critical? the opposite of #_:clj-kondo/ignore
?
e.g. some temp debug stuff that should not be checked in (to trunk at least), and could be nice when I write it to be able to mark it at the same time to have kondo flag it as critical
This is git specific but I use a git pre-commit hook to have a language agnostic way of letting me mark a specific line as "hey, computer don't let me accidentally commit this change" I've written about https://jakemccrary.com/blog/2015/05/31/use-git-pre-commit-hooks-to-stop-unwanted-commits/. It looks like I've slightly tweaked the pre-commit hook since writing that article and the latest version can be found https://github.com/jakemcc/dotfiles/blob/master/git-templates/hooks/pre-commit
I am doing some println/logging debugging of raw api call results which contain secrets (db credentials, api tokens, etc) when doing local development (because the upstream api looks broken). Since those would be no-nos to have to have in production-like environments in the logs thought maybe marking them as critical might be a way to make sure that those would never creep in
where it makes sense to let it make it into local commits for a working branch, but could be halted by a CI check for getting into trunk
using CI as being the latest worse case prevention, but even a local check of critical issues when doing final prep for a branch
@US03ZP2F5 We have discouraged-var
for specific forbidden var usages
Perhaps you can make an "identity" macro like:
(defmacro dont-do-this [x] x)
and then add this to the discouraged-var linter and wrap calls that should not be used in thereI am writing code that makes use of core.logic in Emacs with clj-kondo doing linting, and it keeps complaining about the binding forms ...
(l/run 3 [q]
(l/conde
[(l/== q [[:first "Damien"] [:middle "Robert"] [:last "Kick"]])]
[(l/== q [[:first "Damien"] [:middle nil] [:last "Kick"]])]
[(l/== q [[:nickname "D'amy"]])])
(name!? q))
... gives me ...
dkick1@donovan mallikanren % lein clj-kondo | grep 'Unresolved symbol: q'
/Users/dkick1/src/dkick/mallikanren/src/com/github/dkick/mallikanren/flat/repl.clj:12:13: error: Unresolved symbol: q
dkick1@donovan mallikanren %
These are not typical let
-like binding forms because they are not of the form name value
but rather only just name
. How can I tell clj-kondo
stop complaining about unresolved symbols? ThanksThere are various ways to deal with this: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#unrecognized-macros
I think writing a hook for it would be the best option. Then we could maybe host those here: https://github.com/clj-kondo/configs So everyone could use them
But the quick and dirty way would be to just silence the unresolved var linter for l/run
How do I suppress/disable a lint on something like Potemkin's def-derived-map
? I know about the :lint-as
key in config.edn
but I wasn't sure if this was a) the right approach or b) how exactly to do it if it is.
potemkin already has a clj-kondo configuration that you can import: https://github.com/clj-commons/potemkin/blob/master/resources/clj-kondo.exports/potemkin/potemkin/config.edn
great, thanks @U04V15CAJ!
hmm, I am using clojure-lsp. are there any LSP-specific steps I need to take here or no?
Maybe @UKFSJSM38 can chime in. I’m about to sleep now :)
No worries, thank you!
clojure-lsp when calling clj-kondo will pass the --copy-configs
by default, so you only need something like this in your .clj-kondo/config.edn
{:config-paths ["potemkin/potemkin"]}
This way, clj-kondo will recognize those copied folders and use those configs during linting
I added that to my config.edn
and now the "quick fix" gives me a drop down menu to tell LSP to lint the selection as one of a number of clojure.core vars, but clicking on any of them does not seem to do anything?
I did however put this in my project-level config, should it be in the global clj-kondo config?