Fork me on GitHub
#shadow-cljs
<
2021-02-22
>
rschmukler18:02:15

Has anyone here ever seen shadow unable to use a specific library because the underlying library cannot be converted from ES6 in the closure compiler?

rschmukler18:02:49

Specifically, I am trying to use https://www.npmjs.com/package/mapbox-gl which is published as an ES6 bundle

thheller18:02:45

if it cannot be converted you can turn of the conversion via :compiler-options {:output-feature-set :es6} or :es7 :es8. depending on what makes sense

rschmukler18:02:27

It does look like it can't be, without more advanced transpilation config anyway (it depends on webworkers)

thheller18:02:01

unless you need really old browser support :es6 is a reasonable setting. I might even make it default soon (since Closure will do that as well)

rschmukler18:02:00

Yep, that fixed it! Apologies for not consulting the user guide before bothering you

rschmukler18:02:10

Thanks for the help 🙏

orestis18:02:02

I wonder if people are seeing slow file change response times from shadow-cljs on M1 macs? This is probably related to the hawk and the underlying file watch service thing, but I thought I'd ask here first if there's a known issue?

thheller19:02:47

@orestis update. I removed hawk entirely and the default JVM watcher seems to be faster.

orestis20:02:38

Indeed it’s much faster. Thanks! I’m using the Azul 11 jdk on ARM btw.

orestis19:02:03

I'll try, thanks

Adam Kalisz19:02:56

@thheller Ok, it seems the problem I have written about yesterday (but messed up the handle) "For some time, I was unable to load the development version of our ClojureScript project on localhost in Chromium. It worked in Firefox, but was rather slow. I didn't know at all, what caused it. So I tried to gather some data about it. I cleared the cache of Chromium (deleted ~/.cache/chromium) and this helped a few times but the problem always returned. I have resorted to deleting of the build directory of shadow-cljs. The result was that the development version of our project loaded immediately in Chromium and Firefox as well. I don't have any further data, just wanted to let you know." It seems, the problem stems from shadow-cljs watch since the problem doesn't happen when a release is built. I tried this with 2.11.11 and 2.11.18 and there was no change. I am on Debian Testing, none of my colleagues with Windows are experiencing this but for me, I am basically unable to work efficiently - there are no development tools for ClojureScript in Firefox. Chromium seems to be hit by this bug somewhat harder. What further debugging steps do you propose?

thheller19:02:03

sorry I cannot provide any tips without more info about your project

thheller19:02:28

when it compiles and you get the "build completed" message. what numbers do you see?

thheller19:02:54

[:browser] Build completed. (143 files, 137 compiled, 0 warnings, 8.33s)

thheller19:02:10

which version do you use? which java version?

Adam Kalisz19:02:18

When run with shadow-cljs watch I see:

Adam Kalisz19:02:54

[:client] Build completed. (1106 files, 9 compiled, 0 warnings, 1.48s) The release version looks like this: [:client] Build completed. (1041 files, 895 compiled, 0 warnings, 113.01s) The Java version is: java --version openjdk 11.0.10 2021-01-19 OpenJDK Runtime Environment (build 11.0.10+9-post-Debian-1) OpenJDK 64-Bit Server VM (build 11.0.10+9-post-Debian-1, mixed mode, sharing)

Adam Kalisz19:02:17

I tested with shadow-cljs 2.11.18 and 2.11.11 as well. No visible change in behaviour between those.

thheller19:02:11

looks fine. do you use :init-fn in your build config?

thheller19:02:21

if so try changing :init-fn some.ns/foo to just :entries [some.ns]. that will cause the same code to be included but not called on startup

thheller19:02:44

is it still slow when loading the page? or is the call actually making everything slow? if so that is your code and shadow-cljs can do nothing about that.

Adam Kalisz19:02:13

