Fork me on GitHub
#shadow-cljs
<
2021-01-14
>
jkent02:01:10

After adding :repl-init-ns option to my shadow-cljs.edn, I’ve been encountering the following error after leaving my browser repl idle:

[2021-01-05 13:26:03.677 - WARNING] :shadow.cljs.devtools.server.worker.impl/cljs-compile-ex - {:input {:code "(test-client)", :ns client, :repl true}}
ExceptionInfo Failed to process REPL command {:eof? false, :ns client, :form (test-client), :source "(test-client)", :tag :shadow.cljs.repl/process-ex}
        shadow.cljs.repl/process-read-result (repl.clj:524)
        shadow.cljs.repl/process-read-result (repl.clj:498)
        shadow.cljs.repl/process-input (repl.clj:682)
        shadow.cljs.repl/process-input (repl.clj:660)
        shadow.cljs.devtools.server.worker.impl/fn--15170 (impl.clj:755)
        shadow.cljs.devtools.server.worker.impl/fn--15170 (impl.clj:745)
        clojure.lang.MultiFn.invoke (MultiFn.java:234)
        shadow.cljs.devtools.server.util/server-thread/fn--14833/fn--14834/fn--14842 (util.clj:285)
        shadow.cljs.devtools.server.util/server-thread/fn--14833/fn--14834 (util.clj:284)
        shadow.cljs.devtools.server.util/server-thread/fn--14833 (util.clj:257)
        java.lang.Thread.run (Thread.java:834)
Caused by:
ExceptionInfo no source by provide: client {:provide client}
        shadow.build.data/get-source-id-by-provide (data.clj:187)
        shadow.build.data/get-source-id-by-provide (data.clj:184)
        shadow.build.data/get-source-by-provide (data.clj:190)
        shadow.build.data/get-source-by-provide (data.clj:189)
        shadow.cljs.repl/repl-compile/fn--14400/fn--14401 (repl.clj:460)
my client.cljs file looks as follows:
(ns client
  (:require [cljs.repl :refer [doc find-doc source apropos pst dir]]
            [re-frame.core :as rf]
            [re-frame.db :as rfdb]))

(defn test-client []
  {:status "alive"})

(defn db []
  @rfdb/app-db)
what does “no source by provide: xxx {:provide xxx}” mean? is there a way to to recover from this besides restarting my shadow-clj watch and my repl?

thheller10:01:56

which version do you use? I fixed a bug related to this in the last version

jkent14:01:16

@thheller I’m using the latest shadow-cljs version 2.11.13

thheller15:01:20

I suppose client is not part of your usual build? try adding :preloads [client] :repl-init-ns client

jkent15:01:35

thats correct. client.cljs is mostly used a scratch file for development

jkent15:01:02

I’ll try adding :preloads [client] to my shadow-cljs.edn file

jkent15:01:59

I’m giving this a go:

:devtools         {:repl-init-ns client
                   :http-root    "resources/public"
                   :http-port    8280
                   :proxy-url    ""
                   :preloads     [client
                                  sphere.cstools
                                  devtools.preload
                                  day8.re-frame-10x.preload]}}}}

thheller15:01:38

that should be fine

grav08:01:18

Can I get Shadow to reload and re-run tests (`:target :node-test`) when a non-clojure file changes (in this case an edn file with expected results)?

Karol Wójcik10:01:46

@thheller I'm sorry for notifying you directly, but I think that you're the only who can answer this question. In the project I'm working on we're using following strategy to resolve lazy modules:

