This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-19
Channels
- # adventofcode (44)
- # announcements (2)
- # aws (9)
- # beginners (166)
- # braveandtrue (16)
- # calva (170)
- # cider (14)
- # cljdoc (9)
- # cljs-dev (4)
- # cljsrn (1)
- # clojars (1)
- # clojure (150)
- # clojure-dev (15)
- # clojure-europe (4)
- # clojure-india (3)
- # clojure-italy (93)
- # clojure-nl (18)
- # clojure-serbia (1)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojurescript (54)
- # cursive (19)
- # data-science (8)
- # datomic (83)
- # emacs (6)
- # events (1)
- # hoplon (3)
- # hyperfiddle (3)
- # jobs (6)
- # jobs-discuss (1)
- # klipse (1)
- # lein-figwheel (6)
- # leiningen (15)
- # lumo (1)
- # nrepl (1)
- # pedestal (15)
- # re-frame (48)
- # reagent (4)
- # reitit (2)
- # remote-jobs (1)
- # rum (2)
- # shadow-cljs (111)
- # spacemacs (10)
- # sql (16)
- # testing (10)
- # tools-deps (5)
If you previously couldn’t use Expound because your specs used a custom conformer, try Expound 0.7.2 - it may not be able to give a precise error, but at least it won’t throw a “Cannot convert path” error
Question about evolving specs: I realize the whole idea with specs is "don't change them in breaking ways", so I'm thinking about how to plan for that.
If I define a spec with a single definition, then later realize there's another valid representation, so I want to change it to (s/or ....)
, can that be a non-breaking change to consumers?
I guess if the original definition was one of the options under the s/or
it would still validate the same, but the conformed value would change right? I guess generally the conformed value is more likely to be depended-upon by internal code rather than API consumers...
adding additional valid things means old stuff should continue to be valid
I don’t know that we would expect forward-consistent stuff out of conform though