Fork me on GitHub
#clojurescript
<
2020-01-08
>
phtz06:01:15

Hi, does anyone here happen to be using cljs in conjunction with PostgREST?

philip16:01:29

Hello, I believe I am neck deep in a "Jar hell" problem and need a deeper understanding of cljs internals to figure it out. The problem manifests itself when I upgrade datomic and run cljs via the lein-cljsbuild plugin. Upgrading com.datomic/datomic-pro "0.9.5981" to .6014 causes cljs to not be able to parse ##NaN. The only jars this upgrade changes is datomic-pro and datomic-client so I don't see how it could even affect cljs, but nonetheless: When I start a cljs repl with lein trampoline cljsbuild repl-rhino and datomic .6014 in my project.clj dependencies:

cljs.user=> *clojurescript-version*
"1.10.597"
cljs.user=> ##NaN
Syntax error reading source at (REPL:1).
Reader tag must be a symbol
But with datomic .5981:
cljs.user=> *clojurescript-version*
"1.10.597"
cljs.user=> ##NaN
##NaN
On the JVM side, the deps trees and classpaths are identical except for the datomic jars. On the cljs side you can see it reports the same cljs version. From splunking around with source and doc as near as I can tell the tools.reader version is the same too. How would I even go about debugging this problem further?

p-himik17:01:42

That's interesting. Would it be possible to publish an example where I could check it out?

delaguardo17:01:07

you can check complete dependency tree for difference between “before upgrade” and “after” to spot “real” difference after resolving command lein deps :tree should help if I remember correctly

philip17:01:37

lein deps :tree shows that the only difference is datomic-pro and datomic-client. No other changes 😞

philip17:01:14

Unfortunately I can't post this project. This is a very large proprietary codebase. I'm going to work on a reproduction with minimal dependencies but I have a feeling it will work fine if I strip everything out, otherwise everyone would be having this problem.

p-himik17:01:15

> I have a feeling it will work fine if I strip everything out That's exactly why I usually ask for a minimal reproducible example. :) Often, when I just create it myself, it ends up working on my side.

p-himik17:01:15

Oh, datomic-pro and datomic-client are private jars, right? I can't find them.

👍 4
p-himik17:01:30

If so, try to see what namespaces they declare. It may be that one of them has a higher priority than tools.reader and overrides the clojure.tools.reader namespace with some older version that doesn't support ##NaN.

thheller17:01:42

the NaN issue is caused by mismatching the tools.reader and clojurescript versions

thheller17:01:07

if you use 1.10.597 cljs with an old tools.reader version you get this error

Alex Miller (Clojure team)18:01:04

maybe you have a dep that is an uberjar including its deps? certainly that can happen, is bad, and is hard to discern.

Alex Miller (Clojure team)18:01:08

if so, it's a matter of looking in each jar to see if it contains tools.reader code till you find it, but you might be able to make an educated guess as to where to start

Alex Miller (Clojure team)18:01:40

any chance you're using metasoarus/oz?

👎 4
thheller18:01:44

you can also check ( "clojure/tools/reader.clj") which might provide a clue

Alex Miller (Clojure team)18:01:40

oz was distributing uberjars, which included tools.reader, not sure if they still are

philip18:01:25

Thomas from what I can understand, the tools.reader in my clojure repl is fine. ##NaN works there. It's clojurescript that is the problem. There's no equivalent for cljs, right? It'd be cljs.tools.reader that is the problem?

philip18:01:33

@U064X3EF3 it looks like datomic-pro-0.9.6014.jar and datomic-pro-0.9.6021.jar include tools.reader (and tools.analyzer and core.async for what it's worth)

Alex Miller (Clojure team)18:01:37

hmm, might be a good question to take up in #datomic - I'm not too familiar with the design there

👍 4
cmcfarlen18:01:09

clojurescript-1.10.520.jar also has classes from tools.reader

cmcfarlen18:01:41

2272  02-13-2019 13:46   clojure/tools/reader$read_dispatch.class
     1473  02-13-2019 13:46   clojure/tools/reader$unquote_splicing_QMARK_.class
     3223  02-13-2019 13:46   clojure/tools/reader$read_string_STAR_.class

Alex Miller (Clojure team)18:01:56

clojurescript has always included AOT compiled versions of tools.reader and data.json

Alex Miller (Clojure team)18:01:33

ideally, they should probably shade those

dnolen21:01:56

@philip something else to consider is I don't really see why datomic and your cljs tooling needs to share a classpath

dnolen21:01:17

ClojureScript is build time only - it's quite common that it will never be involved with runtime ever

dnolen21:01:37

so sharing the classpath isn't meaningful and of course open you up to these kinds of time wasters

dnolen21:01:08

for the past year so when using deps, I have an alias just for ClojureScript and I keep all deps related to ClojureScript separate from stuff that will be actually deployed

dnolen21:01:06

(you might be doing some kind of embedded REPL based workflow then of course the other suggestions might be more relevant)

cmcfarlen21:01:10

@dnolen (I work with @philip) we embed figwheel with our backend jvm for our dev workflow. This issue is exposed running cljs tests so we could have a separate classpath for that. We compile the cljs separately for our prod builds but historically it is compiled at service startup for dev builds (so we can turn on debug/change optimizations without redeploying) It turns out that the datomic jar is also now including AOT compiled tools.reader code which is what surfaced this issue.