This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (33)
- # aws (1)
- # babashka (8)
- # beginners (100)
- # calva (59)
- # clara (4)
- # clj-kondo (33)
- # cljdoc (9)
- # cljs-dev (30)
- # cljsrn (1)
- # clojure (24)
- # clojure-australia (1)
- # clojure-boston (1)
- # clojure-dev (4)
- # clojure-europe (14)
- # clojure-france (5)
- # clojure-italy (7)
- # clojure-nl (1)
- # clojure-uk (36)
- # clojurescript (13)
- # clojureverse-ops (6)
- # conjure (2)
- # cursive (2)
- # datahike (11)
- # datalevin (1)
- # datomic (106)
- # graphql (3)
- # helix (10)
- # holy-lambda (24)
- # kaocha (2)
- # lambdaisland (3)
- # lsp (199)
- # malli (35)
- # off-topic (16)
- # pathom (7)
- # polylith (38)
- # portal (16)
- # quil (2)
- # re-frame (18)
- # reagent (57)
- # shadow-cljs (11)
- # testing (3)
- # xtdb (9)
There's https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#unused-private-var but its for private vars. With public vars, it's hard to know if its meant to be used by consumers of your library code or not.
@didibus If it scans your whole codebase and it's an application, it can detect that. It works really well for us at work -- although it isn't able to spot functions called from our legacy code (of course) nor functions called dynamically.
(I'm referring to this https://clojure-lsp.io/settings/#clojure-lspunused-public-var BTW)
Ya, it probably relies on clj-kondo's analysis, but I'm pretty sure this issue is why there is no such linter in clj-kondo itself, though borkdude instead created: https://github.com/borkdude/carve for it
Because kondo doesn't know what is your project code, it just know to lint the given files
But it doesn't have the concept of project source paths or classpath of your application
Hum, kinda but not really. See the doc https://github.com/clj-kondo/clj-kondo#project-setup It's a clj-kondo feature for its linters that are cross-namespace. Clojure-lsp might conveniently setup a cache for your project for you, but you can do it even without Clojure-lsp.
I guess it could be an optional linter like some of the other slightly controversial ones
Haha, true true, but I think some of them you just know they'll be controversial, like missing docstring, or warn when shadowing a global var, or when require is not alphbetically sorted. They just have that quality of being tab vs spaces like in nature 😛
It's great that with clojure we can avoid that whole tabs vs. spaces debacle and indent our code with commas
Great idea! Whitespace is overrated. And if I used comma, I could use spacebar as a leader key since I wouldn't need it anymore for coding
I do wonder which ones and why :thinking_face: It is always great to get your take on your choices 🙇
"missing docstring" (on public vars) and "require is not alphabetically sorted" (in
There's only two backend devs so there's not really a process but we do discuss this stuff. I just noticed that the missing docstring linter is a warning, not an error. We don't enforce that rule on very small, very obvious functions. And I tend to write more docstrings than my teammate -- because I tend to design my code by writing function signatures and docstrings first, and then writing the code to satisfy that prose. But that does have the disadvantage that the docstrings and code can get out of sync over time (which is another reason we don't require docstrings -- better no docstring than an incorrect one).
Thanks for the explanation. Knowing your team size also helped put in context other answers from you that I found sort of puzzling in the past related to the absence of conflicts when changing code. 👍
Hah, well, we have a lot of different applications/services in the same monorepo and tend to work independently on them so conflicts would be rare even if we scaled up our team, I suspect. We also have very few long-lived branches, have automated CI/CD to our staging environment, and automated deploys to production, which all contributes to reducing conflicts.
CI auto-merges master to every PR when running tests so conflicts against master, at least, would be caught immediately.
We noticed that usage of a certain macro is dangerous in our code base. Therefore we made a decision to not use that macro from certain library. Now I am wondering if this rule can be forced with clj-kondo. Is it possible somehow to add project rules like
:not-recommended-macros ["my-ns/my-macro-fn"]which will generate a warning?
There is an issue here:
Please upvote and/or comment.
Right now you can accomplish a similar effect using the hooks API. Write a hook which emits a warning when the macro is called. After that, just return
nil in your hook code to continue linting as usual.
Btw, if your company is using clj-kondo, would you mind leaving a message here? https://github.com/clj-kondo/clj-kondo/discussions/1397 Then I can list your company on the companies page, if you want.
Thanks for the example. Listing our company as a clj-kondo user sounds good. I will double check internally that it is ok and post a message to the discussion.
Made some docs around how you can use hooks to disrecommend a call to a function or macro: https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md#disrecommend-usage-of-function-or-macro