Fork me on GitHub
#clj-kondo
<
2020-03-09
>
Sasho14:03:57

👋 Is clj-kondo able to work with macros, that expect a binding vector. Here’s an example: https://github.com/clojure/java.jdbc/blob/2acbf2736a30634c9c75e6a1853e970ffa6bdbb4/src/main/clojure/clojure/java/jdbc.clj#L876 When I write:

(jdbc/with-db-connection [db some-db-spec] …)
clj-kondo complains tha db is unresolved (`unresolved symbol db` )

borkdude14:03:44

@sasho.popov You can probably use :lint-as {clojure.java.jdbc/with-db-connection clojure.core/with-open}

👀 4
Sasho15:03:10

Michiel, is this a valid config?

{:lint-as {clojure.java.jdbc/with-db-connection clojure.core/with-open
           clojure.java.jdbc/with-db-transaction clojure.core/with-open}}

Sasho15:03:34

@borkdude I can confirm your suggestion worked! Thank you.

borkdude18:03:38

Can someone remember that Clojure-Kit was suggest here by someone who made it work with clj-kondo?

serioga19:03:34

Hi @borkdude Should not clj-kondo warn about if-let with single branch?

serioga19:03:26

For this code with reader conditionals clj-kondo warns about “namespace rum.core is required but never used” (which is actually used in line 21). How should I lint code with reader conditionals?

borkdude19:03:09

@serioga If the library is only used in clj or cljs you should put the require in a reader conditional

serioga19:03:42

hm, this is not ergonomic...

borkdude19:03:16

that's your opinion 😉

borkdude19:03:46

about if-let: I think an issue is warranted for that

serioga19:03:53

for single require reader conditional should be around (:require) 😞

borkdude19:03:57

@serioga because (:require) isn't valid? yeah, that's how it is. clj-kondo lints a .cljc file twice: once for .clj and once for .cljs

borkdude19:03:12

luckily you can have multiple :require clauses, so it's not that much of an issue.

borkdude19:03:33

yes, it would be good to add an issue for that and it's pretty easy to fix. I'll make sure it gets into the next release

serioga19:03:43

«luckily you can have multiple :require clauses» wow, interesting

borkdude19:03:52

thanks a lot.

serioga19:03:05

«luckily you can have multiple :require clauses» the namespace order is tested independently in every :require?

borkdude19:03:19

do you mean by clj-kondo?

serioga19:03:27

«do you mean by clj-kondo?» yes

borkdude19:03:49

I'm not entirely sure

serioga19:03:22

ok, I'll test

borkdude19:03:38

@serioga what you can also do: #?(:cljs [rum.core :as rum] :clj [rum.core]). clj-kondo will ignore namespaces that do not have an alias or referred vars

serioga19:03:06

I'm thinking about what to do with code like

(:require
    ; systems
    [app.app-system.service.app-config]
    [app.app-system.service.hikari-data-source]
    [app.app-system.service.immutant-web]
    [app.app-system.service.mount]
    [app.app-system.service.webapp-http-handler]
    [app.app-system.task.database-migration]
    ; imports
    [app.app-system.impl :as impl]
    [app.lib.util.integrant :as ig-util]
    [integrant.core :as ig])

borkdude19:03:00

ah yeah, maybe it works if you split them into multiple requires, I'm not sure

borkdude19:03:20

I'm assuming you are asking this because of the unsorted-required-namespaces linter

serioga19:03:38

It works! Cool.

serioga19:03:00

«I'm assuming you are asking this because of the unsorted-required-namespaces linter» exactly

serioga19:03:23

Multiple requires is a really nice hint.

borkdude19:03:47

oh maybe this could be documented and captured inside a unit test so we can keep this behavior as it is

borkdude19:03:59

if you want to do this, it might be an easy and nice PR

borkdude19:03:26

else, posting an issue to remind me is also fine

serioga19:03:57

with multiple requires everything become clear

(ns app.lib.react.mount
  (:require
    [app.lib.react.component :as react-component]
    [app.lib.util.transit :as transit])
  #?(:clj
     (:require
       [clojure.string :as str])
     :cljs
     (:require
       [rum.core :as rum])))
so every format has its own section which is easy to maintain. https://clojurians.slack.com/archives/CHY97NXE2/p1583782598108900

serioga20:03:50

@borkdude did you think about checking line length for documentation strings?

borkdude20:03:50

I'm not aware of any conventions around that. Is that important?

serioga20:03:55

I also not aware, but: • Cursive has option “Docstring fill width” with default value 80 • Cursive shows function documentation “as is” and long lines are not easy to read because of horizontal scroll So I thought maybe there a rule expected to keep lines in width 🙂

serioga20:03:34

At least in clojure.core docstrings are fine

serioga20:03:03

this documentation format also shows docstrings as preformatted http://clojure.github.io/clojure/clojure.core-api.html

borkdude20:03:16

I'm hesitating to include this in clj-kondo because in general clj-kondo isn't concerned with formatting. it strips away all whitespace for example before it analyzes any code.

borkdude20:03:42

maybe it can be a feature of a clojure formatter tool

serioga20:03:05

«it strips away all whitespace for example before it analyzes any code.» but not from docstrings I guess

borkdude20:03:22

that's true, but doesn't it also matter how far the string is indented itself?

borkdude20:03:55

hmm, clj-kondo knows how far the string is indented btw. it has location metadata

serioga20:03:56

I mean linter can produce warning if docstring lines exceed specific width

borkdude20:03:31

yeah, I guess it could. make an issue and then we can think about it some more: what the warning and config should look like.

serioga20:03:36

«doesn't it also matter how far the string is indented itself?» leading spaces are stripped as I know

borkdude20:03:32

please provide some concrete examples in the issue

dominicm21:03:28

Docstring width is fine until someone needs to paste a link in and tell the CI to go away for this one function.

borkdude21:03:35

@dominicm If you have useful feedback on that issue, you can post it here: https://github.com/borkdude/clj-kondo/issues/793