This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-26
Channels
- # announcements (1)
- # babashka (106)
- # beginners (11)
- # biff (7)
- # calva (16)
- # clj-kondo (40)
- # clj-on-windows (5)
- # clj-yaml (10)
- # clojars (4)
- # clojure (37)
- # clojure-austin (22)
- # clojure-australia (1)
- # clojure-europe (40)
- # clojure-nl (1)
- # clojure-norway (10)
- # clojure-spec (6)
- # clojure-uk (6)
- # clojurescript (13)
- # conjure (11)
- # cursive (14)
- # datalevin (8)
- # datascript (5)
- # emacs (39)
- # events (1)
- # fulcro (55)
- # gratitude (4)
- # holy-lambda (2)
- # humbleui (9)
- # instaparse (1)
- # lsp (3)
- # malli (12)
- # meander (2)
- # membrane (7)
- # nbb (1)
- # off-topic (16)
- # pathom (9)
- # releases (3)
- # sci (14)
- # shadow-cljs (25)
Makes sense to be cautious. Do people upgrade the clj-kondo in their CI without first checking? That seems dangerous to me
Iām a bit on the extreme side and run it a specific version from the JVM for CI via a deps.edn dep
ah yeah, is a good point, that does keep up pretty actively.
Yeah I appreciate all the up-to-date goodness that clojure-lsp brings to me in my editor. For CI, I want repeatability.
@dpsutton Do you mean something like :experimental true
and then after a while the experimental linters become default linters?
> soon-to-be-default linters
"Experimental" sounds to me like ... well, experimental. I would have no expectations of a linter described as experimental even being complete, much less destined to be a default.
I think the request is more like :planned-defaults true
, to get an early jump on linters that you definitely hope to enable for everyone after some battle-testing. (Also gives people a heads up on such plans, so they can chime in with possible reasons to never default some particular linter.)
Meh, I think it might be sufficient to just keep future linters all optional and if people want to use them, they can do that
shadow-cljs and kaocha both use the concept of a file-system watcher to trigger build and test runs. is it possible to run clj-kondo in this manner, so as to benefit from running it as a warm process? duh, of course it's possible. what i meant is, is anyone doing it and can i have your code please? š why i am asking: i want to run kaocha, shadow and kondo-in-watch-mode all at the same time as i move a whole bunch of namespaces around. this way, i can watch one set of terminals and see all the feedback together, without having to browse files in my editor
you can use the watcher pod from here: https://github.com/babashka/pod-babashka-fswatcher
hah! we already have one. so all i need is to add the watcher. simple! thanks @borkdude
how i force a bb script to stay running?
@robert-stuttaford @(promise)
ah darn of course!
Feel free to add something to the clj-kondo wiki: https://github.com/clj-kondo/clj-kondo/wiki
ooh for sure!
https://twitter.com/RobStuttaford/status/1574430197079752706 (is it ok for me to paste a link to a tweet like this?)
Sure. It might have been nice to show the code in a different buffers so you don't get the clj-kondo lint warnings š
haha i haven't unlocked the make a gif achievement yet š
licecap š
@borkdude would it be worth shipping kondo with these hooks? datomic and malli are at least as popular as re-frame.
I'd rather not ship any built-in stuff if it can be done in libraries. In the beginning it was a necessity but this is no longer true
I've had a lot of churn in the re-frame stuff with edge cases which led to releasing new versions of clj-kondo, which is not a problem you have when you do it in libs
oh right, so a PR for the hook could be added to malli and --copy-configs
used in projects that depend on it. In theory, the same should be done for re-frame
so @robert-stuttaford that could be a way to contribute to the ecosystem if you're interested.
yeah, I am considering chopping up clj-kondo/config into multiple libraries, so you can just include extra libraries on your classpath to get configs
i'd like to ensure that every test file requires a specific test setup file that does some side-effecting set up. i could do this in a hook, i think, but would there be any interest in adding this as an official linter rule?
it seems that :macroexpand
hooks aren't used when checking dependencies. is there a way to use a locally defined :macroexpand
hook on dependencies?
clj-kondo doesn't really distinguish between your code and dependency code. hooks are always executed
I must have an error in my code then, thanks