are you using the latest code from master? I believe that is fixed.

> I've also tried other reporters, including just straight console log/warn/error, but since pretty/reporter is the closest to working and the one whose intended output I want, I'll focus on that one. I’ve tried pretty/reporter, console.log/error/warn, pretty/thrower and have even copied and modified tons of the function call chain of pretty/reporter However: 1. With thrower and default -fail completely illegible schema failures are printed a. It is extremely "horizontal/squished" b. and more importantly even inspected in devtools repl, I cannot see the schema failure contents, just the data of the schema I wrote in the first place i. (I've expanded all the folding bits in devtool's custom formatted content for the error) 2. I also tried replacing some logic within pprint-document (more on that fn to follow) to console.warn instead, and got some progress somehow a. This is the first screenshot b. But as you can see, it looks like it's printing actual characters, instead of what I believe might be encodings for whitespace? 3. And with pretty/reporter, it looks like something about the whitespace is messed up, and so is also nearly illegible a. (second screenshot) b. The content does print, but it looks like each word boundary whitespace is printed as a new line, and most of the time, it's several empty newlines per. c. As I step through pprint-document, it looks like after the document goes through (serialize document) and the (eduction chain, the print call in (run! print) receives each individual word, instead of the lines that (I think) should have those words in them

(->> (serialize document)
          (eduction
            annotate-rights
            (annotate-begins options)
            (format-nodes options))
          (run! print))

@U055NJ5CC, I have [metosin.malli LATEST] in lein, do you mean a direct git dependency or something?

Thanks so so much for the help! I've been trying to figure this out for like a week, too embarrassed in case it was like an extension or external script or some user error that was causing it - I didn't even think to check if the latest master/docs were released or not. Regarding your points: 1. I was trying to copy individual functions lol, can't believe I didn't think to just copy the relevant ns completely. Will do this post-haste. 2. Of those 2 recent fixes for cljs, it looks like a. https://github.com/metosin/malli/commit/f7b4e12d3fe3e2f60ff50057118308b7a3abe148 is about collecting metadata fn schemas, doesn't that mean it's a fix only for metadata style fn schemas? So wouldn't things work without this fix if I didn't use metadata style? ( the inverse of what you said) Lastly, since I'm here: 1. I'm actually using neither => nor metadata style, as I'm trying to use malli with helix defnc components. a. I'm directly using a wrapper over (-instrument {:schema ... :reporter ...} some-fn-arg-from-wrapper) i. Would that have some implications regarding any of the since-last-release cljs fixes? b. Without too many specifics, but in case helps to know why, i. defnc does not forward metadata to the expanded fn, so that route doesn't work, would have otherwise used that 1. (yet again, there's an unpublished recent change that added metadata forwarding lol - oh lein) ii. the output of the defnc macro could sometimes be an Fn , in which case => would work, but at other times it produces a js obj with a key render that has the equivalent Fn 1. This is just a detail of React, wherein the latter case of the obj.render is a special case handled automatically by React iii. so my wrapper just instruments the output of defnc with the provided schema for this special case, so it picks out the render key's val if it's an obj, or the fn itself if it's an fn, and then passes either to -instrument

for 2. even though it's about collect it doesn't impact functionality - just developer experience (requires saving your code twice to see new fn schemas)

ok cool, I think using -instrument directly should work - for getting around helix not forwarding meta you can structure your code such that the body of all helix components proxy to your own functions of props -> react element

and then just instrument those