Not sure this is worth mentioning, but just in case it is useful info… I finally got around to updating/testing cljdoc-analyzer with ClojureScript 1.11 and found I’ll need to adapt to the now vendorized clojure tools reader. Current cljdoc analyzer code binds a clojure.tools.reader/*default-data-reader-fn* during file analysis. I’m going to adapt by first looking for cljs.vendor.clojure.tools.reader/*default-data-reader-fn* then, if that does not resolve, fall back to clojure.tools.reader/*default-data-reader-fn* for older versions of ClojureScript. I think that makes sense. If not, happy to hear about it.

I think there was some work done to re-bind the bound default-reader-fn if it was already bound, to the vendored one, but I could be mistaking

that is, if you include tools reader yourself

not sure if using the cljs.vendor stuff is intended as public API - cc @dnolen

Thanks, I saw the cljs.vendor.bridge, but do not understand it very well yet. Maybe I should be using it somehow instead.

@lee How I understand it is that, if you include tools reader yourself, cljs will try to use your bound value, and you can keep doing what you were doing

Not entirely sure yet, but it seems the cljdoc code currently wants to use the bundled tools reader for analysis (previously not vendored, now vendored). Which seems reasonable. Maybe.

that doesn't sound right to me, but it depends on this: https://clojurians.slack.com/archives/C07UQ678E/p1657899551320779

I don't think it's a big problem to use the vendorized stuff? I can't see any obvious major issue

well, ok then :) in one of my libs I've vendorized a library to make tweaks to it and I def. don't want to expose that to end users, but in CLJS's case the reason for vendorizing is different: AOT

Coolio! Thanks @dnolen & @borkdude!