Why doesn't

components.huge-component-to-be-rendered-async

Thanks for pointing that out. I transcribed a poor example. Should say (lazy/lazy-component components.huge-component-to-be-rendered-async/the-component)

and the corresponding clj-kondo warning is

[unresolved-namespace] Unresolved namespace components.huge-component-to-be-rendered-async. Are you missing a require?

and lazy-component is something like requiring-resolve?

do you use this call on the top level in your namespace?

you can add components.huge-component-to-be-rendered-async to the :exclude-ed namespace of the unresolved namespace linter perhaps, or try this (experimental):

:config-in-call {your-ns/lazy-component {:linters {:unresolved-namespace {:level :off}}}}

> and lazy-component is something like `requiring-resolve`? Under the hood, it turns the var/symbol into a https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/lazy.clj#L22 and then invoked either https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/lazy.cljs#L31. I wasn't familiar with requiring-resolve, but I think the spirit is the same > do you use this call on the top level in your namespace? Yep, I define it at the top-level of the namespace via (def my-lazy-component (lazy/lazy-component components.huge-component-to-be-rendered-async)) > you can add `components.huge-component-to-be-rendered-async` to the `:exclude`-ed namespace of the unresolved namespace linter perhaps, or try this (experimental): I'll give this experimental route a try. Otherwise I'd have to add 20 or so namespaces to the exclusion list

>

:config-in-call {your-ns/lazy-component {:linters {:unresolved-namespace {:level :off}}}}

great to hear :)

looks like I couldn't give it a ~ in the path. all fixed 🙂

yeah, but the custom-lint-fn isn't in anyway pluggable, with JVM I meant, as a JVM library, not as a command line tool. for editor integration I think we could either make a proper linter about what namespaces are allowed to be used in which namespaces or make the ns form "hook-able"

e.g.:

{:forbidden-require {foo.bar [foo.baz]}}

I recommend using the analysis output first so you get a taste of this and then we can propose a linter for this

I’m less concerned with this specific example and more interested in general with being able to write custom lint checks that enforce project-specific constraints. Sounds like that’s currently possibleish but it’s not a super well-paved path?

How likely do you think clj-kondo is to develop in any of these directions in the future? • Making ns hookable • Improving support/docs/guard rails for custom checks

The data is all there, that is super well paved. You just have to write a small program which checks this data.

Custom checks are already well supported, just not in this specific example. There more you are willing to cooperate and provide input/feedback, the more likely this will become.

By “a program which checks this data” do you mean a hook or a separate program that operates on analysis data?

Currently, the latter. In the future, we could make a new hook for this which just gets to see the namespace requires, imports, etc and then you can do your own pass over that.

I think that hook could get the raw ns form + the parsed ns form as arguments which should make it easier to assert something

Just takes some work and hammock time to do this. Needs an issue. Perhaps if you're company has funds, sponsoring this could also help.

Ah ok, I think I understand. Yeah probably all of the custom checks I’ve thought about can be implemented off of analysis data. I think the gap is integrating those custom checks into developer workflows, especially editors. Definitely as I get closer to actually building something I will file issues/make PRs/sponsor as appropriate, I’m currently just in the fact-finding phase

yeah, the editor integration will happen once you can make a hook that gets to see this data. see https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md

would it also help if you had a hook which only got to see the raw ns form? this can be very easily added

but the parsing of the ns form is a bit tedious and clj-kondo already does all of this

but we could definitely start with the raw form and add more things to it later

Are there other things that clj-kondo or analysis data are capable of doing that hooks are not?

probably

If it helps to make things concrete other examples of potential custom checks might include stuff like • don’t call that fn without wrapping it in a try • all the fns in this ns should contain a call to this other fn • Other kinds of “please use this correctly” guard rails

