This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-16
Channels
- # announcements (19)
- # babashka (13)
- # beginners (7)
- # calva (8)
- # cider (25)
- # clj-kondo (12)
- # cljsrn (7)
- # clojure (60)
- # clojure-australia (5)
- # clojure-europe (59)
- # clojure-france (14)
- # clojure-gamedev (2)
- # clojure-nl (1)
- # clojure-uk (7)
- # clojurescript (43)
- # community-development (8)
- # core-async (2)
- # cursive (15)
- # datomic (75)
- # deps-new (31)
- # depstar (1)
- # fulcro (6)
- # graalvm (53)
- # holy-lambda (1)
- # juxt (3)
- # jvm (13)
- # kaocha (8)
- # lsp (109)
- # malli (14)
- # off-topic (62)
- # pathom (11)
- # pedestal (12)
- # polylith (12)
- # releases (5)
- # sci (5)
- # shadow-cljs (15)
- # sql (16)
- # tools-deps (27)
- # vim (1)
- # xtdb (14)
what kind of integration?
my guess is that you want something like this: https://www.fulcrologic.com/copilot (which is not available yet)
Perhaps you mean "resolve as..."? It follows the normal form of functions, so resolving it as a defn works well (in IntelliJ, and I'm sure in most others).
I think copilot is what I'm thinking of, more or less. If we already have the Guardrails annotations, it seems to me they should be usable statically too, not just at runtime... at least technically possible. Maybe even the runtime results can have some editor integration. Like if a function is returning a non-conforming value during execution, the Guardrails log contains enough data to identify the exact place in the code and that data could be used to annotate the code in the editor with some warning indicator.
An editor cannot "run" them, nor can a linter (except in some trivial cases). Specs are turing complete. You have to actually evaluate the specs in the runtime where they are defined. This is made even more complicated for CLJC where the CLJS context could be diff than the CLJ one...you need to try it in both runtimes to really give fully accurate results.