I wonder if we should try to add cljdoc-analyzer (or just its cljs metagetta tests) to https://github.com/cljs-oss/canary
Could be a win/win. Cljdoc team would discover problems early due to ClojureScript changes, and ClojureScript team would know early if their changes have affected cljdoc.
that sounds like a good idea
Because I don’t know/remember: why does cljdoc-analyzer supports parsing source with unknown tagged literals? I see from the https://github.com/cljdoc/cljdoc-analyzer/issues/32?.
yeah, that #js tag was present in a cljc file I believe and broke Clojure analysis
Ah… I see.
I wonder if this data_readers.clj is fulcro’s way of addressing? https://github.com/fulcrologic/fulcro/blob/develop/src/main/data_readers.clj
Do you remember if this was a widespread issue or just a problem with fulcro?
@holyjak I think you worked on this one, do you remember?
It will be problem for any CLJC lib that is using #js and, in general, for any lib using any custom data literals. But the fix I made fixes that for all possible cases?
Yes, if you had data readers like those referenced above at root of the classpath then it would work. IMHO it's good to ignore unknown literals because 99% they are irrelevant for those parts of code Cljdoc care about, ie function names and docstrings. No?
There is a lib with custom literals for Java time classes. Should we fail parsing any lib using those?
Thanks for the reply! I only ask because the latest version of ClojureScript broke cljdoc-analyzer’s metagetta in this area. And I was wondering if we really need to support unknown tagged literals. Or should we just expect projects to include appropriate data_readers.clj/cljc? (Maybe this would not be enough? I’m a bit fuzzy on what might be required).
Note the ClojureScript change that broke us is currently being labelled as a regression. But while digging in, I just wondered about this feature.
To be clear, I’m not at all saying we shouldn’t be doing this. Just trying to understand more.