(defn- lazy-resolve
  [symbol-k]
  (let [symbol' (symbol symbol-k)
        module' (-> (str symbol')
                    (s/replace #"/.*" "")
                    (s/split #"\.")
                    ((partial s/join "-"))
                    keyword)]
    `(conj [] ~module' (cond-> (fn [] (resolve (quote ~symbol')))
                         config.core/DEV?
                         (with-meta {:sym (quote ~symbol')})))))
.... From this we get [module-name, symbol] like ["core-reservation", "core.reservation/some-symbol"] . Then we combine that data with shadow.loader . Of course it works well. The only issue I have is how greatly this pattern increase the build size. Those invocations are spread across whole application adding like 200kb for main bundle. The question is whether it can be somehow optimized? If you could share some insights with me I would be more than grateful.

Karol Wójcik10:01:41

@thheller I'm using code splitting and lazy modules. I'm trying to say that requiring lazy different modules to main bundle results in those long strings of resolves. I would like to make it smaller.

Karol Wójcik10:01:14

@thheller Ok got it. Will use loadable and the issue is resolved. 🙂 Thank you so much!

thheller11:01:22

as I said ... look at the build report so you can figure out WHY you get the 200kb

thheller11:01:34

my hunch would be that you are importing cljs.analyzer somewhere maybe

Karol Wójcik12:01:45

@thheller i got a lot of lazy calls, and a lot of lazy modules. Anyway thanks for hint with cljs.analyzer. Will check this out

thheller12:01:28

that doesn't tell me anything. I do not know what a lazy call or lazy module is in your terms

thheller12:01:50

I know what it is in the case of shadow.lazy but if you build your own I do not know what that does

Karol Wójcik15:01:05

I mean that I'm having 30-40 modules (you told me once that I should group those modules together (will do it as well)) in :modules section in shadow-cljs.edn configuration which I use quite extensively in main module. The strategy of requiring the module is combination of shadow.loader + resolve. Resolve is the function which adds that 200kb to main bundle. Checked whether cljs.analyzer is imported somewhere, but it's not 🙂

Karol Wójcik15:01:33

Thank you very much for the respnse. Will use Loadable to get rid of resolve 🙂

thheller15:01:23

resolve adds a bunch of boilerplate "noise" yes. didn't expect it to get to 200kb though.

Felipe Marques14:01:58

I boiled down to two problems. • Referencing deprecated functions (and multi-method)

(defn ^:deprecated my-fn [a b] (+ a b))
• A namespace defining a value two times
(def a 1)
(def a 2)
@thheller Was there any change to Shadow from version 2.8.93 to verison 2.11.13 regarding this? I didn't find any in the notes of each release, but I may have not notice.

grounded_sage15:01:13

How do I control what browser the browser-repl connects to?

mkvlr15:01:07

@grounded_sage by default it’s the first one that connects, but you can change it to be the last with :repl {:runtime-select :latest} in shadow-cljs.edn

👍 3
thheller15:01:48

there is also now (shadow/repl :app {:runtime-id 123})

👍 3
grounded_sage16:01:10

Is this documented somewhere and how you use it?

thheller16:01:09

what do you mean? thats all there is to it?

grounded_sage17:01:18

Sorry I am just unsure how :runtime-id works. Where is it generated? I don’t see anything that says runtime id when I run shadow-cljs watch app etc. I haven’t been that deep in shadow-cljs lately or doing any complex configurations.

thheller17:01:16

ah sorry. it is visible in the ui http://localhost:9630/runtimes

thheller17:01:25

or listed in most runtimes on connect

thheller17:01:38

browser.cljs:20 shadow-cljs: #13 ready! or so

thheller17:01:43

13 would be the runtime-id

thheller15:01:03

@marques.goncalves.fel your question is unclear. need more information about what you are doing. how do you "eval" the dev ns? (require 'dev) in the REPL? load-file from the editor? (ns dev)? if you just use (dev/whatever) without doing those first you'll get the dev is not defined error?

Felipe Marques15:01:17

I eval the file using cider-eval-buffer. The file in question is the dev.cljs which contains the dev namespace.

thheller15:01:36

and what is in that file?

Felipe Marques16:01:39

Lot of stuff! Hahahaha. But I found out that it didn't load when it referred another namespace that contained a deprecated function like this: (defn ^:deprecated ab [a b] (+ a b) Or when the namespace itself defined a value two times, like this:

(def company-id (random-uuid))
; Some other code
(def company-id #uuid "0acf9013-7c42-49fc-ae4b-221639bf9a34")

thheller16:01:32

ah so whenever there is a warning

Felipe Marques18:01:48

Yes, I think so.

thheller18:01:05

right yeah I changed it that warnings in compiled code prevent the code from being loaded

thheller18:01:32

still need to add an option to turn that off

Felipe Marques18:01:41

Got it! Cool! Thanks for the information. Do you think that this is an issue that a new comer to the repo would be able to do? Maybe I can try to add this option.

thheller18:01:42

fixed in 2.11.14 via :devtools {:ignore-warnings true} in your build config

grounded_sage16:01:46

Thanks @mkvlr that is exactly what I needed.