I think that's a good one to enable by default

rubocop will release a new linter as disabled in the initial release and then enable it in the following release after getting feedback and fixing bugs/handling edge cases

(they don't do that for all linters, just the ones that seem important)

yes, that's a good approach, but even then, if it's just about styling and contains something subjective/opinionated, I'm not inclined to enable it by default

clj-kondo can check input maps on specific function calls, but there is currently not a way to check namespaced keys + types. this is actually not hard to implement. I think @U050CTFRT asked this in the #CPABC1H61 talk by @UKFSJSM38 at the conj, if I heard it correctly

I wonder if we implement it how useful it will be since e.g. clojure.spec also supports :req-un so then the user would not use the fully qualified key

Ah yes, there is this idea of @U055NJ5CC he told me in Conj of being able to have something similar but for completion and lsp features, to be able to offer completion suggestions of known types, something to research I think

for my use case, I spec keywords with malli, but using pathom we run stuff by passing maps to the logic engine instead of calling functions directly, so I don't get much mileage out of the function call linting

Clojure-lsp has a feature of showing in a function completion suggestions of the function input map if has destructuring, but nothing checking schemas, yet

top-3 things that I would like to see with clj-kondo & lsp: 1. type-check arguments in function bodies 2. enable lsp auto-complete of map-fields when accessing keys from maps with known structure 3. like 2, but for EDN (“apply defaults” based on schema)

here’s pic of 1 & 2 from #CLDK6MFMK:

1: type-check function arguments in function bodies:

2:

the latter is just cursive auto-completing over all known keys in the project.

and 1,2,3 in comments just wishes 🙂

emitted clj-kondo config from above

I've been toying around the idea of writing Terraform in EDN, then spitting EDN to JSON, since Terraform accepts data in JSON format too. With Terraform, you basically describe input to various REST APIs and these inputs can be nested data. Typing out literal nested data is kind of a chore since there is at times, quite a lot of configuration data to manage, and this is why things like https://github.com/aws/aws-cdk/https://developer.hashicorp.com/terraform/cdktf/https://www.pulumi.com/ are all the rage, to get context-sensitive autocomplete, say aws.instance.inst <hit tab> => instance_type , but these things take a major effort to generate types for various programming languages, just in order to get autocompletion (well, they also get packaging of configurations as libraries too). You can get a schema of the resource types in Terraform as data, so I did a hack that registers all types as keywords, putting the resource name into the namespace of a keyword, and attribute name as name of keyword, so you can type say :aws_instance/insta <hit tab> => instance_type, if you have cider connected repl/rebel-readline into a clojure program with the keywords registered (relies on the way cider & others discovers keywords): https://github.com/viesti/clj-tf That way, you could get some basic form of intellisense, and say, discover what keys a resource contains (it get's a bit more complicated for deeply nested data though, in the hack I just put a . in the namespace to separate nesting, say :aws_instance.capacity_reservation_specification/capacity_reservation_target I guess the extreme of this could be F# kind of type providers, but for data schemas, but I might be derailing a bit 🙂

@U055NJ5CC about 1: please post an issue. here are all the type related clj-kondo issues: https://github.com/clj-kondo/clj-kondo/labels/type%20warnings

will do

I think 2. is harder to support, we would need to have a runtime context to check what fields are being accessed for that thread, we do have completion of all known keywords of that ns though but is generic indeed.

done: https://github.com/clj-kondo/clj-kondo/issues/2070

thanks @UKFSJSM38, hopefully there would be a way get the runtime context somehow. I’m not familiar how lsp-server works here.

the issue was just the type-linting on clj-kondo. that would already be a BIG improvement.

there is one thing that I did that is related to runtime stuff and maybe could serve as idea for this problem:

(we know the argument clj-kondo definitions and the malli schemas here)

we wanted to be able to complete datomic.api and closed source code, but we didn't have the source, so no kondo analysis, so no LSP features. We created https://github.com/clj-easy/stub, a lib that generate stubs for namespaces, and clojure-lsp uses that when starting, and now we have analysis for datomic.api. stub only uses clojure to get all the vars available and spit to a dummy clojure file where LSP cals kondo and get analysis of basic stuff

it was kind of a hack, but something that fixed the absent of analysis for closed source, and is based on runtime

interesting.

so, I'd avoid doing this kind of custom logic, but we extracted a lot of the complexity to that lib which helped a lot Just saying, say we manage a way to provide that data to LSP or to kondo, something like that could work maybe

if there is something I can do / provide extra info / something, glad to help. I think the feature set (type-linting withing function bodies, warnings on accessing keys that are not defined in argument map and a some sort of field suggester / autocompleter) would sum up to be a game-changer for clojure dx.

I guess this is really hard in clojure as the core functions are so generic, but clj-kondo is already doing great job here 💪

Nice the stub idea, now started thinking, that could this be done for IaC stuff, to generate enough Clojure language constructs (functions with arguments typed) to be able to get autocomplete when authoring IaC configuration, just like the CDK stuff does... this generation doesn't need to happen in clojure-lsp