Fork me on GitHub
#clj-kondo
<
2022-02-23
>
martinklepsch16:02:35

For cljc files is there a way to not lint the Clojure side of things and instead only lint ClojureScript?

martinklepsch16:02:06

Asking because with shadow-cljs it’s somewhat common to use #?(:browser ..) and node reader conditionals

martinklepsch16:02:21

and you don’t really want to lint the namespace as Clojure

borkdude16:02:08

Yes, but undocumented since I was unsure about the API. Try:

{:cljc {:features #{:cljs}}}

💡 1
alex18:02:45

If we adopt the above config, what is the recommended approach for linting the Clojure branch in some .cljc files but not others? Most of our .cljc files are Clojurescript only, but there are a handful that expose implementations for both Clj and Cljs After implementing the :cljc config above, I'm seeing that clj-kondo reports "Unresolved var" wherever a Clojure namespace consumes a var defined in a .cljc file For example,

;; log.cljc

(defn info
  [& s]
  (let [msg (fmt s)]
    #?(:clj  (log/info msg)
       :cljs (glog/info logger msg))))

;; user.clj

(log/info (str "Rendering CSS to " path))
;; clj-kondo reports unresolved var log/info

alex18:02:31

I tried adding a {:clj-kondo/config '{:cljc {:features #{:clj :cljs}}}} override in the log.cljc namespace declaration, but that didn't seem to work

borkdude18:02:24

That doesn't work yet, since by the time clj-kondo reads that config, the cljc branches have already been parsed

1
borkdude18:02:47

The unresolved var is because clj-kondo is only going to analyze the features you specify. The intention of that config is to disable .cljs completely for babashka projects that use .cljc files

alex19:02:02

Ah got it, so right now it's an all-or-nothing type of deal with the :cljc config Hmm, given the situation described in our use case above, do you any suggestions on a way to make this work?

borkdude19:02:45

Currently not

alex19:02:24

Thanks! That is our lone Clojure namespace, and it's rarely updated, so maybe we can just get away with not linting it... 😬

borkdude20:02:37

Maybe you can explain what your issue is with this, since this requirement has never come up before

borkdude20:02:00

If it's your only clojure namespace then I don't see why you wouldn't use the global config

alex20:02:15

Ah sure - thanks for working through it with me. My issue is an extension of what Martin wrote above We have lots of .cljs files, ~20 .cljc files, and a single .clj file. The .cljs files are used in both Node and browser for server and client-side rendering We have 2 distinct sets of .cljc files: • those that target :node and :browser ; shadow-cljs supports using the reader conditional to target different JS platforms e.g. node and browser to consume specific platform-specific APIs. These import other CLJS namespaces • those that target :clj and :cljs And we have a single .clj file that imports a couple .cljc namespaces --- Without the :cljc {:features #{:cljs}} config you shared above, we would have to wrap most of the .cljc namespaces (required imports and vars) in #?(:cljs) to prevent the Clojure path from being linted. Ideally we would be able to just use the #?(:browser) reader conditional on the leaf nodes where we utilize the browser-specific API e.g. js/window or js/document

alex20:02:27

Is your suggestion to use the global config to ignore the unresolved var errors for Clojure files?

borkdude20:02:40

With global I meant :cljc {:features #{:cljs}} which I think makes sense for your project. And then you could maybe just ignore the one .clj file or put a namespace config in that one.

👍 1
borkdude20:02:49

Or perhaps I'm still missing what the issue is.

alex20:02:59

Yep, utilizing the :cljc config + ignoring the one .clj file was what I had in mind 🙂 Thanks!