Fork me on GitHub
#clj-kondo
<
2021-10-20
>
Joshua Suskalo01:10:03

Is there an unused public var linter now? Or did lsp add that?

Joshua Suskalo01:10:29

oh yeah, it's being reported as coming from clojure-lsp

didibus05:10:15

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.

seancorfield05:10:10

@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.

didibus05:10:56

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

ericdallo12:10:33

Because kondo doesn't know what is your project code, it just know to lint the given files

ericdallo12:10:52

But it doesn't have the concept of project source paths or classpath of your application

didibus02:10:35

Hum, it has its cache, wouldn't that work?

ericdallo12:10:47

That cache was built by clojure-lsp right?

didibus16:10:05

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.

didibus05:10:15

I guess it could be an optional linter like some of the other slightly controversial ones

seancorfield05:10:48

One person's "controversial" is someone else's "mainstream" 🙂

didibus05:10:55

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 😛

lassemaatta05:10:10

It's great that with clojure we can avoid that whole tabs vs. spaces debacle and indent our code with commas

didibus05:10:01

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

seancorfield05:10:21

Two of those three are error level linters at work!

mynomoto13:10:33

I do wonder which ones and why :thinking_face: It is always great to get your take on your choices 🙇

seancorfield16:10:25

"missing docstring" (on public vars) and "require is not alphabetically sorted" (in ns).

mynomoto16:10:36

Thanks. Do you have a team process to decide what to include on linters?

seancorfield17:10:04

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).

mynomoto17:10:41

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. 👍

seancorfield17:10:49

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.

seancorfield17:10:49

CI auto-merges master to every PR when running tests so conflicts against master, at least, would be caught immediately.

mhjort09:10:28

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?

borkdude09:10:42

There is an issue here: https://github.com/clj-kondo/clj-kondo/issues/996 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.

mhjort09:10:14

Thanks for the info. I will take a look

borkdude09:10:12

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.

mhjort12:10:19

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.

🎉 1
borkdude14:10:21

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

Noah Bogart15:10:14

excellent, thank you very much