Fork me on GitHub
#clojurescript
<
2017-06-29
>
hackeryarn02:06:20

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.

hackeryarn02:06:30

I am using a pretty standard setup with figwheel and lein

hackeryarn02:06:09

{: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"]}

akiroz07:06:22

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)

asolovyov12:06:37

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

dnolen12:06:35

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

dnolen12:06:59

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

asolovyov12:06:44

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

asolovyov12:06:57

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

asolovyov12:06:32

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

asolovyov12:06:57

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

asolovyov12:06:03

let me re-check

asolovyov12:06:39

@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.

sandeep.balaji12:06:49

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

dnolen12:06:39

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

dnolen12:06:47

never had the patience to investigate though

dnolen12:06:46

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

asolovyov12:06:50

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

asolovyov12:06:01

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

dnolen12:06:11

this is what I mean though 🙂

dnolen12:06:29

everything looks OK - but the symptom is something impossible

dnolen12:06:59

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

dnolen12:06:07

your protocol error

asolovyov12:06:39

yeah, I guessed so

asolovyov12:06:52

ok, so maybe my :exclusions breaks it

asolovyov12:06:01

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

james12:06:09

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!

james12:06:04

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.

the-kenny14:06:39

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-kenny14:06:19

hm too bad 😞

thheller14:06:31

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

the-kenny14:06:49

@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

thheller14:06:47

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

dnolen15:06:18

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

dnolen15:06:45

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

dnolen15:06:56

code motion exists for :modules

dnolen15:06:18

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

dnolen15:06:29

see my comment at the end

dnolen15:06:05

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

dnolen15:06:25

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

dnolen15:06:47

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

the-kenny15:06:18

@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

dnolen15:06:43

@the-kenny it is the current behavior

dnolen15:06:03

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

dnolen15:06:45

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

dnolen15:06:01

just defining a intermediate module will greatly aid in code motion

the-kenny15:06:33

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

dnolen15:06:48

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

dnolen15:06:54

read the original Google Closure thread on this issue

the-kenny15:06:52

Yup, will do

thheller16:06:58

@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.

thheller16:06:19

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

thheller16:06:45

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

dnolen16:06:55

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

dnolen16:06:22

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

dnolen16:06:19

I do not care about naive :modules use at all

thheller16:06:47

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

dnolen16:06:54

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

mobileink19:06:20

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?

dnolen19:06:19

@mobileink :none means no Closure Compiler

dnolen19:06:34

historically Closure Compiler never saw :foreign-libs

dnolen19:06:02

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

mobileink19:06:58

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?

mobileink19:06:40

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

dnolen19:06:12

@mobileink no rewriting is necessary

dnolen19:06:21

goog.base provides a dynamic loader

dnolen19:06:26

goog.require is a real thing under dev

mobileink19:06:22

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?

dnolen19:06:24

not bonkers

dnolen19:06:40

Google Closure provided a dependency mechanism because nothing standard existed

dnolen19:06:26

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

mobileink19:06:33

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.)

dnolen19:06:15

absolutely

dnolen19:06:37

@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

dnolen19:06:13

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)

dnolen19:06:23

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

dnolen19:06:39

also called tree-shaking

mobileink20:06:38

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

mobileink20:06:04

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.

dm321:06:31

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?

thheller22:06:08

@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

thheller22:06:24

I assume its .cljc because of self-hosted