Fork me on GitHub
#cljs-dev
<
2022-07-15
>
lread15:07:24

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.

borkdude15:07:17

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

borkdude15:07:20

that is, if you include tools reader yourself

borkdude15:07:11

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

lread15:07:34

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

borkdude15:07:40

@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

lread15:07:15

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.

borkdude15:07:10

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

dnolen16:07:34

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

borkdude16:07:13

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