This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-01
Channels
- # announcements (2)
- # babashka (26)
- # beginners (26)
- # biff (18)
- # boulder-clojurians (2)
- # cider (16)
- # clj-kondo (34)
- # cljs-dev (4)
- # clojure (22)
- # clojure-denver (10)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (10)
- # clojure-uk (2)
- # clojurescript (25)
- # conjure (3)
- # cursive (11)
- # datomic (11)
- # dev-tooling (6)
- # emacs (6)
- # etaoin (7)
- # events (1)
- # fulcro (6)
- # humbleui (11)
- # hyperfiddle (15)
- # instaparse (2)
- # introduce-yourself (2)
- # jobs-discuss (1)
- # lsp (26)
- # malli (7)
- # reitit (5)
- # releases (1)
- # sci (6)
- # shadow-cljs (16)
- # specter (5)
- # vim (5)
I don't enable new linters by default unless they are critical but I think :uninitialized-var
is a good candidate to enable by default from the next release on. See e.g. https://clojurians.slack.com/archives/C06MAR553/p1682951237640419?thread_ts=1681479653.194879&cid=C06MAR553
I had a similar issue in clj-kondo itself once.
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
can kondo typecheck map literals? e.g. can it warn on (let [x {::should-be-int "foo"}] ...)
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)
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
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.
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 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
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