I think it can only work for simple stuff, but the simple stuff can be pretty high impact - specifically just nullability

Perhaps we should try to do https://dev.clojure.org/jira/browse/CLJS-2946 prior to release as it would provide a workaround for https://dev.clojure.org/jira/browse/CLJS-2945 (Otherwise spec failures may not be very useful because they print with very little info.)

With the latest master

(require,'[clojure.spec.alpha,:as,s])
(require,'[clojure.spec.test.alpha,:as,stest])

(s/fdef clojure.core/merge
  :args (s/cat :maps (s/* (s/nilable associative?)))
  :ret (s/nilable associative?))

(stest/instrument `merge)

(merge) ;; should be nil, gives maximum call stack exceeded

clj -A:test -m cljs.main -re nashorn -i maximum-call-stack-exceeded.cljs

added to the JIRA ticket https://dev.clojure.org/jira/browse/CLJS-2942?focusedCommentId=50404#comment-50404

I see there’s already a ticket for it: https://dev.clojure.org/jira/browse/CLJS-2948

Confirmed ^ CLJS-2948 isn’t a regression

I've bumped the two specs issues to blockers

The lack of printing of spec error details on many REPL environments (https://dev.clojure.org/jira/browse/CLJS-2945) has an easy workaround that lessens this as an issue: If you encounter a spec failure in a REPL, then *e will be an ExceptionInfo, which easily provides access to the desired ex-data.