I just pushed my first cljs app to prod, and I am still getting the screen "If you are seeing this you haven't compiled your application yet...". I am not sure how to get rid of this.

I am using a pretty standard setup with figwheel and lein

{:uberjar {:omit-source true
             :prep-tasks ["compile" ["cljsbuild" "once" "min"]]
             :cljsbuild
             {:builds
              {:min
               {:source-paths ["src/cljc" "src/cljs" "env/prod/cljs"]
                :compiler
                {:output-to "target/cljsbuild/public/js/app.js"
                 :optimizations :advanced
                 :pretty-print false
                 :closure-warnings
                 {:externs-validation :off :non-standard-jsdoc :off}}}}}
             
             
             :aot :all
             :uberjar-name "fcc_tracker.jar"
             :source-paths ["env/prod/clj"]
             :resource-paths ["env/prod/resources"]}

Not sure if this is the right place to ask but does anyone know if there's already been a JIRA ticket about the new :npm-deps feature for JS libraries that require() JSON files in their code? (or libraries that's got their entry point set to index.json)

Hey all! Any pointers on why suddenly I can get this error in a new project? Use of undeclared Var cljs.core/PROTOCOL_SENTINEL

@asolovyov I haven’t heard anybody else report that - seems strange

I would make sure there’s nothing strange in your project setup and that your project is clean

it's pretty weird, yeah, project seems really simple to me. Clojure, clojurescript, rum, figwheel, that's all... 😕

https://paste.in.ua/2787/ - that's my full project.clj

I'm really unsure what I'm doing wrong. It's not the first time I created a cljs project... :))

oh, it seems that :classifier "aot" causes the problem

let me re-check

@dnolen ok, so that happens when I do :exclusions [org.mozilla/rhino] 🙂 I do this in another project to make uberjar smaller, but here it's not important, so I'll just remove that. Not sure why it causes the problem though.

Someone Please suggest real-time-messaging clojure library. I might also need Screen Sharing and video chat.

@asolovyov I have seen some strange behavior in build setups that aren’t just Maven when using ClojureScript with classifier aot

never had the patience to investigate though

@asolovyov the symptom shows that you are probably getting 2 version of ClojureScript somehow

@dnolen aot works actually, that's rhino making this hard 🙂

well I looked at lein deps :tree output and it looks ok...

this is what I mean though 🙂

everything looks OK - but the symptom is something impossible

ah 🙂

you could only see that error if you got macros from a new ClojureScript but a standard library from an old one

your protocol error

yeah, I guessed so

ok, so maybe my :exclusions breaks it

whatever, now I'm happy I made it work 🙂