The first one, clj-kondo is able to do this (it doesn't currently) but looking at the parent calls, these aren't exposed to hooks currently.

The second one you could do with hooks, by just looking at the arguments

hooks are mainly there to transform custom macros into known constructs, but slowly but surely extra things will be added to it.

Ok, so if I’m going to summarize this particular fact finding mission, it sounds like the conclusion is: • clj-kondo definitely can support at least some (and probably many) custom rules via hooks • certain checks might require new development in clj-kondo, which should be supported appropriately • Probably anything you could want in a custom check is supported by operating on analysis data, but that approach won’t integrate well into developer workflows Does that sound correct?

Correct

Awesome, thank you! This was really helpful

…I guess I actually have one more question: would there be interest in clj-kondo growing a way to have integrated custom checks that run in the integrated SCI interpreter and operate on arbitrary analysis data? I think that’s different from a hook, but maybe it’s a special kind of hook? Does this question even make sense? The observation here is that analysis data can do anything but doesn’t integrate well into dev workflows, so I wonder if there’s a way to bridge that gap

@max.r.rothman That's already what's happening, SCI is used to execute hooks. And yes, that's what I had in mind with exposing the parsed ns form as data in a hook.

Got it. Makes sense, thank you!

The general format with hooks is map in, map out and node is just one part of the map in/output. There can be many more things added over time.

@max.r.rothman Hmm, it seems hooks are available on namespace forms already: https://twitter.com/FourPillTherapy/status/1492831326680059911 So I guess you can already do a lot of what you want, using the raw ns form node.

Nice!

This triggers an unused binding warning on clj-kondo v2022.02.09.

This has always been the behavior. The binding is unused in the cljs form, so the warning applies to the cljs behavior.

You can do #?(:cljs _f :clj f) to fix this warning

nice, thank you!

do you like _f vs #?(:cljs _ :clj f) so that the symbol is at least sort of self documenting if you want to use it later?

no preference

fixing these warnings is addictive…

is there a way to opt out of this behavior? Making the code more complex by introducing another reader conditional just to fix the unused var warning doesn’t seem right to me. I don’t see the benefit of having this be a warning or am I missing something? Since _ isn’t treated special in Clojure there’s zero difference in performance or behaviour, right?

An unused binding in one target, but not in the other target is usually a sign that you forgot something in handling the other target. This behavior has been in clj-kondo since the very start and intentional.

There is no option to opt out of it.

I think the first step should be to add the target to the warning message: unused binding [cljs] or so. since it sometimes confuses people why the binding was unused if it's used e.g. only in clj but not in cljs

there is already an issue for this

but you think it’s useful in general? Looking at the code holistically (cljc) it’s not unused.

I’ll comment on the issue

clj-kondo views .cljc files as actually two (or more) files: one for each platform and lints those separately. which issue?

searching for the issue you mention in https://clojurians.slack.com/archives/CHY97NXE2/p1644925841686819?thread_ts=1644594623.137069&cid=CHY97NXE2 now

That issue is about the reporting. https://github.com/clj-kondo/clj-kondo/issues/1196

I'm not entirely convinced that adding a config to suppress stuff based on one target is a good idea.

E.g. if you have an invalid arity call in .clj, but not in .cljs, would you not emit it because it's valid in just one target?

I’d argue that it shouldn’t be a warning, but only this specific case, unused var. Feels like the game of pleasing the linter, without an actual improvement to how my code behaves.

invalid arity is very different in this regard.

As I said, it's often an oversight when a binding is used in only one target, so I don't really agree with that it's only pleasing the linter. Can be, doesn't have to be, as always with linting.

I personally wouldn't use this option, if it existed.

> Can be, doesn’t have to be, as always with linting. Surely this doesn’t apply to everything condo reports? A lot of things are almost certainly problems?

An unused binding isn't a problem to begin with.

You can also just disable it in a .cljc file if it's too much

true

It depends, expanding to the latter might result in unused literal function var warnings, but depending on the context, that may not matter

👍

Can you explain how a compiler error relates to #clj-kondo?

Hi

I am new,and I was in another room. I was told that this room is more relevant to speclj

I know nothing about clj-kondo. I was told that speclj is related to it. If that is wrong I'll jump out, and I appologize for troubling you

Oh they told me that the linter complains about :refer :all and this room might know more about it

I was able to run it. Thank you and sorry for borthering you for nothing. I am reading the docs.

@U032K6B0EEA Ah I see. It's about the unresolved symbols. Normally those should go away when your dependencies are linted. Are you using Calva?

I see the issue. So the solution is to open each sub-project in the right root, where the project.clj is. Then #lsp will index the dependencies and the :refer :all is understood.

https://ask.clojure.org/index.php/11564/need-help-with-compiler-error-unresolved-symbol?show=11568#a11568

Hi. yes I am using Calva, and ok I'll open the projects separately. Thank you so much for the reply. Calva is just amazing, and so is Clojure. They make short work of some very useful functionalities.

Let's see

I don't really know what to make of this unless I also see example calls

sorry, pitiful bug report!

@U04V15CAJ SO, what the internal compile-pattern does is scans its incoming forms and handles various cases like:

- `(? x) => (list '? 'x)`
  - `(?? x) => (list '?? 'x)`
  - `($$ x) => (list '$$ 'x)`
  - any unquoted symbol is quoted
  - Any form unquoted like `~x` is left UNquoted
  - Any form marked `~@(1 2 3)` is spliced in directly

that requires walking the incoming syntax tree and performing various substitutions, dropping down recursively into any sequences or maps

but what linting errors does it actually cause? those might be easy to prevent regardless of what the macro does

yup, writing this up is helping me realize that there might be a simpler way. The main error is “unresolved symbol”;

do you have an actual example call?

yes, getting it together now

here is a 1-nested pattern:

so, yes… I think I am seeing the simpler form

any symbol should NOT ever trigger an unresolved symbol error;

unless it is inside a splice form like

so what I’m realizing (duh) is that it might be that a much simpler walker that just quotes everything except stuff inside splices or unquote-splices will do it

what you could do is write a hook that ignores every question marked symbol, or just ignore all unresolved symbol errors whatsoever by configuring :linters {unresolved-symbol {:exclude [(your-ns/pattern)]}}

the latter is the quick solution

yup, but in this case I DO want to have the unresolved symbol error on expected in that last example

@U04V15CAJ I think I haave the answer so don’t let me take your time here

what you can do is walk the body, select all unquoted expressions and then return a vector node of those

oh, I like that

I have a similar macro in babashka.process, called $ which also uses unquote in this way

so by returning the vector, everything in the vector will get hit with the linter

brilliant…

yeah

now that I’m started on this, it’s super fun writing hooks etc

Hm no, this should be fixed in clj-kondo. issue welcome

Oh, there is already an issue for it: https://github.com/clj-kondo/clj-kondo/issues/892#issuecomment-803461457 I will bump priority

so the macroexpansion checks out fine, but not the reader-literal wrapper

@sritchie09 Let's go into a thread. This is a repro I tried on the JVM:

(set! *data-readers*
      (assoc *data-readers* 'time/date identity))

(let [foo "2022-02-10"
      bar #time/date foo]
  (prn bar))

Sg

Nice, way tighter . I'm away from keyboard now - does it show the same behavior?

even:

(def foo 1)
(let [bar #time/date foo]
  (prn bar))

But does clj-kondo Think that foo is unused in this case?

that that prints 1 instead of foo is I think an accident of implementation and where evaluation happens

well, maybe not

I guess I'd expect bar to be bound to the symbol foo

> But does clj-kondo Think that foo is unused in this case? Before the latest release it it didn't, but because of a fix for this issue: https://github.com/clj-kondo/clj-kondo/issues/1563 it now basically treats the "data" as a quoted expression.

imo, that is correct in CLJ

I think I disagree because of what happens when you put an explicit quote in the argument to a reader literal

the #time/date fn is called during read with unevaluated values

I’ll pick back up when I’m not a distracted passenger in the car, thanks to you both for looking at this!

But the return value is treated like the return value from a macro

if so, that is accidental implementation in CLJ (but I think is expected in CLJS)

this is where the platforms differ

I'll just relax the linting in clj-kondo in accordance with the accidental implementation, since people seem to rely on this....

well, they shouldn't and they could be broken in the future

Alex, the current implementation matches how the vector literal and map, set etc work right?

those are different - literal colls evaluate their elements

#sicm/quaternion [a b ‘x ‘y] was a place where I was relying on this

First two elements were let bound, the third and fourth are explicit quoted symbols

(Since I can do symbolic arithmetic)

https://clojure.org/reference/evaluation "Vectors, Sets and Maps yield vectors and (hash) sets and maps whose contents are the evaluated values of the objects they contain."

Totally, and evaluation in this case makes bar bind to 1 like it does now

Whereas Unevaluated would be the symbol foo

https://clojure.org/reference/reader#tagged_literals "The data reader function is invoked on the form AFTER it has been read as a normal Clojure data structure by the reader." (notably no evaluation mentioned here)

so you're talking about the combination of these

....

yes, so the symbol (unevaluated) is passed in, and then the returned form is evaluated. Which matches my mental model that [] expands to a call to “vector”

not a great model but maybe ok

okay, got a keyboard for a moment

I guess the combination of the things above would imply evaluation of the literal vector at read time before being passed to the reader fn

I would say this is certainly not the intent of the reader fn, which is to take primitive data values to describe new complex data values

@alexmiller hmm, it is quite useful for sure to be able to make compound values too

that's what functions are for

true 🙂

it's not data anymore

I can't stick it in an edn file and read it elsewhere

the reason I was doing all this was so I could have a printable representation that someone could evaluate

which is fine

so quaternions are 4-vectors, but they print like #sicm/quaternion [r i j k]

that seems fine

it's the evaluation in the constructor that's fishy

which you can then paste in; which works with primitives, I see what you’re saying

I think I am explicitly NOT evaluating in the constructor

what are a and b here then? #sicm/quaternion [a b 'x 'y]

say, 1 and 2; but the emitted form from that is just (quaternion a b 'x 'y)

that's not data

I'd say use the function in that case

so reader literals should always emit data;

literal

and it’s an accident now that they can emit code forms, like a macro?

it's an accident that that "works"

I totally get it, we are clashing on my model of [a b c] expanding to (vector a b c)

which works, even when a b and c are bound outside of [a b c]

if you want a macro, make a macro

👍

okay, thanks for talking it out

it might be an accident, but it is a nice feature 🙂

you should be able to take the thing that is a data reader and read it in another jvm and get a value

it's bad and you should feel bad :)

it's basically reader macros, which are intentionally not a feature in Clojure

and this has come up before in cases where it didn't work like someone expected (don't remember the context now)

but it was something Henry was doing

So, is the summary: it works (similar to macro-expansion), but it's not how it's intended to be used in JVM Clojure, but in CLJS it is explicitly supported?

yes for the CLJ parts, I think for the CLJS parts but I would verify that with dnolen

So the gist is: data readers should be used to read context-free data.

or reader literals are literals

So the current take of clj-kondo on this aligns with how it's intended (at least on the JVM)

I think so

feel my ears burning 🙂 to explain what the change is that I was advocating for (and has recently been merged to cljs master). A data_readers.cljc file with the following content: {foo/bar #?(:clj xx/yy :cljs ff/gg)} is read by the clojure compiler ok (and it reads the :clj branch). The cljs compiler did not have conditional read enabled so would barf on that. With the change, the cljs compiler reads the :cljs branch. That's it really - so no change to how data reader functions work

ok. I wonder how clj-kondo could help with promoting the idea of reading literals instead of expressions that depend on context, but this depends on what the reader function does and clj-kondo cannot know this

hmm, probably I'm being naive but in #foo/bar a it must see that a is not a literal

no! the point is that a could be a literal and should be handled as a literal by the reader function, but often is not, because people are abusing reader functions as macros

Hopefully I'm paraphrasing correctly, what Alex explained in this thread

ok. I can't think I would write something like #foo/bar a in code. I would think it better style to just call the function. again repeating what's been said above, but reader functions targeting cljs (written in clojure) are often necessarily macro-like (as per one emitting

(js/BigInt ~x)). 

Why is that necessary (instead of just calling a function or macro)?

And how is that unique to CLJS?

because the reader runs on the JVM but the code produced runs in JS?

Yes, exactly that

But note a reader function intended to run in a js env, such as when reading edn, will not be macro like

so when do you need a reader function for this rather than a macro? as in, the necessary part?

or even a function

for me personally I use cljs data literals in the repl. the tags round trip via printer. so e.g. calling some fn that prints out #foo/bar "abc" , then I'll want to paste that back in. I don't think I would ever put a tagged literal in a source file

for one thing, in clojure, you have to make sure the reader function exists already, or else the reader will complain. iow you have to require the reader function ns in any ns where you use the literal. so if you have to do that, you might as well call the fn directly imo

what is the point with the last issue?

I don't see how it relates to "read only literals, not context-sensitive expressions", could you explain?

well my feeling is the context sensitive thing would only come up in source code. and ofc that's what kondo is for 🙂 . I guess I'm saying if kondo complained error: tagged literal in source code then I would be happy

isn't that the main idea behind data_readers.cljc though, that you can use it in source code? ;)

well I only want to use when interacting with the REPL. I appreciate others may feel differently. and I would be interested to hear arguments for having them in source code. I mean, there's usually little in it verbosity-wise and tagged literals intentionally add indirection-- but I don't want that indirection in source

@U051B9FU1 one spot I am abusing this is to get ratio support in Clojurescript; I do have #sicm/ratio 1/2 forms in my source that can actually product (rationalize (bigint 1) (bigint 2)) in cljs because, by running on the JVM side, the 1/2 reader literal actually makes sense

that’s the only spot where it would be aesthetically blah to switch to (ratio 1 2) all over (though (/ 1 2) when I have my overriding / imported, so even that is not so bad

thanks @sritchie09 - personally I'd go with the fn call style you mention but appreciate that's personal preference. Slight digression but I certainly wouldn't put them in library source as I think end user should have full control over reading and printing. but would you do #sicm/ratio foo though if it was written in macro style? & back to clj-kondo and discouraging macro-style reader functions @U04V15CAJ I still think kondo could report on usage such as

#foo/bar a 

(let [x "2022"]
  #inst x)

clj-kondo cannot know if you're passing x as a contextual value or as a literal. the reader function always sees the literal symbol x - it's up to that function what to do with it and this is opaque to clj-kondo.

so x might be really unused, depending on what the reader function expands into

so clj-kondo cannot reliably warn against something here

Ok, I'm sure you're right!

@U051B9FU1 it's the same with:

(defmacro foo [x] ...)

(list 'quote x)

symbols are data and data reader function could treat those just as literal symbols, which makes things almost impossible to statically analyze, unless clj-kondo had a config for data reader function expansion like it has for macros, I guess it could add that, but not sure how useful it would be

I'm struggling to think why you might pass a valid variable symbol to a reader function that would treat it just as a symbol.

But who knows

well, given examples like:

#garden.types.CSSAtRule {:identifier :media
                             :value {:media-queries {:min-width "768px"}
                                     :rules ([".md\\:container" {:max-width "768px"}])}}

I think the best clj-kondo can do here, might be to not emit any warnings on code that could be valid Clojure, getting out of the way

yeah makes sense. :thumbsup:

@U04V15CAJ How do I go about linting my deps, including my used clojure? I’m launching it from the same directory as the deps.edn and have tried --lint . and --lint deps.edn ….

@zane clj-kondo --lint $(clojure -Spath) --dependencies

The --dependencies flag will take care of a few things: 1. it won't emit any warnings 2. it will not re-lint jar files it's already seen

I see!

Thanks!

Would you recommend --dependencies in CI, then?

For better linting results, it does provide benefits, e.g. you will see invalid arity calls to third party deps, but it's also totally fine to not do this.

you can cache the linting results though, if you're deps.edn didn't change

and then the second time should be faster, if that's a concern