Fork me on GitHub

im trying to compile my compojure project into a jar file and I keep getting this error Could not locate clojure/java/jdbc__init.class or clojure/java/jdbc.clj on classpath.


What should I do if a javascript lib I use uses a reserved javascript word? Under advanced compilation, I’m getting errors, and I’m unsure if it’s something I can just ignore, or if there’s something I should do about it.


@levitanong What's the error? It might be fixable by adjusting :language-in since GCC will accept newer JS constructs then...


@rauh ERROR: JSC_PARSE_ERROR. Parse error. identifier is a reserved word at…


the offending identifier is byte


Right, so this should be fixable


Set :language-in to :es6 or :es5


@rauh thanks! it’s showing something else now though, skipping passes.


WARNING: Skipping pass checkVariableReferences


about 40 distinct but similar warnings o_O


I think it is not safe to set :language-in :es6. it does interfere with :advanced and easily doubles your output size


es5 should be fine


good morning! I’m trying to mix up es6 and cljs (the reason is that I need to extend an es6 react component that has a lot of local state and I find the idea of bridging that to cljs a bit daunting). So I started playing with the cljs native javascript modules, and the basics work like a charm… until I tried to use the dynamic import syntax (`import x from 'module'`). Does anybody have experience with that?


I have done a fair bit of ES6 interop. whats the problem?


@thheller How come it doubles your output size? I've been running with :es6-strict for forever. Just checked and compared to :es5 it's only ~5kb and 1kb gzipped difference.


@thheller I think I found one issue: I was hoping to be able to mix and match cljsjs but I had no joy there, I’m now trying by providing js sources for all the imported modules. Let’s see…


@rauh might just become an issue with the more recent releases of closure (not those used by CLJS yet). they changed how the compiler handles code in some way that causes weird issues when using the incorrect language-in


I see, I'll keep an eye out


@bru extending ES6 classes is also not that bad in CLJS so it can definitely be done


@thheller I may have to do that in the end. At the moment I think I managed to get the import working, but the (es6) transform processor is now complaining about ReferenceError: "console" is not defined


I'm playing around with npm-deps, but each time i recompile I get Undefined nameToPath for react unless I clear out the out directory. Are you seeing this too?


lots of people are seeing this yes. no idea what causes it. I’d suggest trying shadow-cljs where you definitely won’t see this. 😉


:) yeah, maybe. I like the idea of trying to get my npm libraries, where possible, through GCC. But it might be too crazy. Just had it crash on one module


I've just upgraded CLJS to 1.9.946 (from 1.9.671) on a React Native CLJS project I'm working on and am noticing 84% slower compilation (:optimizations :none) -- are there any known performance issues with this latest release? Any out-of-the-box ways to mitigate this?


@pandeiro No specific major slowdown that I'm aware of. But, one thing to ensure is that you have set a fixed heap for the compiler, say around 8 GB


@mfikes Thanks! Is that a new recommendation related to recent changes (ie, could that be what's causing the slowdown)?


No... it is a long-standing recommendation


This is a good stat to look at (to be sure it is actually the compiler, and not something else in the stack)