Fork me on GitHub

with all the vendorization going on isn't there now a problem between transit-java and the vendorized transit-clj? if a newer or older transit-java ends up getting on the classpath that might break things? I mean given how stable the interface is that seems unlikely, yet still possible?

Alex Miller (Clojure team)11:05:26

Not different than other lib dependency?


but the other vendorized libs don't have dependencies so they can't have that interaction


but yes, dependency conflicts need to be sorted either way. just that that one may create more confusing errors


@alexmiller working on this bridging thing - is the dynamic extension really necessary


I just typed an alternative that just extends the protocol implementers directly by using the backing interface


this would be conditionally loaded in cljs.analyzer

Alex Miller (Clojure team)14:05:41

no, as I said yesterday, I don't think it's necessary

Alex Miller (Clojure team)14:05:22

conditional to tools.reader namespace on classpath -> install the bridges to the shaded protocol

Alex Miller (Clojure team)14:05:21

the dynamic part only adds something if people have external extensions to the tools.reader protocols, and I did not find a single case of anyone doing that


@alexmiller mind eye-balling this, will do the conditional load later and the *alias-map* stuff

Alex Miller (Clojure team)14:05:20

I can look at it at some point today, yeah


merged the bridging - building an artifact for people to test - if that seems ok - then will put together release notes etc.

🎉 1

1.11.50 should be available soon, reports most welcome