Has anyone successfully used autotrack (https://github.com/googleanalytics/autotrack) in a ClojureScript project? We managed to get the basics setup, and are successfully sending “impression” and “maxScroll” events. But we can’t get “eventTracker” events to send to Analytics, even though it looks like we followed the documentation to the letter. Any help would be highly appreciated!

Looks like we fixed it. We needed to customize the attributePrefix option (https://github.com/googleanalytics/autotrack/blob/master/docs/plugins/event-tracker.md#customizing-the-attributeprefix-options) so as not to refer to ga. Now eventTracker events are correctly being sent.

@james sounds like you are missing the externs for google analytics maybe? https://github.com/google/closure-compiler/blob/master/contrib/externs/google_universal_analytics_api.js

Can we depend on Google Closure moving non-shared code to the most specific module instead of keeping it in :cljs-base when using the :modules feature? We've got some code we only want to load in a specific situation, which should not end up in the :cljs-base module.

@the-kenny no you cannot. see https://dev.clojure.org/jira/browse/CLJS-2011

hm too bad 😞

use shadow-cljs … then you can 😉 https://github.com/thheller/shadow-cljs

@thheller I'll have a look, but I think it will come to two different compilation units. We don't load the different compilation units into the same page at all

not sure I understand but yeah 2 builds is better than :modules unless users frequently use both “builds”

@the-kenny I do not agree with @thheller’s analysis here

@the-kenny the way we leverage :modules is exactly what Google recommends

code motion exists for :modules

that ticket is liable to just get closed it’s not a real problem

see my comment at the end

@the-kenny the latest release supports wildcard namespaces to make the whole process considerably less tedious

there’s some more enhancement work I’d like to do based on a shadow-build feature, which is to provide a loader for you and for this to work under :none and :advanced

and finally that’s what resolve is for - so you can invoke across code splits

@dnolen I think what I wanted in my earlier question was a behavior like "Move as much code as possible into leafs in the module tree, keep shared code as small as possible". As far as I can see this isn't the current behavior of neither Closure nor Clojurescript. Doesn't really matter here anyway, two separate builds are working perfectly fine 🙂 I'll give this another shot with wildcards tomorrow. Got a better feeling with explicit grouping anyway, less error-prone

@the-kenny it is the current behavior

I’ve used this feature numerous times and code motion works great as long as you modify your expectation

for example if I’m doing a re-frame app I would make a module just for React, re-frame and re-frame utilities

just defining a intermediate module will greatly aid in code motion

Oh, I must have misread the thread then. I'll give it another try 🙂

Thanks!

I would ignore all commentary on that issue except the last one

read the original Google Closure thread on this issue

Yup, will do

@dnolen I do not have time to go into this right now but you are wrong. things closure won’t move: defmethod, cljs.spec.alpha/def and a few more. If they are assigned to :cljs-base they will stay there.

and the discussion in the closure thread is about something else entirely

it is not

I have provided a full reproduction, if you do not agree feel free to close

and your points about various things that can’t move aren’t actually that interesting

I have worked with clients projects and manually splitting works well enough

I do not care about naive :modules use at all

as I said … no time … not trying to convince you, I have no stake in this.

yes not going to be convinced, the issue is closed - we just not going to support this kind of naive :modules usage - users need to define more modules

q 1: compiling with :optimizations :none means your code will not be run thru the closure compiler, correct? q2: but if you use :foreign-libs, the closure compiler will munge the libs. correct? q3: ditto for :libs? q4: the only case in which the closure compiler is not at all involved is with no optimization and all external js embedded using <script>. correct?

@mobileink :none means no Closure Compiler

historically Closure Compiler never saw :foreign-libs

the only real exception here is if you’re using JS modules (not Closure modules)

even if i use goog.provide for my own lib? doesn't that need closure processing? (fwiw trying to pin down the exact role of the closure ecosystem in cljs) or does it just depend on closure libs?

my understanding is that a 3rd party lib using goog.provide must be rewritten (by closure) to make the namespacing work.

@mobileink no rewriting is necessary

goog.base provides a dynamic loader

goog.require is a real thing under dev

aha! the lib itself provides functionality that an old c crank like me would expect to find in the compiler/linker? nutty proposition: the closure ecosystem provides for cljs at least some of the functionality that is provided by the jvm for clojure. like loaders. so we can think the cljs host environment as not just the jsvm, but also the closure "environment". is that bonkers?

not bonkers

Google Closure provided a dependency mechanism because nothing standard existed

and in fact the compiler compiles new JS modules idioms like AMD, CommonJS, ES6 import back to goog.require

hoorah, i think i'm beginning to grok it. and the closure module mechanism effectively functions as a kind of module emulation layer (shim?), and the closure compiler maps the disparate module mechanisms to that common mech. cljs leverages this to provide a unified model of code organization in spite of the fact that the base host env (pure jsvm) has none. sound accurate? (yes ,i'm trying to work out prose to offer for the official docs.)

absolutely

@mobileink the caveat of course is that many JS libs are not written with DCE in mind like Closure JS (or ClojureScript by generating Closure compatible JS) - they can be too dynamic

DCE?

so while in theory we can abstract over all these different systems, in practice only a few libs can work w/o some help (externs)

*D*ead *C*ode *E*limination

also called tree-shaking

ha, always wondered what "tree-shaking" meant. (memo to self: compile list of acronyms)

thanks so much for taking the time to answer my qs! i know you must be very busy, really appreciate it and will try to reciprocate with some good docs.

regarding the spec impl in Clojurescript - the cljs.spec.alpha/registry-ref is defined in both cljs/spec/alpha.cljc and cljs/spec/alpha.cljs - how does that work?

@dm3 when both exist the CLJS compiler will prefer the .cljs, the .cljc then just becomes a macro file and specs have a CLJ part for macros

I assume its .cljc because of self-hosted