:client     {:target           :browser
                            :output-dir       "resources/public/js/compiled"
                            :asset-path       "/js/compiled"
                            :module-loader    true
                            :modules          {:shared {:entries []}
                                               :main   {:init-fn    orgpad.client.core/init
                                                        :depends-on #{:shared}}
                                               :admin  {:entries    [orgpad.client.views.administration.core]
                                                        :depends-on #{:main}}
                                               :layout {:entries    [orgpad.client.layout.webworker.core]
                                                        :depends-on #{:shared}
                                                        :web-worker true}}
                            :compiler-options {:infer-externs      :auto
                                               :output-feature-set :es6}
                            :devtools         {:after-load     orgpad.client.core/mount-root
                                               :before-load    orgpad.client.core/stop-web-workers
                                               :watch-dir      "resources/public"
                                               :browser-inject :main
                                               :loader-mode    :script}}
The init looks like this:
(defn init
  "Init function of the client."
  []
  (rf/dispatch-sync [:init/starting-app])
  (window-events!)
  (accountant/configure-navigation!
    {:nav-handler       #(rf/dispatch [:app/changed-route %])
     :path-exists?      #(routes/client-routes (:handler (b/match-route routes/routes %)))
     :reload-same-path? true})
  (webfonts/load!)
  (mount-root))
I will try your proposed change

Adam Kalisz19:02:12

I have done the change:

:main   {:entries    [orgpad.client.core] ;:init-fn    orgpad.client.core/init
         :depends-on #{:shared}}
(restarted shadow-cljs watch) and it still hangs and shows "shadow-cljs - Reconnecting ..." in the browser, also the Console output looks pretty much the same as it looked before on such hang

thheller19:02:23

do you have browser extensions installed in chrome?

thheller19:02:54

> Console output looks pretty much the same

thheller19:02:56

what does it say?

Adam Kalisz19:02:21

Installing CLJS DevTools 0.9.10 and enabling features :formatters :hints :async util.cljs:136 CLJS DevTools: some custom formatters were not rendered. devtools$util$check_custom_formatters_active_BANG_ @ util.cljs:136 browser.cljs:20 shadow-cljs: #6 ready! react-dom.development.js:24995 Download the React DevTools for a better development experience: core.cljs:11 csrf-token parsed: 9YQlw8taXECNrtRSbR8y1jjZ3awFctrGTALtx5YpLoTZxxhb0O9xIY1ZGxoTbWFGBF0D5VjbpxwKh6lW

Adam Kalisz19:02:54

I don't have any notable extensions just Chromium PDF Viewer and CryptoTokenExtension

Adam Kalisz19:02:22

The Chromium is: Version 88.0.4324.146 (Developer Build) built on Debian bullseye/sid, running on Debian bullseye/sid (64-bit)

thheller19:02:34

that suggests there is still code running on startup core.cljs:11

thheller19:02:09

why the the shadow-cljs websocket reconnecting? what do you see in the network tab regarding that?

Adam Kalisz19:02:33

I don't know. I will try again with all browser cache cleared

fsd19:02:50

Need help starting shadow cljs Application yarn start crashes and cant get pass this

thheller19:02:59

weird. try deleting the .shadow-cljs directory in the project. not a clue why it can't read a file it obviously found?

fsd20:02:19

didn’t work after doing that :(

thheller20:02:51

I don't know. look at the file in your editor and make sure it is readable and so on

Adam Kalisz19:02:49

I cannot get rid of the csrf-token parsed line - it seems to concern this code: (def csrf-token "Value of CSRF token parsed from the metadata of HTML." (-> "csrf-token" js/document.getElementsByName (aget 0) (.getAttribute "content"))) (js/console.log "csrf-token parsed: " csrf-token) this is the line 11

thheller19:02:07

you don't have to get rid of it. all code running on startup (without :init-fn) however directly contributes to load time

thheller19:02:14

so you have to dig yourself on why it is slow

thheller19:02:45

got into the profile, hit record+reload and figure out what is going on 😛

Adam Kalisz19:02:21

The problem is, the load never finishes at all in Chromium...

thheller20:02:45

that is fine. the profiler should stop after a few seconds.

Adam Kalisz20:02:15

Sometimes, after a lot of deleting caches etc. it loads but after a few page changes in our SPA the problems is back again

thheller20:02:39

I have absolutely no clue what you are doing so I cannot comment

Adam Kalisz20:02:14

Sure. Me neither thank you for your time and effort

jaide22:02:59

Is there a quick way to tel the dev-http config to serve files from a virtual /static/ path or should I write a custom handler?

thheller12:02:12

what is a virtual /static/ path? You mean you don't have an actual /static/ directory on disk? that case would require a custom handler.

jaide17:02:23

Correct, a non /static/ path on disk.

jaide17:02:58

That makes sense, though I ended up just creating an actual static subdir which also solved the problem 😛

jaide19:02:04

Also: Thanks 🙂